DE69013541T2 - Kryptosystem mit öffentlichem Schlüssel und/oder Unterschrift und mit digitaler Unterschriftsbeglaubigung. - Google Patents
Kryptosystem mit öffentlichem Schlüssel und/oder Unterschrift und mit digitaler Unterschriftsbeglaubigung.Info
- Publication number
- DE69013541T2 DE69013541T2 DE69013541T DE69013541T DE69013541T2 DE 69013541 T2 DE69013541 T2 DE 69013541T2 DE 69013541 T DE69013541 T DE 69013541T DE 69013541 T DE69013541 T DE 69013541T DE 69013541 T2 DE69013541 T2 DE 69013541T2
- Authority
- DE
- Germany
- Prior art keywords
- certificate
- signature
- message
- hash value
- digital signature
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 claims abstract description 77
- 238000004891 communication Methods 0.000 claims description 22
- 238000012545 processing Methods 0.000 claims description 15
- 238000012795 verification Methods 0.000 abstract description 20
- 238000013475 authorization Methods 0.000 abstract description 7
- 230000008569 process Effects 0.000 description 29
- 230000006870 function Effects 0.000 description 22
- 238000004422 calculation algorithm Methods 0.000 description 17
- 230000008520 organization Effects 0.000 description 16
- 238000013478 data encryption standard Methods 0.000 description 13
- 238000010200 validation analysis Methods 0.000 description 11
- 239000000463 material Substances 0.000 description 7
- 238000012217 deletion Methods 0.000 description 5
- 230000037430 deletion Effects 0.000 description 5
- 238000012546 transfer Methods 0.000 description 5
- 230000002776 aggregation Effects 0.000 description 4
- 238000004220 aggregation Methods 0.000 description 4
- 238000013459 approach Methods 0.000 description 4
- 230000005540 biological transmission Effects 0.000 description 4
- 238000012790 confirmation Methods 0.000 description 4
- 238000004590 computer program Methods 0.000 description 3
- 238000010606 normalization Methods 0.000 description 3
- 230000002829 reductive effect Effects 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 2
- 230000001010 compromised effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000015654 memory Effects 0.000 description 2
- 230000002441 reversible effect Effects 0.000 description 2
- RWSOTUBLDIXVET-UHFFFAOYSA-N Dihydrogen sulfide Chemical compound S RWSOTUBLDIXVET-UHFFFAOYSA-N 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 239000012141 concentrate Substances 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 239000002243 precursor Substances 0.000 description 1
- 230000007306 turnover Effects 0.000 description 1
- 230000003936 working memory Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6209—Protecting access to data via a platform, e.g. using keys or access control rules to a single file or object, e.g. in a secure envelope, encrypted and accessed using a key, or with access control rules appended to the object itself
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/33—User authentication using certificates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/31—User authentication
- G06F21/33—User authentication using certificates
- G06F21/335—User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
- G07B17/00—Franking apparatus
- G07B17/00733—Cryptography or similar special procedures in a franking system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
- H04L9/3265—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate chains, trees or paths; Hierarchical trust model
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2211/00—Indexing scheme relating to details of data-processing equipment not covered by groups G06F3/00 - G06F13/00
- G06F2211/009—Trust
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2145—Inheriting rights or properties, e.g., propagation of permissions or restrictions within a hierarchy
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2147—Locking files
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
- G07B17/00—Franking apparatus
- G07B17/00733—Cryptography or similar special procedures in a franking system
- G07B2017/00741—Cryptography or similar special procedures in a franking system using specific cryptographic algorithms or functions
- G07B2017/00758—Asymmetric, public-key algorithms, e.g. RSA, Elgamal
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
- G07B17/00—Franking apparatus
- G07B17/00733—Cryptography or similar special procedures in a franking system
- G07B2017/00741—Cryptography or similar special procedures in a franking system using specific cryptographic algorithms or functions
- G07B2017/00758—Asymmetric, public-key algorithms, e.g. RSA, Elgamal
- G07B2017/00766—Digital signature, e.g. DSA, DSS, ECDSA, ESIGN
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
- G07B17/00—Franking apparatus
- G07B17/00733—Cryptography or similar special procedures in a franking system
- G07B2017/00741—Cryptography or similar special procedures in a franking system using specific cryptographic algorithms or functions
- G07B2017/00782—Hash function, e.g. MD5, MD2, SHA
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
- G07B17/00—Franking apparatus
- G07B17/00733—Cryptography or similar special procedures in a franking system
- G07B2017/00927—Certificates, e.g. X.509
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/34—Encoding or coding, e.g. Huffman coding or error correction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- Computer Hardware Design (AREA)
- Accounting & Taxation (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Finance (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Storage Device Security (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Collating Specific Patterns (AREA)
- Credit Cards Or The Like (AREA)
Description
- Die Erfindung betrifft ein System und ein Verfahren zur verschlüsselten Kommunikation. Insbesondere betrifft die Erfindung ein Verschlüsselungssystem mit bekanntem Schlüssel oder Unterschrift mit einer verbesserten digitalen Beglaubigung der digitalen Unterschrift zum Anzeigen der Identität, der Befugnis- und Verantwortlichkeitsstufen im Zusammenhang mit wenigstens dem Sender einer digitalen Nachricht.
- Die schnelle Zunahme von elektronischen Postsystemen, elektronischen Geldübertragungssystemen und dergleichen hat das Interesse an der Sicherheit von über ungesicherte Kommunikationskanäle übertragenen Daten erhöht. Weit gebräuchlich sind Verschlüsselungssysteme zum Sicherstellen der Geheimhaltung und Authentizität von über derartige ungesicherte Kanäle ausgetauschten Nachrichten.
- In einem herkömmlichen Verschlüsselungssystem ist ein Verschlüsselungsverfahren zum Umwandeln einer Klartextnachricht in eine unverständliche Nachricht verwendet. Anschließend ist ein Entschlüsselungsverfahren zum Dekodieren der verschlüsselten Nachricht zum Wiederherstellen der Nachricht in ihre ursprüngliche Form verwendet.
- Herkömmliche Unterschrifts- und Authentizitätsverschlüsselungssysteme verwenden üblicherweise eine Hash-Funktion "in einer Richtung" zum Umwandeln der Klartextnachricht in eine Form, die unleserlich ist. Eine dabei verwendete "Hash"-Funktion ist eine Funktion, die auf einen Datenverbund angewendet wird, um einen kleineren, einfacher zu verarbeitenden Datenverbund zu erzeugen.
- Eine wichtige Eigenschaft der Hash-Funktion ist, daß sie eine "in eine Richtung" wirkende Funktion ist. Ein Hash ist eine "unidirektionale" Funktion, die rechentechnisch einfach zu verarbeiten ist, um die zugrundeliegenden Daten zu liefern. Die Hash-Funktion sollte in nicht nachzuberechnender Weise einen Hash-Wert liefern, um entweder die zugrundeliegenden Daten zu bestimmen oder Daten mit dem bestimmten Wert als Hash zu erzeugen. In allen praktischen Belangen ist der bei der Anwendung der Hash-Funktion auf den ursprünglichen Datenverbund erzeugte Wert ein eindeutiger, unvergänglicher Fingerabdruck der ursprünglichen Daten. Wenn die ursprünglichen Daten in irgendeiner Weise verändert sind, ist der Hash von derart abgeänderten Daten verschieden.
- In herkömmlichen Verschlüsselungssystemen wird die binär kodierte Information in eine unleserliche, Chiffrierung genannte Form verschlüsselt und in ihre ursprüngliche Form entschlüsselt, wobei ein Algorithmus verwendet ist, der durch Chiffrierungs- und Dechiffrierungsoperationen mit einem Binärcode arbeitet, der Schlüssel genannt ist. Beispielsweise hat das National Bureau of Standards im Jahr 1977 einen als Datenverschlüsselungsstandard (DES) bezeichneten Blockchiffrierungsalgorithmus empfohlen (Data Encryption Standard, FIPS PUB 46, National Bureau of Standards, 15. Januar 1977).
- Im DES ist der binär kodierte Datensatz durch Anwendung des DES-Algorithmus in Verbindung mit einem Schlüssel verschlüsselungsmäßig geschützt. Jedes Mitglied einer Gruppe von befugten Benutzern von verschlüsselten Computerdaten muß den Schlüssel besitzen, der zum Chiffrieren des Datensatzes benutzt wurde, um diesen zu benützen. Dieser durch jedes Mitglied gemeinschaftlich gehaltene Schlüssel wird zum Dechiffrierung der von anderen Mitgliedern der Gruppe in chiffrierter Form empfangenen Daten verwendet.
- Der zur Benutzung in bestimmten Anwendungen gewählte Schlüssel macht die Ergebnisse des Verschlüsselns von Daten unter Verwendung des DES-Algorithmus eindeutig. Die Auswahl eines anderen Schlüssels führt bei einem gegebenen Satz von Eingaben zu einer verschiedenen Chiffrierung. Nichtbefugte Empfänger des chiffrierten Textes, die den DES-Algorithmus kennen, den geheimen Schlüssel aber nicht besitzen, können die ursprünglichen Daten nicht mit einem Algorithmus ableiten.
- Demzufolge hängt die Verschlüsselungssicherheit der Daten von der auf den Schlüssel zum Chiffrieren und Dechiffrieren der Daten aufgewendeten Sicherheit ab. Wie in den meisten herkömmlichen Verschlüsselungssystemen hängt die letztendliche Sicherheit des DES-Systems empfindlich von der Geheimhaltung des Verschlüsselungsschlüssels ab. Durch das DES-System definierte Schlüssel weisen 64 Binärstellen auf, von denen 56 unmittelbar durch den DES-Algorithmus als signifikante Stellen des Schlüssels und acht Bits zur Feststellung von Fehlern verwendet sind.
- Bei derartigen herkömmlichen Verschlüsselungssystemen müssen einige Sicherheitsmaßnahmen zum Verteilen eines geheimen Schlüssels vom dem Absender der Nachricht zu dem Empfänger angewendet werden. Demzufolge ist eine der Hauptschwierigkeiten im Zusammenhang mit bestehenden Verschlüsselungssystemen die für den Sender und Empfänger bestehende Notwendigkeit, einen einzigen Schlüssel derart auszutauschen, daß ein nichtbefugter Dritter keinen Zugang zu dem Schlüssel hat.
- Der Austausch eines derartigen Schlüssels wird häufig durch Senden des Schlüssels vor Austausch der Nachricht über beispielsweise Privatbriefe oder eingeschriebene Post bewerkstelligt. Zwar schaffen derartige Techniken zur Verteilung des Schlüssels die notwendige Sicherheit, sie sind jedoch langsam und teuer. Wollen der Sender und Empfänger lediglich eine vertrauliche Nachricht auszutauschen, kann dies durch einen Privatbrief oder über eingeschriebene Post geschehen, so daß dadurch die verschlüsselte Kommunikation überflüssig ist. Weiterhin führt bei der Notwendigkeit einer schnellen, privaten Kommunikation die zum Verteilen des privaten Schlüssels erforderliche Zeit zu einer inakzeptablen Verzögerung.
- Verschlüsselungssysteme mit einem bekannten Schlüssel lösen viele der mit herkömmlichen Verschlüsselungssystemen verbundenen Probleme bei der Verteilung des Schlüssels. In Verschlüsselungssysteme mit bekanntem Schlüssel sind die Verschlüsselungs- und Entschlüsselungsvorgänge derart entkoppelt, daß der Schlüssel für den Verschlüsselungsvorgang getrennt und verschieden von dem Schlüssel für den Entschlüsselungsvorgang ist. Somit gibt es für jeden Verschlüsselungsschlüssel einen zugehörigen Entschlüsselungsschlüssel, der nicht der gleiche wie der Verschlüsselungsschlüssel ist. Bei Kenntnis des Verschlüsselungsschlüssels ist es nicht möglich, den Entschlüsselungsschlüssel zu berechnen.
- Bei einem System mit bekanntem Schlüssel ist es möglich, vertraulich miteinander zu kommunizieren, ohne irgendwelche geheimen Schlüssel auszutauschen. Das System mit bekannten Schlüssel erfordert, daß ein Paar von Verschlüsselungs- und Entschlüsselungsschlüsseln erzeugt ist. Die Verschlüsselungsschlüssel für alle Benutzer können verteilt oder veröffentlicht werden und jede(r), die (der) zu kommunizieren wünscht, verschlüsselt ihre (seine) Nachricht mit dem bekannten Schlüssel des Empfängers.
- Allein der Zielbenutzer, der den geheimen Entschlüsselungsschlüssel hält, ist dazu in der Lage, die übermittelte Nachricht zu dechiffrieren. Ein Zugriff auf den Verschlüsselungsschlüssel offenbart nichts Verwertbares über den Entschlüsselungsschlüssel, das heißt, es können lediglich Personen mit der Kenntnis der Entschlüsselung die Nachricht entschlüsseln. Das RSA-Verschlüsselungssystem, das in dem Rivest et al. erteilten US-Patent Nummer 4,405,829 offenbart ist, offenbart beispielhaft das Vorgehen für eine praktische Implementierung eines Verschlüsselungssystemes mit bekanntem Schlüssel.
- Ein Hauptproblem bei Verschlüsselungssystemen mit bekannten und anderen Schlüsseln besteht in der Notwendigkeit zu bestätigen, daß der Sender der empfangenen Nachricht tatsächlich die in der Nachricht genannte Person ist. Eine bekannte, die Authentizität prüfende Technik, die "digitale Unterschriften" verwendet, gestattet einem Benutzer die Anwendung seines geheimen Schlüssels zum "Unterschreiben einer Nachricht", die der empfangende Teilnehmer oder ein Dritter unter Benutzung des bekannten Schlüssels des Autors für gültig erklären kann (siehe beispielsweise US-Patent Nummer 4,405,829).
- Mit der Hinzunahme von derartigen digitalen Unterschriften ist nun das Unterzeichnen von jeder digitalen Nachricht möglich, so daß der Empfänger sichergestellt ist, daß die Nachricht wie abgesendet empfangen und daß sie keine Fälschung ist. Dies wird durch Verwendung einer digitalen Unterschriftsvorgehensweise mit "bekanntem Schlüssel" bewerkstelligt, wie es unter anderem in dem Patent 4,405,829, nachfolgend als RSA-Technik bezeichnet, beschrieben ist. Es gibt andere Techniken mit bekanntem Schlüssel und Unterschrift, die andere Vorgehensweisen als die gemäß RSA verwenden. Beispiele anderer Techniken mit bekanntem Schlüssel oder Unterschrift sind Fiat-Shamir, Ong-Schnorr-Shamir und verschiedene andere, die von Nullkenntnisprüfungstechniken abgeleitet sind. Während keine dieser anderen Techniken die Vertraulichkeitseigenschaften von RSA aufweist, gestatten sie jedoch digitale Unterschriften. Die vorliegende Erfindung ist nicht auf eine besondere Technik mit bekanntem Schlüssel oder Unterschrift beschränkt.
- Ein Benutzer, der einen bekannten Schlüssel in einem frei zugänglichen Datensatz abgelegt hat, kann digital eine Nachricht durch "Entschlüsseln" (oder "Unterschreiben") der Nachricht oder eines Hash von ihr mit dem privaten Schlüssel des Benutzers vor Absenden der Nachricht unterzeichnen. Empfänger der Nachricht können die Nachricht oder die Unterschrift durch deren Verschlüsseln mit dem bekannten Verschlüsselungsschlüssels des Absenders für gültig erklären. Somit ist der digitale Unterschriftsvorgang im wesentlichen die Umkehrung des üblichen Verschlüsselungsvorganges, bei dem die Nachricht zuerst entschlüsselt und dann verschlüsselt ist. Jeder, der den bekannten Verschlüsselungsschlüssel des Benutzers besitzt, kann die Nachricht oder Unterschrift lesen, aber nur der Absender, der die geheime Entschlüsselung besitzt, kann die Nachricht oder Unterschrift erzeugt haben.
- Im allgemeinen stellt die digitale Unterschrift für den Empfänger den ordnungsgemäßen Zustand der Nachricht zu dem Zeitpunkt sicher, an dem die Unterschrift berechnet worden ist. Allerdings ist die Authentizität des Unterzeichners nur soweit sichergestellt, daß der Empfänger versichert ist, daß der zum Unterzeichnen der digitalen Nachricht verwendete bekannte Schlüssel tatsächlich zu dem besagten Sender gehört. Diese Tatsache wird bei einer weiter verbreiteten Anwendung von digitalen Unterschriften immer wichtiger, und die verschiedenen Korrespondenzpartner (möglicherweise auf andere Art und Weise nicht miteinander bekannt) erhalten gegenseitig die bekannten Schlüssel über zentral abgelegte "Verzeichnisse" (oder andere Mittel).
- Somit bestehen in Verschlüsselungssystemen mit bekanntem Schlüssel weiterhin Probleme sicherzustellen, daß ein bestimmter bekannter Schlüssel tatsächlich der durch ein bestimmtes Individuum erzeugte ist. Ein bekannte Technik zum Lösen dieses Problemes ist das Vertrauen auf eine vertrauenswürdige Autorität, wie beispielsweise eine Verwaltungsdienststelle, um sicherzustellen, daß jeder bekannte Schlüssel mit der Person verbunden ist, die beansprucht, der wahre Autor zu sein.
- Die vertrauenswürdige Autorität erzeugt eine digitale Nachricht, die den bekannten Schlüssel und den Namen des Beanspruchers enthält (der im Rahmen der Sorgfalt der Autorität richtig ist), und ein Vertreter der Autorität unterzeichnet die digitale Nachricht mit der eigenen Unterschrift der Autorität. Diese digitale Nachricht, die häufig als Zertifikat bezeichnet wird, wird mit der Benutzung der eigenen digitalen Unterschrift des Beanspruchers versendet. Jeder Empfänger der Nachricht des Beanspruchers kann der Unterschrift vertrauen, vorausgesetzt, daß der Empfänger den bekannten Schlüssel der Autorität (der eine Überprüfung der Unterschrift der Autorität gestattet) anerkennt, und in soweit, daß der Empfänger der Autorität vertraut.
- Zertifikate können als kurze Nachrichten angesehen werden, die durch die vertrauenswürdige Autorität unterzeichnet sind und die entweder explizit oder implizit einen Bezug auf den bekannten Schlüssel, der damit beglaubigt ist, und die Identität des Eigentümer des bekannten Schlüssels (Erzeuger) aufweisen. Wenn bei einer derartigen Implementierung "C" eine Bestätigung für "A" schafft, dann kann Empfänger "B" der Benutzung des bekannten Schlüssels von "A" vertrauen, vorausgesetzt, daß "B" dem "C" vertraut und daß "B" die Bestätigung von "C" des bekannten Schlüssel von "A" besitzt.
- In herkömmlichen Kommunikationssystemen schafft das übermittelte Zertifikat keinen Hinweis auf den Vertrauensgrad oder die Verantwortlichkeitsstufe, mit der der Absender der Nachricht ausgestattet ist. Statt dessen zeigt die Bestätigung lediglich an, daß die identifizierte vertrauenswürdige Autorität den bekannten Schlüssel des Absenders als zu dieser Person gehörig anerkennt.
- Das System mit bekanntem Schlüssel ist für einen Betrieb ausgelegt, bei dem die bekannten Schlüssel verschiedener Benutzer veröffentlicht sind, um die vertrauliche Kommunikation einfacher ausführbar zu machen. Wenn jedoch die Anzahl der Teilnehmer zunimmt, die das System mit bekanntem Schlüssel zu verwenden wünschen, nimmt die Anzahl der veröffentlichten Schlüssel zu einer Größe zu, bei der die die Schlüssel ausgebende Autorität nicht zuverlässig sicherstellen kann, daß die Teilnehmer, deren bekannte Schlüssel veröffentlicht sind, tatsächlich die Personen sind, für die sich ausgeben. So kann ein Dritter dafür sorgen, daß in dem frei zugänglichen Verzeichnis unter dem Namen des Vorsitzenden eines größeren Unternehmens, beispielsweise der General Motors Corporation, ein bekannter Schlüssel aufgeführt ist. Ein derartiges Individuum kann dann in die Lage versetzt sein, an den Vorsitzenden von General Motors gerichtete, vertrauliche Nachrichten zu empfangen oder vorgeblich zu dem personifizierten Vorsitzenden gehörende Unterschriften zu erzeugen.
- Es gibt ebenso Technologien zum Herstellen von digitalen Unterschriften, wie beispielsweise der Fiat-Shamir- Algorithmus, die keine vollständig Fähigkeit für bekannte Schlüssel erfordern. Jeder Bezug auf Verschlüsselungssysteme mit einem bekannten Schlüssel sollte ebenso im Hinblick auf Unterschriftssysteme angesehen werden. Jeder Bezug auf eine Entschlüsselung mit bekanntem Schlüssel sollte als ein allgemeiner Hinweis auf eine Unterschriftserzeugung und jeder Bezug auf eine Verschlüsselung sollte als ein Hinweis auf eine Gültigerklärung von Unterschriften verstanden werden.
- Der vorliegende Anmelder hat sich derartigen Problemen bei Verschlüsselungssystemen mit bekanntem Schlüssel oder Unterschrift in Bezug auf die Authentifizierung der Identität des Besitzers des bekannten Schlüssels durch Steigerung der Leistungsfähigkeit der digitalen Unterschriftsüberprüfung, wie weiter unten und in der EP 0 327 232 A beschrieben, zugewendet. Dazu ist eine Vorgehensweise zur Beglaubigung verwendet, die eine Beglaubigung auf einer Vielzahl von Ebenen gestattet, während gleichzeitig die "Befugnis" des Individuums, dessen Unterschrift zu beglaubigen ist, wie weiter unten im Detail erläutert, angezeigt ist. Ein Hinweis auf die "Befugnis" wird hierbei im weiten Sinne auf jeden Hinweis der Vollmacht, Kontrolle, Autorisation, Delegationsverantwortungen oder dabei wirksamen Beschränkungen durch die Verwendung von digitalen Unterschriften oder Zertifikaten verstanden.
- Das in der EP 0 328 232 A beschriebene System verbessert die Möglichkeiten der Verschlüsselung mit bekanntem Schlüssel, so daß es bei einer größeren Vielzahl von geschäftlichen Transaktionen anwendbar ist, auch bei denjenigen, bei denen die beiden Parteien miteinander praktisch nicht bekannt sind.
- Das System schafft vorteilhafterweise die Möglichkeit, eine Vielzahl von mit dem Zertifikat verbundenen Zusätzen zu spezifizieren. Diese Zusätze gehen über das alleinige Sicherstellen des korrekten Identifizierens eines Individuums hinaus und spezifizieren wirksam die Befugnis oder die Beschränkungen (in einer großen Vielzahl von Situationen), die dem zu Beglaubigenden durch den Beglaubiger verliehen sind.
- So erlaubt das System beispielsweise einem Unternehmen nicht nur zu bestätigen, daß ein bestimmter bekannter Schlüssel durch einen bestimmten Angestellten verwendet ist, sondern gestattet dem Unternehmen auch explizit die Befugnis, die dem Individuum im Zusammenhang mit seiner Anstellung erteilt worden ist, und die Benutzung dieses Schlüssels im Namen des Unternehmens anzugeben.
- Die Typen und Arten der erteilten Befugnis sind nicht beschränkt. In dem System ist eine digitale Unterschrift in der Art beglaubigt, daß die Befugnis, die der zu beglaubigenden Partei (dem Beglaubigten) erteilt wurde, angezeigt ist. Bei dem Bilden eines Zertifikates erzeugt der Beglaubiger eine spezielle Nachricht, die Felder einschließt, welche den zu beglaubigenden, bekannten Schlüssel identifizieren sowie den Namen und andere Identifikationsmerkmale des zu Beglaubigenden einschließen. Zusätzlich schließt das durch den Beglaubiger gebildete Zertifikat die erteilte Befugnis und Beschränkungen sowie Sicherheiten ein, die auferlegt sind, wobei Informationen enthalten sind, wie beispielsweise das finanzielle Limit für den zu Beglaubigenden und die Vertrauensstufe, die dem zu Beglaubigenden erteilt sind, die dem Beglaubiger wichtige Punkte widergespiegeln. Das Zertifikat kann ebenso Erfordernisse einer Kounterzeichnung angeben, die dem zu Beglaubigenden auferlegt sind. Einige der üblichen Arten einer Befugnis und/oder dabei zu berücksichtigender Beschränkungen sind nachfolgend zusammengefaßt.
- Ein Zertifikat kann den finanziellen Betrag einschließen, über den ein beglaubigter Angestellter unter Benutzung einer besonderen digitalen Unterschrift verfügen kann. Eine derartige Beschränkung wird bei der Zunahme von elektronisch über digitale Netzwerke ausgeführten Geschäften immer wichtiger. Da diese Beschränkung in das Zertifikat "eingebaut" ist, ist jedem Empfänger gestattet, sofort zu wissen, ob zum Beispiel eine digital unterschriebene Kaufbestellung gültig ist.
- Digitale "Kounterzeichnungen" können immer dann benutzt werden, wenn ein bestimmter beglaubigter, bekannter Schlüssel verwendet ist. Der Begriff "Kounterzeichnung" ist benutzt, um sowohl "Mitunterschrift" als auch "Gegenzeichnung" zu umfassen. Wie hierin benutzt sind Mitunterschriften Unterschriften, die direkt zu dem gleichen "Gegenstand" (zum Beispiel eine Kaufbestellung von Dokumenten) abgegeben sind, während Gegenzeichnungen Unterschriften sind, die in Bezug auf eine andere Unterschrift erstellt sind. Grundsätzlich können Mitunterschriften parallel in beliebiger Reihenfolge erstellt werden, während eine Gegenzeichnung eine bereits bestehende Unterschrift in besonderer Weise ratifiziert. Demzufolge schafft die Methode und das Verfahren zur digitalen Unterschriftsbeglaubigung eine Hierarchie von Zertifikaten und Unterschriften. Bezüglich den Erfordernissen der Kounterzeichnung sind in jedem digitalen Zertifikat Erfordernisse der Gegenzeichnung und Mitunterschrift eingeschlossen, um das elektronische Abwickeln von geschäftlichen Transaktionen zu gestatten, die hierzu häufig erst stattfinden würden, wenn sich wenigstens ein Beteiligter seinen Weg durch eine Unternehmensverwaltung bahnt. Dies gestattet es, einer Organisation beispielsweise die gängige Praxis der Erfordernis einer Vielzahl von Unterschriften zum Bevollmächtigen von Ausgaben (oder jedem anderen sensiblen Zweck, der als angemessen angesehen wird) zu minimieren. Da dieses Erfordernis in das digitale Zertifikat gemäß der vorliegenden Erfindung eingebaut ist, ist dem Empfänger bekannt, wenn (ein oder mehrere) Kounterzeichnungen notwendig sind, und der Empfänger (oder das Datenverarbeitungsprogramm des Empfängers) kann feststellen, ob die notwendigen passenden Kounterzeichnungen vorhanden sind.
- Das System gemäß der EP 0 328 232 A führt weiterhin zu einer Beglaubigung von digitalen Unterschriften derart, daß das Erfordernis für weitere beglaubigende Mitunterschriften für jeden Empfänger einer digitalen Nachricht offengelegt ist. Das Erfordernis von Mitunterschriften ist insbesondere beispielsweise in Transaktionen zweckmäßig, bei denen Geld zu übertragen oder eine Freigabe zu autorisieren ist. Um diesen Zweck zu erfüllen, ist das Zertifikat derart gebildet, daß (zusätzlich zu dem bekannten Schlüssel und dem Namen des Bestätigenden sowie weiterer Felder) die Anzahl von erforderlichen Mitunterschriften und ein Hinweis auf die Identität zur Ausweisung von Mitunterzeichnern widerzuspiegeln. Somit kann eine explizite Liste von jedem der anderen Besitzer eines bekannten Schlüssels, die zum gemeinsamen Unterzeichnen erforderlich sind, in dem Zertifikat enthalten sein. Auf diese Weise ist der Empfänger davon in Kenntnis gesetzt, daß jegliches Material, das durch die bevollmächtigende Stelle des Zertifikates des Senders unterzeichnet ist, ebenso durch eine Anzahl von anderen vorbestimmten Unterzeichnern unterschrieben sein muß. Der Empfänger ist damit in die Lage versetzt, weitere Mitunterschriften und Gegenzeichnungen durch einfaches Vergleichen der in jeder Unterschrift in dem Zertifikat vorhandenen bekannten Schlüsseln zu überprüfen. Die hierin offenbarte Erfindung schließt weiterhin andere Wege des Hinweises auf Erfordernisse einer Kounterzeichnung ein, wie beispielsweise dem Bezug auf andere Zertifikate. Derartige Hinweise auf andere Besitzer von bekannten Schlüsseln können explizit (mit einer hierin beschriebenen Liste) oder implizit durch das Festlegen von einem anderen Zusatz oder einer Angliederung erfolgen. Dieser Zusatz oder diese Angliederung kann auch in dem Zertifikat jedes Kounterzeichners angezeigt sein.
- Es können auch "Freigabe"stufen in das Zertifikat eingebaut sein. Beispielsweise gestattet dies dem Militär (oder jeder anderen auf Sicherheit bedachten Organisation) Sicherheit in ihre Zertifikate einzuschließen. Diese Maßnahme gestattet die Bestätigung der genauen Sicherheitsstufe der Person, die die unterschriebene Nachricht erzeugt hat.
- Umgekehrt und möglicherweise von größerer Bedeutung ist die Möglichkeit, eine zusätzliche Kontrollstufe beim Absenden digitaler Nachrichten zu schaffen: beim Verschlüsseln der Nachrichten (ein Vorgang, der ebenso den bekannten Schlüssel des Empfängers und demzufolge das Zertifikat des Empfängers erfordert) ist das Computersystem in der Lage sicherzustellen, daß alle Empfänger die sicherheitsmäßige Befugnis zum Empfang einer besonderen, sensible Information enthaltenden Nachricht haben.
- Zusätzlich können digitale Unterschriften so bestätigt sein, daß dem Empfänger eine Vertrauensstufe zum Ausführen von Unterbeglaubigungen erteilt ist. Auf diese Weise ergibt sich eine Vertrauensstufe bezüglich der Verantwortlichkeit von einer zentralen Vertrauenswürdigen Quelle.
- In einem Beispiel ist es dem Unterzeichner gestattet, mit einem einzigen vorbestimmten, digitalen Code mit einer Vertrauensstufe zu zeichnen, die anzeigt, daß der Beglaubiger gewährleistet, daß der in dem Zertifikat genannte Benutzer dem Beglaubiger bekannt und zur Benutzung des damit verbundenen bekannten Schlüssels berechtigt ist. Vermöge dieses digitalen Codes jedoch ist der Benutzer (Beglaubigte) nicht berechtigt, jegliche weitere Angaben oder Beglaubigungen im Namen des Beglaubigers vorzunehmen. Andererseits kann der Beglaubiger ein Zertifikat ausgeben, das anzeigt, daß der Benutzer des bekannten Schlüssels zur genauen Identifikation anderer Personen im Namen des Unterzeichners ermächtigt ist und (möglicherweise) weiterhin dazu ermächtigt ist, diese Befugnis bei entsprechender Beurteilung durch den Benutzer zu delegieren.
- Der bekannte Schlüssel des Benutzers kann auf mehrere Arten und Weisen (beispielsweise mit Zertifikaten von verschiedenen Beglaubigern) bestätigt werden. Die entsprechenden Zertifikate können als Teile der von dem Benutzer unterzeichneten Nachricht eingeschlossen sein. Derartige Zertifikate schließen ein Zertifikat des Beglaubigers des Unterzeichners und des Beglaubigers des Beglaubigers und so weiter bis zu einem vorbestimmten Zertifikat (oder einem Satz von gegenseitig aufeinander bezugnehmenden Kozertifikaten) ein, dem von allen beteiligten Parteien vertraut wird. Wenn dies ausgeführt ist, enthält jede unterzeichnete Nachricht eindeutig die Hierarchieleiter der Zertifikate und die Unterschriften, die die Befugnis des Senders anzeigen. Ein Empfänger einer derart unterzeichneten Nachricht kann diese Befugnis derart überprüfen, daß geschäftliche Transaktionen auf der Grundlage einer Analyse der unterzeichneten Nachricht zusammen mit der vollständigen Hierarchie der Zertifikate sofort durchführbar sind.
- Es ist möglich, ein großes System oder Gruppen von Systemen mit einer maximalen Kontrolle hierarchisch zu verwalten, was die Möglichkeit von Fehlern, Korruption, Täuschungen oder nachteiligen Unterbrechungen minimiert.
- Da die Zertifikate nicht nur einfache Identifikationen, sondern ebenso die Befugnis mit Einschränkungen und Beschränkungen einschließlich einer finanziellen Befugnis vermitteln, ist es äußerst wichtig, daß die Beglaubigung genau vollzogen und sorgfältig kontrolliert wird. In einer großen Organisation (oder einer Gruppe von Organisationen wird es immer schwieriger, zentral die Identität von jedem einzelnen zu bestätigen (ganz zu schweigen von deren Befugnis). Weiterhin tritt ein konstanter Wechsel auf. Es ist notwendig, Angestellten Zertifikate bei einem Wechsel ihres Status neu zu erteilen. Eine aufgegliederte hierarchische Verwaltung kann zum Erfüllen dieser Erfordernisse eingeschlossen sein.
- Beschränkungen und Verantwortlichkeit von Hierarchie zu Hierarchie können derart auferlegt sein, daß der Empfänger einer mit einem derartigen (hierarchisch abgeleiteten) Zertifikat unterzeichneten Nachricht sichergestellt ist, daß die durch den Unterzeichner repräsentierte Befugnis genau nachgewiesen ist.
- Dies ist wie folgt ausführbar:
- 1) den Einschluß der Feststellung (in einer durch einen Computer einfach zu überprüfenden Form, ebenso durch eine menschliche Bestätigung) der Kompetenzen, der Befugnisse und Beschränkungen, die erteilt sind, als ein Teil jedes Zertifikates;
- 2) in jedem Zertifikat das Festsetzen der Kompetenzen und Befugnisse, die dem Beglaubiger weiter hierarchisch zu erteilen gestattet ist (falls überhaupt);
- 3) falls von Bedeutung kann bei der Erteilung einer bedeutsamen oder sensiblen Befugnis einschließlich der Kompetenz zum Erteilen der Befugnis zu einer noch weiteren Stufe oder die Kompetenz zur Befugnis in Geldangelegenheiten oder anderen sensiblen Bereichen das Erfordernis von mehrfachen Unterschriften (Kounterzeichnung) festgesetzt sein; derartige Kounterzeichnungen können explizit (durch Bezug auf andere Zertifikate oder Schlüssel) oder implizit (durch Angabe einer Klasse von Zertifikaten oder bekannten Schlüsseln beziehungsweise durch eine abstrakte Anordnung oder Identifikation) angezeigt sein; dies erfordert eine Kontrolle und Gegenkontrolle, wechselseitige Entscheidungen und eine automatische Regelung, wenn sensible Kompetenzen ausgeübt werden; dies erhöht ebenso die Integrität des gesamten Systems durch Herabsetzen der Möglichkeit, daß Korruption auftritt, und falls sie auftritt ein Minimieren und Eingrenzen von jeglichem Schaden; die Gefahr einer Absprache kann immer durch Heraufsetzen der Anzahl von notwendigen Kounterzeichnern gemindert werden;
- 4) in großen Organisationen kann die Vertraulichkeit von bekannten Schlüsseln gelegentlich beeinträchtigt werden (möglicherweise durch Unachtsamkeit ihrer Eigentümer) und es kann notwendig sein, Aufhebungsvermerke innerhalb eines Netzwerkes auszugeben.
- Zuvor war dafür der einzig praktikable Weg für den Ersteller eines Zertifikates (dem Beglaubiger), das Zertifikat aufzuheben. Ansonsten könnte ein böswilliger oder auf Schaden erpichter Teilnehmer falsche Aufhebungsvermerke erzeugen und durch fälschlicherweises Aufheben von Zertifikaten argloser Benutzer Chaos hervorrufen.
- Die Aufhebung kann in einer aufgeteilten Art und Weise kontrolliert sein, so daß der tatsächliche Ersteller eines Zertifikates nicht in jedem Fall der Stornierer sein muß. Dies gestattet es, die "Überwachungs"kompetenz auf sichere Art und Weise zu regeln, ohne jedoch die ständige Hinzuziehung derjenigen zu erfordern, die die Zertifikate erzeugen und deren Genauigkeit sicherstellen.
- Es ist eine Verfahrensweise geschaffen, bei der mehrere Objekte, wie beispielsweise ein Anschreiben, ein zugehöriger Anlagebrief, ein zugehöriger Graphikdatensatz und so weiter in einer Art und Weise zusammen unterzeichnet werden können, daß jedes Objekt einzeln überprüfbar ist und ebenso die Beziehung des einzelnen Objektes zu der gesamten Gruppe anzeigbar ist. Eine Aggregation von mit diesen Objekten verbundenen Daten (möglicherweise der Hash jedes dieser Objekte zusammen mit einer Kontrollinformation) ist in einer geordneten Liste zusammengefaßt. Diese geordnete Liste wird dann als ein Objekt betrachtet und unterzeichnet oder der Hash dieser Liste wird unterzeichnet. Die Liste zeigt an, daß der Unterzeichner einzeln die miteinander verbundenen Objekte ebenso wie ihren Zusammenhang in der Gruppe als gültig anerkennt. Somit ist jedes Element dieser geordneten Liste durch einen Hash-Algorithmus bearbeitet (um eine kompaktere Version davon zu erzeugen), die zu einer Liste von vorunterzeichneten Hash- Werten führt. Die vorunterzeichnete Hash-Liste durchläuft dann einen den Entschlüsselungs- (Unterschrifts-) Kreislauf, der zu der Unterschrift des Unterzeichners führt, die nachfolgend als Siegel bezeichnet wird, das ein Teil des weiter unten genauer beschriebenen Unterschriftspaketes wird.
- Die vorliegende Erfindung schafft eine Verfahrensweise zum digitalen Unterzeichnen von Dokumenten, bei der die Unterschrift sowohl für eine computergestützte Überprüfung als auch für eine erneute Überprüfung erzeugt ist, falls ein Dokument in der Zukunft durch dessen Wiedereingabe von einer Wiedergabe auf Papier erneut bestätigt werden muß. Um dieses Ziel zu erreichen sind in den digitalen Unterschriften von dokumentartigen Computernachrichten zwei Hash-Werte verwendet. Der erste Hash-Wert, der verwendet ist, bezieht sich auf die exakten Bit-für-Bit-Daten des Datensatzes. Dies gestattet eine Gültigerklärung des exakten Originaldokumentes, solange es in computerlesbarer Form zugänglich ist.
- Gemäß der vorliegenden Erfindung ist ein Verfahren zum digitalen Signieren einer zu übertragenden Nachricht in einem Kommunikationssystem zum Austausch von Nachrichten über einen Kommunikationskanal vorgesehen, bestehend aus den Schritten des Erzeugens eines Hash-Wertes der zu übertragenden Nachricht, der auf den zu übertragenden genauen Bit-für-Bit-Daten beruht, und gekennzeichnet durch die Schritte des Erzeugens eines Hilfs-Hash- Wertes, der zum Verifizieren der Echtheit einer gedruckten Fassung der Nachricht gebildet ist, und des Einschließens beider Hash-Werte als einen Teil der digitalen Unterschrift.
- Gemäß der vorliegenden Erfindung ist weiterhin eine Vorrichtung zum digitalen Signieren einer zu übertragenden Nachricht in einem Kommunikationssystem zum Austausch von Nachrichten über einen Kommunikationskanal geschaffen, bestehend aus Mittel zum Erzeugen eines Hash-Wertes der zu übertragenden Nachricht, der auf den zu übertragenden genauen Bit-für-Bit-Daten beruht, und gekennzeichnet durch Mittel zum Erzeugen eines Hilfs- Hash-Wertes, der zum Verifizieren der Echtheit einer gedruckten Fassung der Nachricht gebildet ist, und Mittel zum Einschließen beider Hash-Werte als einen Teil der digitalen Unterschrift.
- Die vorliegende Erfindung schafft einen zweiten Hilfs- Hash-Wert, der über die gesamten Daten in dem Datensatz genommen ist, außer daß die für den zweiten Hash-Wert verwendeten Daten bezüglich der Leerzeichen (beziehungsweise bezüglich des "Weißabstandes") normiert sind. Diese Leerzeichennormierung gestattet, falls in der Zukunft notwendig, eine Wiedereingabe der Daten von einem Ausdruck, ohne sich darum sorgen zu müssen, welche nicht druckbaren, unsichtbaren Steuerzeichen in dem Original existiert haben könnten.
- Es sei angemerkt, daß bei einer vorgegebenen Anwendung der bekannte Schlüssel, das Zertifikat und die digitale Unterschrift so ausgelegt sind, daß sie verschiedene, in gewisser Weise jedoch überlappende Funktionen ausführen. In dieser Hinsicht könnte möglicherweise in dem "bekannten" Schlüssel gewisse Eigenschaften von dem, was unter "Zertifikat" bezeichnet ist, eingeschlossen sein. Umgekehrt könnte das Zertifikat so gebildet sein, daß es den bekannten Schlüssel als einen Teil enthält. In ähnlicher Weise könnten einige Teile des Zertifikates und/oder des bekannten Schlüssels als ein Teil der Unterschrift inbegriffen sein. Diese Möglichkeit ist insbesondere dann zu berücksichtigen, wenn die Unterschrift zur Bevollmächtigung anderer Zertifikate angewendet ist. Somit sind die speziellen Ausführungsbeispiele, die in der nachfolgenden genauen Beschreibung aufgeführt sind, nicht als Beschränkungen der vorliegenden Erfindung auszulegen.
- Diese und andere Ausgestaltungen der Erfindung sind nach Studium der nachfolgenden Beschreibung von bevorzugten Ausführungsbeispielen der vorliegenden Erfindung in Verbindung mit der beiliegenden Zeichnung besser verständlich, wobei
- Fig. 1 ein Blockdiagramm eines Kommunikationssystems mit Verschlüsselung entsprechend einer beispielhaften Ausgestaltung der vorliegenden Erfindung ist,
- Fig. 2 ein Flußdiagramm ist, das darstellt, wie entsprechend einer beispielhaften Ausgestaltung der vorliegenden Erfindung eine digitale Unterschrift erzeugt ist,
- Fig. 3 ein Flußdiagramm ist, in dem dargestellt ist, wie eine entsprechend Fig. 2 erzeugte Unterschrift überprüft ist,
- Fig. 4 ein Flußdiagramm ist, das darstellt, wie für eine digitale Unterschrift eine Gegenzeichnung erzeugt ist,
- Fig. 5 ein Flußdiagramm ist, das darstellt, wie ein digitales Zertifikat entsprechend einer beispielhaften Ausgestaltung der vorliegenden Erfindung erzeugt ist,
- Fig. 6 ein Flußdiagramm ist, das darstellt, wie einem Zertifikat eine Mitunterschrift hinzugefügt ist,
- Fig. 7 ein Flußdiagramm ist, das darstellt, wie die Unterschriften und Zertifikate durch einen Empfänger der übermittelten Nachricht überprüft werden,
- Fig. 8 eine elektronisch zu übermittelnde beispielhafte Mitteilung ist, die einen digitalen Unterschriftsabschnitt aufweist,
- Fig. 9A und 9B Flußdiagramme sind, die die mit der Berechnung der Leerzeichen-Hash-Funktion verbundene Verarbeitung zeigen,
- Fig. 10 zeigt, wie ein Paket mit einer Vielzahl von Dokumenten entsprechend der vorliegenden Erfindung unterzeichnet ist,
- Fig. 11 zeigt, wie ein gedrucktes Dokument mit der Leerzeichen-Hash-Funktion erneut überprüfbar ist und
- Fig. 12 zeigt, wie eine Unterschrift für ein Paket mit mehreren Dokumenten/Datensätzen überprüft ist.
- Fig. 1 zeigt in der Form eines Blockdiagrammes ein beispielhaft ein Kommunikationssystem, das in Verbindung mit der vorliegenden Erfindung benutzbar ist. Dieses System weist einen ungesicherten Kommunikationskanal 12 auf, über den über Datensichtgeräte (Terminals) A, B ... N Übertragungen stattfinden können. Der Kommunikationskanal 12 kann beispielsweise eine Telefonleitung sein. Die Terminals A, B ... N können beispielsweise Kleinrechner mit einem Prozessor (mit Hauptspeicher) 2 sein, der an eine herkömmliche Tastatur sowie einen Bildschirm 4 angeschlossen ist. Jedes Terminal A, B ... N schließt weiterhin eine handelsübliche Datenübertragungskarte (nicht dargestellt) für IBM-Kleinrechner auf, die bei einem jeweiligen Anschluß an eine herkömmliche Datenübertragungseinrichtung (Modem) 6, 8, 10 den Terminals das Absenden und Empfangen von Nachrichten gestattet.
- Jedes Terminal ist dazu eingerichtet, einen Volltext oder eine unchiffrierte Nachricht zu erzeugen und einen beliebigen erforderlichen Unterschriftvorgang auszuführen sowie die Nachricht zu jedem der anderen Terminals zu übermitteln, die an den Kommunikationskanal 12 oder an ein nicht dargestelltes Kommunikationsnetzwerk, das mit dem Kommunikationskanal 12 verbunden sein kann, angeschlossen sind. Zusätzlich ist jedes der Terminals A, B ... N dazu eingerichtet, für jede Nachricht eine Unterschriftsüberprüfung auszuführen.
- Jeder der Terminalbenutzer (wie oben in Bezug auf das System mit bekanntem Schlüssel diskutiert) hat einen bekannten Verschlüsselungsschlüssel und einen zugehörigen privaten geheimen Entschlüsselungsschlüssel. In dem in Fig. 1 gezeigten Verschlüsselungssystem mit bekanntem Schlüssel ist jeder Terminalbenutzer von der allgemeinen Verfahrensweise, wie die anderen Terminalbenutzer eine Nachricht verschlüsseln, in Kenntnis gesetzt. Weiterhin ist jedem Terminalbenutzer der bei dem Verschlüsselungsvorgang des Terminals verwendete Verschlüsselungsschlüssel zum Erzeugen der chiffrierten Nachricht bekannt.
- Durch das Veröffentlichen des Verschlüsselungsvorganges und des Verschlüsselungsschlüssels gibt jeder Terminalbenutzer jedoch nicht seinen privaten Entschlüsselungsschlüssel bekannt, der zum Entschlüsseln der chiffrierten Nachricht und zum Erzeugen von Unterschriften notwendig ist. Diesbezüglich ist es auf rechnerische Art und Weise nicht möglich, den Entschlüsselungsschlüssel aus der Kenntnis des Verschlüsselungsschlüssels zu berechnen.
- Neben der Möglichkeit zum Übermitteln von privaten Nachrichten hat jeder Terminalbenutzer ebenfalls die Möglichkeit zum digitalen Unterzeichnen einer übermittelten Nachricht. Eine Nachricht kann durch einen Terminalbenutzer digital unterzeichnet werden, indem er eine Nachricht mit seinem privaten Entschlüsselungsschlüssel vor dem Übermitteln der Nachricht entschlüsselt. Bei Empfang der Nachricht kann der Empfänger die Nachricht durch Benutzen des bekannten Verschlüsselungsschlüssels des Absenders lesen. Auf diese Weise kann der Empfänger überprüfen, daß nur der Besitzer des geheimen Entschlüsselungsschlüssels die Nachricht erzeugt haben konnte. Somit hat der Empfänger der unterzeichneten Nachricht den Beweis, daß die Nachricht von dem Absender stammt. Weitere Einzelheiten eines beispieihaften digitalen Unterschriftsverfahrens, das in Verbindung mit der vorliegenden Erfindung benutzbar ist, ist in dem US- Patent Nummer 4,405,829 offenbart.
- Vor der Beschreibung von Einzelheiten der weiterentwickelten digitalen Beglaubigung gemäß der vorliegenden Erfindung ist zuerst die allgemeine Verfahrensweise nach Fig. 1 bei beispielsweise elektronischer Post im Zusammenhang mit einer Verschlüsselung mit bekanntem Schlüssel beschrieben. Zu Beginn sei angenommen, daß der Benutzer des Terminals A ein Angestellter auf einer unteren Hierarchieebene einer mit Rechenanlagen ausgestatteten Design-Gruppe von General Motors ist, der ein Softwarepaket von einem in einem anderen Land niedergelassenen Rechnerprogrammlieferanten zu erwerben wünscht. Der Rechnerprogrammlieferant hat in seinen Geschäft ein Terminal N und ein zugehöriges Modem 10.
- Der Angestellte von General Motors stellt am Terminal A eine elektronische Kaufbestellung zusammen, die den (die) zu erwerbenden Posten und die Adresse angibt, zu der die Posten zu senden sind, sowie weitere Angaben, die für eine übliche Kaufbestellung notwendig sind. Es sei angemerkt, daß trotz des Bezugs dieses Beispiels auf eine elektronische Kaufbestellung jede Datenaggregation, die in einer Verarbeitung mit irgendeiner Methode mit bekanntem Schlüssel zum Unterzeichnen darstellbar ist, ebenfalls übertragen werden kann. In der nachfolgenden genauen Beschreibung wird eine derartige Ansammlung von Daten, beispielsweise ein Datensatz einer Rechenanlage, im allgemeinen als ein "Objekt" bezeichnet.
- Der Benutzer des Terminals A, das heißt der Angestellte von General Motors, unterzeichnet digital die Kaufbestellung unter der Befugnis eines Zertifikates, das an die übermittelte Nachricht, wie weiter unten beschrieben, hinzugefügt ist. Bei Betrachtung zuerst der digitalen Unterschrift des Angestellten ist eine Nachricht durch Anwendung des vertraulich gehaltenen Unterschriftsschlüssels auf wenigstens einen Teil des zu unterzeichnenden Objektes "unterschreibbar". Durch Unterzeichnen eines Abbildes des Objektes (oder einer kompakteren Version davon, die als Auszug oder Hash des Objektes bekannt und weiter unten genauer erläutert ist,) mit einem geheimen Schlüssel ist es für jeden mit Zugriff auf den bekannten Schlüssel möglich, dieses Ergebnis zu "verschlüsseln" (das heißt umzukehren) und es mit dem Objekt (oder mit einem wiederberechneten Hash beziehungsweise einer Zahlenversion davon) zu vergleichen. Da einzig der Besitzer des bekannten Schlüssels den geheimen Schlüssel zum Ausführen dieses Vorganges benutzt haben konnte, ist dadurch der Besitzer des bekannten Schlüssels als Unterzeichner der Nachricht bestätigt. Es sei angemerkt, daß andere Verfahren als die "Verschlüsselung" für verschiedene Unterschriftsschemata wie Fiat-Shamir geeignet sind.
- Gemäß der vorliegenden Erfindung ist einer digitalen Unterschrift zusätzlich wenigstens ein gültiges Zertifikat beigefügt, das die Identität des Unterzeichners und die dem Unterzeichner erteilte Autorisation angibt. Das Zertifikat kann als ein besonderes Objekt oder eine Nachricht aufgefaßt werden, die die Identität des Benutzers eines spezifischen bekannten Schlüssels und die dem Benutzer von einem Dritten mit einer höheren Bevollmächtigungsstufe als die des Benutzers erteilte Befugnis angibt.
- Um gültig zu sein muß ein Zertifikat mit wenigstens einem bekannten Schlüssel unterzeichnet sein, der mit einem oder mehreren anderen gültigen Zertifikaten verbunden ist, die nachfolgend als Vorlaufteile zu diesem Zertifikat bezeichnet sind. Diese können weiterhin durch Beschränkungen und/oder Übertragungseinschränkungen begleitet sein, die erfüllt sein müssen (wie beispielsweise Kounterzeichnungen). Jedes dieser Vorlaufzertifikate muß dem Unterzeichner die Befugnis erteilen, eine derartige Unterschrift zu erzeugen und/oder in unserem Beispiel die Kaufbestellung zu tätigen. Diese können weiterhin durch Beschränkungen und/oder Übertragungseinschränkungen begleitet sein die erfüllt sein müssen (wie beispielsweise mit Kounterzeichnungen). Jedes dieser Vorlaufzertifikate kann wiederum sein(e) eigenen/s Vorlaufteil(e) haben.
- Bei einer beispielhaften Ausgestaltung der vorliegenden Erfindung ist vorgesehen, ein abschließendes Vorlaufzertifikat von allen Zertifikaten zu verwenden, das eine allgemeine bekannte und vertrauenswürdige Autorität, wie beispielsweise hypothetisch das National Bureau of Standards, ist und das als Meta-Zertifikat bezeichnet wird. Das Meta-Zertifikat ist das einzige Glied, das allgemein vertrauenswürdig und bekannt sein muß. Ein Meta-Zertifikat erfordert keine Unterschrift. Jedes Meta-Zertifikat wird als weitverbreitet und veröffentlicht angenommen. Es können mehrere Meta-Beglaubiger vorgesehen sein, und es ist möglich, daß mehrere Meta- Beglaubiger für erforderliche Mitunterschriften aufeinander Bezug nehmen.
- Die Benutzung von mehreren Meta-Beglaubigern kann für viele Anwendungen wichtig sein. Obwohl jeder der Meta- Beglaubiger anerkannt sein kann, muß jedes vielköpfige Unternehmen notwendigerweise die Gefahr von Korruption berücksichtigen. Durch das Erfordernis von mehreren Meta-Beglaubigern ist jeder Vorwurf "von oben" an alle unabhängig Beteiligten beim Erzeugen der höchststufigen Zertifikate jeder Organisation sowie jedes tatsächliche oder vermeintliche Risiko wesentlich herabgesetzt. Da weiterhin die Erfordernisse einer Kounterzeichnung innerhalb jeder Organisation nach angemessener Beurteilung jeder Organisation aufgestellt werden können, kann jede Organisation das Risiko von Korruption innerhalb ihrer eigenen Organisation kontrollieren.
- Zu unserem Beispiel zurückkehrend überprüft der Empfänger nach Übermittlung der Nachricht von Terminal A zu dem Rechnerprogrammlieferanten an Terminal N in einer weiter unten genauer beschriebenen Art und Weise die Unterschrift des Angestellten von General Motors. Zusätzlich überprüft er, daß alle anderen Unterschriften in dem Nachrichtenzertifikat und den Vorlaufzertifikaten vorhanden sind, was dem Rechnerlieferanten am Terminal N weitere Sicherheit gibt, daß der Geschäftsvorgang gültig und vollständig autorisiert ist. Es sei angemerkt, daß derartige Sicherheiten vor der Auslieferung von Gegenständen oder vielleicht noch wichtiger im Zusammenhang mit der elektronischen Übertragung von Geldmitteln besonders bedeutsam sind.
- Jeder Dritte, der die durch den Benutzer des Terminals A übermittelte Nachricht empfängt (entweder ein derartiger Dritter als der eigentliche Empfänger der Nachricht am Terminal N oder weitere Dritte innerhalb beispielsweise der Unternehmenshierarchie bei General Motors), kann die Unterschrift von A und die von dem Benutzer des Terminals A ausgeübte Befugnis überprüfen und für gültig erklären. Eine derartige Gültigerklärung ist möglich, da die vollständige Hierarchie von gültig erklärenden Zertifikaten mit der ursprünglichen Kaufbestellung übermittelt ist, was dem letztendlichen Empfänger gestattet, darauf zu vertrauen, daß der auszuführende Geschäftsvorgang echt und ordnungsgemäß autorisiert ist.
- Unter Bezug auf von beispielsweise der General Motors Corporation ausgehenden größeren Transaktionen ist es zweckmäßig, sich zuerst auf die oben genannten abschließenden Beglaubiger zu konzentrieren, das heißt die Meta-Beglaubiger. In dieser Hinsicht können General Motors und Dritte, die beabsichtigen, mit General Motor Geschäfte zu tätigen, oder sich auf andere Weise an dem Verschlüsselungssystems mit bekanntem Schlüssel zu beteiligen, wenden sich zu Beginn an eine allgemein anerkannte, vertrauenswürdige Autorität, wie beispielsweise hypothetisch das Bureau of Standards und/oder eine der landesweit größten Banken. Unternehmen und andere Teilnehmer in diesem System übergeben einen Satz von bekannten Schlüsseln (die sie vermöge einer Handlung ihrer Direktorenversammlung zu benutzen autorisiert sind) zusammen mit einer ausreichend substantiierten Dokumentation und Belegen den Meta-Beglaubigern. Dies sind "hochrangige" Schlüssel, die innerhalb der Umgebung von General Motors zum Beglaubigen des internen Personals von General Motors zu benutzen sind. Der Meta-Beglaubiger (oder jeder Meta-Beglaubiger) stellt General Motors seine Beglaubigung zu, daß jeder dieser zur Verfügung gestellten bekannten Schlüssel von ordnungsgemäßen Stellen von General Motors zu ihrer eigenen Benutzung erzeugt worden sind. Der Meta-Beglaubiger bestätigt effektiv, daß die den Schlüssel benutzende Partei tatsächlich mit General Motors verbunden ist. Die Beglaubigung des Meta-Beglaubigers kann einen eingebundenen Text umfassend daß die Benutzer der registrierten bekannten Schlüssel ordnungsgemäß mit General Motors verbunden sind. Beispielsweise kann General Motors entscheiden, drei bestätigte "hochrangige" Schlüssel zu haben, beispielsweise für Unternehmensvorstandsmitglieder wie den Vizepräsident, das für Finanzfragen zuständige Vorstandsmitglied und das für Sicherheitsfragen verantwortliche Vorstandsmitglied. Nach Wunsch von General Motors könnte jedes der drei Zertifikate so strukturiert sein, daß auf die bekannten Schlüssel der beiden anderen als erforderliche Mitunterschriften hingewiesen wird.
- Somit müssen nach Erhalt der(s) hochrangigsten Zertifikate(s) von dein Meta-Beglaubiger diese Bediensteten von General Motors gemeinsam Zertifikate für die nächstniedrige Stufe unterzeichnen. Üblicherweise würden diese hochrangigen Zertifikate von General Motors gegenseitig als erforderliche Kounterzeichner aufeinander Bezug nehmen. Somit kann auf dieser Ebene kein allein handelndes Unternehmensvorstandsmitglied irgendetwas vollständig autorisieren, da in jedem der drei Zertifikate ein Erfordernis der Unterzeichnung mit anderen eingeschlossen ist, die spezifisch angegeben sind. Andererseits erzeugen und unterzeichnen diese drei Vorstandsmitglieder bekannte Schlüssel für die anderen Angestellten von General Motors, die genau den Grad der Befugnis, die Verantwortlichkeit und die Beschränkungen jedes Angestellten festlegen. Eines dieser Zertifikate gehört zu dem Benutzer A oder ist ein Vorlaufteil zu dem Zertifikat des Benutzers von A.
- Jedes dieser drei hochrangigen Zertifikate unterzeichnet digital das Zertifikat des Benutzers von Terminal B, vorzugsweise nach einer direkten, unmittelbaren oder anderen persönlichen Überprüfungs- und Anerkennungs- bestätigung. Nachdem jede der erforderlichen Unterschriften erzeugt worden ist, sind die Unterschriften der Zertifikate des Vizepräsidenten, des Vorstandsmitgliedes für Finanzen und des mit der Sicherheit beauftragten Vorstandsmitgliedes sowie ihre jeweiligen drei Zertifikate und jeweiligen Zertifikatsunterschriften durch den Meta-Beglaubiger letztendlich zu dem Angestellten von General Motors am Terminal B zur laufenden Benutzung abgespeichert, so wie in unserem Beispiel für den untergeordnet beglaubigenden Terminalbenutzer A. Auf diese Weise enthält die unterzeichnete Nachricht eindeutig die Abstufung oder Hierarchie von Zertifikaten und Unterschriften, die die Identität des Benutzers von Terminal A und dessen Befugnis überprüfen.
- Wenn ein Mitglied B in einer Leiter von Zertifikaten ein autorisierendes Zertifikat für das Mitglied A erzeugt, schließt das Zertifikat eine Spezifizierung der Identität von A zusammen mit der bekannten Verschlüsselungsunterschrift/Schlüssel von A ein. Zusätzlich zeigt das Zertifikat die Befugnis, die Kompetenzen und Beschränkungen an, die B dem A zu erteilen wünscht. Durch das Erteilen dieses Zertifikates übernimmt B explizit die Verantwortung sowohl für die Identität und als auch die Befugnis von A.
- Das Zertifikat von B für A gestattet weiterhin eine Spezifizierung von weiteren Mitgliedern, die zum Kounterzeichnen von durch A vorgenommene Handlungen erforderlich sind, wenn dieses Zertifikat, wie weiter unten näher erläutert, benutzt ist. Kounterzeichnungen können entweder die Form von Mitunterschriften oder Gegenzeichnungen aufweisen. Weiterhin kann das Mitglied B in dem Zertifikat für A den Grad festlegen, bis zu dem B durch A ausgeführte Unterbeglaubigungen anerkennt.
- Gemäß einer beispielhaften Ausführung der vorliegenden Erfindung sind die von dem Beglaubiger dem Beglaubigten erteilten Vertrauensstufen in dem Zertifikat durch einen vorbestimmten digitalen Code spezifiziert. Eine derartige Vertrauensstufe ist für den Empfänger der Nachricht als ein Hinweis auf die dem Beglaubigten erteilte Befugnis und die von dem Beglaubiger übernommene Verantwortung für Handlungen des Beglaubigten bezüglich der Benutzung des beglaubigten bekannten Schlüssels verwendbar.
- Beispielsweise können Vertrauensstufen durch Vertrauensstufenwerte 0, 1, 2 und 3 angezeigt sein.
- Die Vertrauensstufe 0 zeigt an, daß der Beglaubiger verbürgt, daß der beglaubigte bekannte Schlüssel zu dem in dem Zertifikat genannten Individuum gehört, aber daß der Beglaubiger keine Verantwortung für die Richtigkeit von durch den Beglaubigten erzeugten Zertifikaten übernimmt. Die Quintessenz davon wäre eine Erklärung des Beglaubigers wie folgt: "Ich garantiere, daß der in dem Zertifikat genannte Benutzer mir bekannt und zum Benutzen des zugehörigen bekannten Schlüssels überprüft worden ist, allerdings vertraue ich ihm nicht an, in meinem Namen irgendwelche weiteren Identifikationen vorzunehmen".
- Die Vertrauensstufe 1 ermächtigt den Beglaubigten, im Namen des Beglaubigers Beglaubigungen gemäß Stufe 0 vorzunehmen. Die Quintessenz davon wäre eine Erklärung des Beglaubigers wie folgt: "Ich kenne den Benutzer dieses bekannten Schlüssels und ich vertraue ihm/ihr die richtige Identifizierung anderer Personen in meinem Namen an. Ich werde die Verantwortung für derartige Identifikationen übernehmen. Allerdings vertraue ich dieser Person nicht an, derart identifizierten Personen als selbst vertrauenswürdig zu beurteilen".
- Die Vertrauensstufe 2 ermächtigt den Beglaubigten, im Namen des Beglaubigers Beglaubigungen gemäß 0, 1 und 2 zu machen. Die Quintessenz davon wäre eine Erklärung des Beglaubigers wie folgt "Ich kenne den Benutzer dieses bekannten Schlüssels. Weiterhin vertraue ich ihm/ihr die richtige Identifikation anderer Personen an und ich vertraue ihnen weiterhin die Delegation dieser Befugnis nach ihrer eigenen Urteilsfähigkeit an. Ich übernehme volle Verantwortung für jegliche von ihnen ausgeführte Beglaubigungen oder jeden von ihnen ordnungsgemäß autorisierten Angestellten oder einer anderen Erzeugung von ordnungsgemäß bestellten Angestellten".
- Die Vertrauensstufe 3 ist ausschließlich für einen abschließenden Meta-Beglaubiger vorbehalten, dessen bekannter Schlüssel und Zertifikat erstellt worden sowie wohlbekannt ist (möglicherweise durch wiederholte und weitverbreitete Publikation in Medien) und dessen Richtigkeit allgemein respektiert ist. Dieser Beglaubiger übernimmt lediglich Verantwortung für die richtige Identifizierung von Einheiten, deren bekannte Schlüssel er beglaubigt. Er übernimmt keine Verantwortung für die Benutzung dieser Schlüssel.
- Ein Beglaubiger kann ebenso andere Personen dazu ermächtigen, die Zertifikate aufzuheben, die der Beglaubiger erzeugt hat. Üblicherweise ist angenommen, daß jeder Beglaubiger dazu in der Lage ist, ein Zertifikat aufzuheben oder zu widerrufen, an dem er beteiligt gewesen ist. Üblicherweise wird auch angenommen, daß es einem Beglaubigten gestattet ist, sein eigenes Zertifikat zu widerrufen, wenn er Grund hat anzunehmen, daß es gefährdet ist. Zusätzlich ist die vorliegende Erfindung dahingehend ausgeLegt, irgendwelche Personen davon auszuschließen, ihre Unterschrift einem existierenden Zertifikat anzuhängen (in diesem Falle würden sie so erscheinen, als ob sie für dessen Aufhebung befugt wären). Die vorliegende Erfindung fügt einem Zertifikat ein Hash eines bekannten Schlüssels oder Zertifikates eines originären Unterzeichners ebenso wie einen Hinweis (allgemein entweder der Hash des bekannten Schlüssels oder Zertifikates, aber auch andere abstrakte Identifikationsmerkmale oder Gruppencodes) auf die andere Einheit hinzu, die ebenso zum Unterzeichnen des Zertifikates berechtigt sind. Die anderen Unterzeichner müssen alle für den Unterzeichneten festgelegten Kompetenzen ordnungsgemäß autorisieren. Die vorliegende Erfindung sieht das Erzeugen von Zertifikaten vor, die Kompetenzen so verteilt, daß kein einzelner Beglaubiger sie vollständig besitzt.
- Für Beglaubiger kann es vorteilhaft sein, anderen (ausgewählten) Benutzern zu gestatten, in ihrem Namen "Aufsichts"kompetenzen ausüben zu können. Die beispielhafte Ausgestaltung benutzt hierfür eine Methode, bei der ein Zertifikat von dem (den) Beglaubiger(n) erteilte Aufsichtskompetenz (das heißt zur Löschung) widerspiegelt. In dieser Ausgestaltung sind Löschungskompetenzen von den oben festgelegten "Identifikations"vertrauensstufen verschieden. In einer Ausführung der Erfindung kann ein Beglaubiger eine von vier Löschungskompetenzen erteilen:
- 0 - dem Benutzer ist keine spezielle Möglichkeit zum Löschen anderer durch den Beglaubiger kontrollierter Zertifikate erteilt,
- 1 - der Benutzer ist in der Lage, alle Zertifikate, die der Beglaubiger aufheben kann, zu löschen (Gegenstand von Einschränkungen, die mitgeteilt werden können),
- 2 - ähnlich wie 1, außer daß der Benutzer in der Lage ist, die erteilte Löschungsbefugnis zu delegieren (der Benutzer kann jedoch nicht die Kompetenz zu weiterer Verpflichtung delegieren) und
- 3 - ähnlich wie 2, außer daß der Benutzer ebenfalls die Möglichkeit zum (vollständigen) Delegieren abtreten kann.
- Derartige Löschungskompetenzen können alternativ mit den Vertrauensstufen verbunden sein. Somit können beispielsweise die Vertrauensstufe 1 oder 2 eine zugeordnete Kompetenz zum Löschen eines Zertifikates beinhalten.
- Auf diese Weise ist die Kompetenz zur Löschungskontrolle verteilt, so daß der Ersteller des Zertifikates nicht notwendigerweise immer der Löscher sein muß. Es kann alternativ eine gesonderte Vertrauensstufe gebildet sein, die lediglich die Kompetenz zum Löschen von Zertifikaten beinhaltet.
- Zusätzlich können bei einer Benutzung in einer Organisation, die mit extrem sensiblen geschäftlichen oder militärischen Informationen zu tun hat, in dem Zertifikat Freigabestufen definiert sein. Auf diese Art und Weise kann ein Zertifikat die genaue Sicherheitsstufe der Person angeben, die eine unterzeichnete Nachricht autorisiert hat.
- Weiterhin kann jede Bestätigung das finanzielle Limit, das heißt den Maximalbetrag eines Geldwertes angeben, über den der Beglaubigte zu verfügen autorisiert ist. Das finanzielle Limit darf natürlich nicht das Limit in dem dem Beglaubiger zugeordneten Zertifikat überschreiten, um sicherzustellen, daß der Beglaubiger nicht mehr delegiert als ihm zur Verfügung gestellt ist. Eine derartige Beschränkung ist in einfacher Weise auferlegbar, wenn ein Empfänger den Satz von Zertifikaten erhält.
- Vor der Diskussion weiterer Details der digitalen Unterschrift und Beglaubigungstechniken gemäß der vorliegenden Erfindung ist es zweckmäßig, zuerst eine gewisse Terminologie zu definieren. Wie oben erwähnt, ist der Begriff "Objekt" im wesentlichen zum Beschreiben jeglicher Datenaggregation benutzt, die letztlich in einer Art darstellbar ist, die für eine Verarbeitung nach einer Methode mit bekanntem Schlüssel, die für Unterschriften und/oder Verschlüsselungen Verwendung findet. Der Begriff "Objekt" kann auf ein "primäres" Objekt wie eine Kaufbestellung oder einen Scheck, Geldtransfer oder ein Zertifikat beziehungsweise auf ein "sekundäres" Objekt, nämlich eine andere Unterschrift, angewendet werden.
- Zum Steigern der Effizienz der Verarbeitung ist in der Verfahrensweise gemäß der vorliegenden Erfindung allgemein eine Funktion auf das Objekt angewendet, um ein im allgemeinen kleineres, kompakteres, einfacher zu verarbeitendes Objekt, das heißt typischerweise festdimensionierte Bitdaten mit einigen Dutzend oder mehr Bits, zu erzeugen. Eine derartige Funktion wird als Hash oder Auszug des Objektes bezeichnet. Eine derartige Funktion ist jedoch nicht zwingend notwendig, und jede andere eindeutige Darstellung des Objektes einschließlich des exakten Objektes selbst kann verwendet werden.
- Ein Beispiel eines derartigen Hash oder Auszuges wäre das durch Verarbeitung eines Bildes des Objektes mit dem Datenverschlüsselungsstandard (Data Encryption Standard, DES) unter Verwendung des Chiffrierblockkettenmodus (Cipher Block Chaining Mode, CBC) erreichte Ergebnis. Die Verarbeitung kann durch zwei verschiedene DES- Schlüssel (die beide festgelegt, nicht geheim und allgemein bekannt sind) durchgeführt werden. Danach wird jeder der abschließenden Ausgangskettenwerte verkettet oder verschmolzen, beispielsweise durch eine Exklusiv- ODER-Operation, um die mehrere Dutzend oder mehr Bits zu erhalten, die den Auszug- oder Hash-Wert bilden. Ein anderes als "Square-Mod-N"-Verfahren bekanntes Hash- Verfahren ist in dem X.500-Überprüfungskonzept beschrieben.
- Eine wichtige Eigenschaft des Auszugs- oder Hash-Algorithmus ist, daß es bei einer einfachen Berechnung des Auszuges eines Objektes im Prinzip unmöglich ist, ein verschiedenes oder verändertes Objekt mit einem gleichen Auszug zu konstruieren. Für alle praktischen Belange ist der Auszug ein unverfälschbarer, eindeutiger Fingerabdruck des Originalobjektes. Wenn das Originalobjekt in irgendeiner Art und Weise verändert wird, ist der Auszug verschieden. Für alle praktischen Belange ist mit anderen Worten die kompaktere Darstellung des Originalobjektes in Bezug auf das Originalobjekt selbst eindeutig. Idealerweise sollte ein Hash keinen Anhaltspunkt auf die in der Nachricht enthaltenen spezifischen Datenwerte enthalten. Die in der beispielhaften Ausgestaltung in Betracht gezogenen Hashs weisen wenigstens 128 Bits auf.
- Fig. 2 zeigt den Datenfluß und die Art und Weise, in der Unterschriften erzeugt werden. Der Unterschriftsvorgang ist nicht nur auf allgemeine Objekte, wie beliebige Computerdatensätze, Briefe, elektronische Kaufbestellungen und so weiter, sondern auch auf spezielle Objekte wie Unterschriften und Zertifikate anwendbar.
- Jede digitale Unterschrift ist, wie in Fig. 2 dargestellt, durch eine Beglaubigung des die Unterschrift ausführenden bekannten Schlüssels begleitet. Das Zertifikat ist, wie in Verbindung mit Fig. 5 genau beschrieben wird, durch eine oder mehrere höhere Stellen (das heißt die urnnittelbaren Beglaubiger) unterzeichnet und identifiziert den ursprünglichen Unterzeichner unter Angabe des Grades der Befugnis, der dem ursprünglichen Unterzeichner erteilt worden ist.
- Gemäß der vorliegenden Erfindung kann der Originalunterzeichner mehr als ein Zertifikat haben und verschiedene Zertifikate für verschiedene Befugnisstufen verwenden. Jedes der Zertifikate kann verschiedene Beschränkungen und Erfordernisse einschließlich verschiedener finanzieller Beschränkungen, Vertrauensstufen, Erfordernisse von Mitunterschrift und von Gegenzeichnung beinhalten.
- Es obliegt dem Unterzeichner die geeignete Unterschrift/Zertifikat auszuwählen, mit dem ein besonderes Objekt zu unterzeichnen ist. Beispielsweise kann eine Kaufbestellung eine andere Art von Befugnis (und damit ein anderes Zertifikat) als ein einfacher Nachfragebrief erfordern. Somit ist das Zertifikat dadurch ein sehr wichtiger Teil der übermittelten Nachricht, daß es den Unterzeichner als auch den Befugnisgrad des Unterzeichners angibt.
- Wie in Fig. 2 dargestellt verwendet der Benutzer beim Erzeugen der Unterschrift das Objekt 20 (das beispielsweise eine Kaufbestellung sein kann) und gibt den Objekttyp 22 an. Die dem Objekttypfeld hinzugefügte Dokumentation zeigt beispielsweise an, daß das Objekt ein Kaufbestellungsdatensatz ist. Unter anderen Bedingungen würde das Objekttypfeld 22 angeben, daß das Objekt eine andere Unterschrift oder ein Zertifikat ist. Wie dem Bezugszeichen 24 angedeutet ist das Datum der Unterschrift ebenfalls angegeben.
- Das Kommentarfeld 26 ist zum Hinzufügen einer Dokumentatioin verwendet, die beispielsweise Beschränkungen der Unterschrift angibt oder weiteren Kommentar hinzufügt. Der Unterzeichner kann darauf hinweisen, daß seine Unterzeichnung des Objektes lediglich für eine vorbestimmte Zeitdauer wirksam und gültig ist. Zusätzlich können gewünschte Kommentare in Bezug auf die betreffende Transaktion, beispielsweise die Kaufbestellung, als Kommentardaten hinzugefügt werden.
- In der Unterschrift ist ebenfalls das Zertifikat 28 des Originalunterzeichners eingeschlossen, welches den bekannten Schlüssel 30 des Originalunterzeichners und zahlreiche andere Felder einschließt, die im Detail weiter unten in Bezug auf die Fig. 5 diskutiert sind. Wie oben erwähnt erfordern die Unterschriftsmethoden mit bekanntem Schlüssel die Benutzung eines bekannten Schlüssels 30 und eines zugeordneten Privaten Schlüssels, der in Fig. 2 mit dem Bezugszeichen 32 gekennzeichnet ist.
- Das Objektfeld 20 (beispielsweise Kaufbestellungsdaten), das Objekttypfeld 22, das Unterschriftsdatumfeld 24, das Kommentarfeld 26 und das Zertifikatfeld 28 des Unterzeichners sind mit Hilfe der Streuspeichertechnik über einen mit den Bezugszeichen 34 gekennzeichneten Hash- Algorithmus abgebildet, um die Effizienz der Bearbeitung zu erhöhen. Weiterhin ist jedes der Felder 44, 22, 24, 26 in dem Unterschriftspaket 42 eingeschlossen, um ein Teil des Unterschriftssatzes zu werden. Auf das Objekt 20 ist auch ein Hash-Algorithmus 44 angewendet, um es vor dem Einschließen in das Paket 42 in eine kompaktere Form zu bringen.
- Nach Anwendung des Hash-Algorithmus 34 auf die oben genannten Felder ergibt sich daraus ein mit dem Bezugszeichen 36 gekennzeichneter Vorunterschrifts-Hash. Der Vorunterschrifts-Hash 36 durchläuft einen mit dem Bezugszeichen 38 gekennzeichneten Entschlüsselungs- (Unterschrifts-) Zyklus unter Benutzung des privaten Schlüssels 32 des Unterzeichners, so daß daraus sich die Unterschrift des Unterzeichners ergibt, die nachfolgend als Siegel 40 bezeichnet ist.
- Wenn diese Unterschrift mit dem zugeordneten Objekt übermittelt ist, gestattet sie dem Empfänger zu überprüfen, daß das Objekt wie unterzeichnet intakt ist. Weiterhin kann der Empfänger, wenn genügend Zertifikate eingeschlossen sind, die wahre Identität des Unterzeichners und die Befugnis überprüfen, die in der Kette von Zertifikaten des Unterzeichners erteilt worden ist.
- Fig. 3 zeigt, wie der Empfänger der übermittelten Nachricht mit dem gemäß Fig. 2 gebildeten Unterschriftspaket 42 die Unterschrift überprüft. Wie in Fig. 3 dargestellt verwendet der Empfänger das Unterschriftspaket 42 sowie die zugehörigen Felder 44, 22, 24, 26, 28 und wendet den gleichen Hash-Algorithmus 34 wie auf die gleichen Felder gemäß Fig. 2 angewendet an, so daß sich daraus ein Vorunterschrifts-Hash 50 ergibt.
- Der Empfänger verwendet dann den bekannten Verschlüsselungsschlüssel, der mit dem Zertifikat 28 des Unterzeichners übermittelt worden ist, und führt eine Verschlüsselungs- (Überprüfungs-) Operation 52 auf das zu überprüfende Siegel 40 an (das mit dem Unterschriftspaket übermittelt worden ist), so daß dadurch ein Vorunterschrifts-Hash 54 erzeugt ist. Der Empfänger vergleicht dann durch erneutes Berechnen des Vorunterschrifts-Hash in der gleichen Art und Weise wie der Unterzeichner dessen Wert mit der Verschlüsselung (Überprüfung) der Unterschrift des Unterzeichners.
- Wenn, wie in dem Kasten 56 dargestellt, diese beiden Werte 50 und 54 nicht gleich sind, kann der Empfänger die empfangene Unterschrift nicht als gültig anerkennen. Das Objekt und/oder die Unterschrift müssen absichtlich oder auf andere Art und Weise seit ihrer Unterzeichnung geändert oder verfälscht worden sein. Vermöge dieses Überprüfungsschrittes bestimmt der Unterzeichner, ob das digitale Signal mit dem angeführten bekannten Schlüssel konsistent ist.
- Auf diese Weise werden das Objekt und sein Siegel verarbeitet, um sicherzustellen, daß das Objekt identisch zu den Daten ist, die bei Unterzeichnen durch den Besitzer des bekannten Schlüssels vorgelegen haben.
- Andere Schritte des Überprüfungsprozesses stellen sicher, daß der bekannte Schlüssel zu der Person gehört, die in dem zugeordneten Zertifikat genannt ist, und daß die Person die in dem Zertifikat festgesetzte Befugnis hat. Dieser Überprüfungsprozeß wird allgemeinen auf jedes Objekt angewendet, auch wenn das Objekt eine weitere Unterschrift oder ein Zertifikat ist. Zum Vervollständigen des Überprüfungsprozesses analysiert der Empfänger die mit der Unterschrift verbundenen Zertifikate, um zu bestimmen, daß über die Unterschriften und das (die) vorangehende(n) Zertifikat(e) dieser bevollmächtigenden Unterschriften jedem Zertifikat die richtige Befugnis übertragen worden ist.
- Ein Objekt kann durch mehr als eine Unterschrift begleitet sein. Derartige Kounterzeichnungen fallen in die Kategorie entweder einer Mitunterschrift oder einer Gegenzeichnung. Eine Mitunterschrift ist einfach eine weitere Unterschrift eines Objektes durch eine weitere Partei. Der Unterschriftsvorgang ist von dem, der wie in Verbindung mit Fig. 2 beschrieben zum Erzeugen der ursprünglichen Unterschrift verwendet worden ist, nicht verschieden.
- Eine Gegenzeichnung ist eine Unterschrift einer Unterschrift. Wenn demzufolge A ein Objekt unterzeichnet, kann diese Unterschrift selbst als ein Objekt angesehen werden. Wenn daher C die Unterschrift von A gegenzeichnet, ist das Objekt, das C unterzeichnet, die Unterschrift von A und nicht das ursprüngliche Objekt. Die Gegenzeichnung muß daher nach der gegenzuzeichnenden Unterschrift erfolgen und spiegelt die Anerkennung (oder wenigstens Kenntnisnahme) von sowohl dem zugrundeliegenden Objekt als auch der Tatsache, das A dieses Objekt unterzeichnet hat, wider. Dieser Mechanismus gestattet die Kontrolle einer Kette von Befugnissen, wobei jede höhere Stufe durch eine niedrigere Stufe eingegangene Verpflichtungen bestätigt. Einer der einzigartigen Aspekte dieses Systems ist, daß das mit dieser Unterschrift verbundene Zertifikat A in der Tat erfordern kann, daß die Benutzung der Unterschrift von A durch bestimmte andere Mitunterschriften oder Gegenzeichnungen begleitet sein muß.
- Unter Bezug auf die in Fig. 4 dargestellte Erzeugung einer Gegenzeichnung unterzeichnet anfänglich A bei dem Bezugszeichen 63 ein Primärobjekt 60 gemäß der in Verbindung mit Fig. 2 im Detail dargestellten Prozedur. Das Primärobjekt 60 kann eine Kaufbestellung, irgendeine andere Verpflichtung oder eine Gegenzeichnung irgendeiner anderen Unterschrift eines Primärobjektes sein.
- Wie oben bezüglich Fig. 2 erläutert, kann der Unterzeichnungsvorgang eines Objektes von A ebenso das Unterzeichnen der Unterschrift von A durch eine weitere Stelle einschließen. Somit gibt das Zertifikat 62 von A an dem Bezugszeichen 65 an, daß für die Gültigkeit der Unterschrift von A (das heißt der Ratifizierung) eine Gegenzeichnung durch C erforderlich ist, beispielsweise durch die Benutzung des spezifischen Zertifikates Y von C.
- Nach der Unterzeichnung des Objektes durch A wird das Unterschriftspaket 66 von A zusammen mit dem Primärobjekt und allen zugeordneten Unterschriften und Zertifikaten zu C weitergeleitet, und A beantragt, daß C seine Gegenzeichnung 64 hinzufügt. Bei Empfang des Materials sieht C alle vorhandenen Unterschriftszertifikate sowie das Primärobjekt durch und wenn alles seine Zustimmung findet, würde er entscheiden, die Unterschrift 68 von A gegenzuzeichnen. Die Unterschrift von A spiegelt naturgemäß das Primärobjekt wieder, und die Unterschrift von C spiegelt naturgemäß die Unterschrift von A wieder, so daß C im wesentlichen "in der Zeile unterhalb der Unterschrift von A unterzeichnet".
- Wenn C entschieden hat, die Unterschrift von A bei dem Bezugszeichen 68 zu bestätigen, ist der Prozeß bei der Erzeugung einer Unterschrift, wie im Detail in Fig. 2 dargestellt, wiederholt, außer daß das Objekt die Unterschrift von A ist. Somit wird mit der Unterschrift von A als Objekt (und der Art des Objektes, das mit dem Bezugszeichen 72 als eine Unterschrift gekennzeichnet ist) das Datum 74 der Gegenzeichnung, die Anmerkung 76 zu der Gegenzeichnung von C und das Zertifikat 70 von C einem Hash-Algorithmus 80 unterworfen, der in einem Vorunterschrifts-Hash 82 resultiert. Gleichzeitig werden diese Felder in das Gegenzeichnungspaket 68 wie oben unter Bezug auf das Unterschriftspaket 42 beschrieben (mit einem auf das Unterschriftsobjekt angewendeten Hash- Algorithmus 69) hinzugefügt.
- Der Vorunterschrifts-Hash 82 und der geheime Schlüssel 92 von C sind in einer Unterschriftsoperation 84 angewendet, um ein Gegenzeichnungssiegel 86 zu erzeugen. Dieses Gegenzeichnungssiegel wird genau in der gleichen Art und Weise, wie oben unter Bezug auf die Erzeugung des Unterschriftspakets 42 in Fig. 2 beschrieben, ein Teil des Gegenzeichnungspakets 88.
- Da das Zertifikat "Y", das C zum Ausführen der Unterschrift benutzen muß, ausdrücklich genannt ist (in dem Zertifikat, das A zum Unterzeichnen benutzt), hat C möglicherweise ebenso seine eigenen Kounterzeichnungsverpflichtungen zu erfüllen, die durch "Y" angegeben sind, und leitet das gesamte Paket mit seiner neu hinzugefügten Unterschrift an andere Stellen für weitere Kounterzeichnungen (entweder Mitunterschriften oder Gegenzeichnungen) weiter. Dieser rekursive Unterschriftensammelvorgang setzt sich fort, bis genügend Unterschriften zum vollständigen Erfüllen aller Kounterzeichnungserfordernisse von wenigstens einer Stelle, die ursprünglich das Primärobjekt unterzeichnet hat, hinzugefügt sind.
- Bei der nunmehr folgenden Darstellung, wie eine Stelle ein bevollmächtigendes Zertifikat für eine andere erzeugt, sei festgestellt, daß B ein bevollmächtigendes Zertifikat für A erzeugt, indem eine Angabe der Identität von A zusammen mit dem bekannten Verschlüsselungsschlüssel, den A für sich erzeugt hat, miteinander kombiniert sind. Zusätzlich gibt B die Befugniskompetenzen und Beschränkungen an, die B dem A zu erteilen wünscht. Durch das Unterzeichnen des Zertifikates übernimmt B explizit die Verantwortung für die Identität und Befugnis von A.
- Die vorliegende Erfindung gestattet B, andere Unterzeichner anzugeben, die zum Kounterzeichnen von durch A bei Benutzung der Bestätigung vorgenommenen Handlungen erforderlich sind. Wie oben erwähnt kann B in dem Zertifikat für A weiterhin den Grad angeben, bis zu dem B von A ausgeführte Unterbeglaubigungen anerkennen will.
- Zusätzlich können zahlreiche andere Beschränkungen und Einschränkungen durch B auferlegt werden. Beispielsweise kann B ein finanzielles Limit auferlegen, das sicherstellt, daß jeder Empfänger des Zertifikates von A das von B willentlich zugestandene Limit zur Kenntnis bekommt. Da der Prozeß des Erzeugens von einem Zertifikat, wie weiter unten gezeigt werden wird, Unterschriften einschließt, ist die Benutzung von Kounterzeichnungen zum Gestatten von Beglaubigungsbefugnissen erweitert. Beispielsweise können Zertifikate zum Gestatten der Delegation von Unterbeglaubigungen ausgestaltet sein, jedoch nur, wenn eine bestimmte Anzahl von mehreren Kounterzeichnern involviert ist. Dies gestattet in eine Hierarchie von Befugnissen eingebaute Kontrollen und Gegenkontrollen, so daß elektronische digitale Unterschriften über Organisations- und institutionale Grenzen hinweg mit einer großen Vertrauenswürdigkeit sowohl für die die Unterschrift empfangenden Stellen als auch für die die Befugnisse zum Benutzen der Unterschriften erteilenden Stellen verwendbar sind.
- Die Art und Weise, wie eine Partei B ein Zertifikat für eine Partei A erzeugt, ist in Fig. 5 dargestellt. Wie mit dem Bezugszeichen 100 gekennzeichnet erzeugt A ein Paar von bekannten/privaten Schlüsseln gemäß herkömmlichen Unterschriftssystemen mit bekanntem Schlüssel und stellt B den bekannten Schlüssel, wie durch das Bezugszeichen 102 angezeigt, zur Verfügung. Wenn B den von A zur Beglaubigung zur Verfügung gestellten bekannten Schlüssel erhält, ist es für B wichtig sicherzustellen, daß der bekannte Schlüssel tatsächlich ein von A erzeugter Schlüssel ist und nicht von jemandem, der sich für A ausgibt. Diesbezüglich kann es für den von A erzeugten bekannten Schlüssel erwünscht sein, auf einem direkten Weg übergeben zu werden.
- Nach Auswahl des eigenen Zertifikates, mit dem das Zertifikat von A zu unterzeichnen ist, verwendet B bei dem Bezugszeichen 106 das Zertifikat 108 mit dem zugeordneten bekannten Schlüssel 110, um die Unterschrift eines neuen Zertifikates 112 zu erzeugen. Gemäß Fig. 2 ist die Unterschrift durch Verwendung eines Objektes (das Zertifikat 116 von A) und eines Zertifikates (das Zertifikat 108 von B) erzeugt. Der geheime private Schlüssel von B ist in dem Entschlüsselungsvorgang zum Erzeugen der Unterschrift 112 des neuen Zertifikates 116 verwendet, und das Unterschriftspaket 114 der Unterschrift von B wird ein Teil des neuen Zertifikatpaketes von A.
- Bezug nehmend auf das Zertifikat für A, das unter Benutzung von durch B angegebene Information über A konstruiert ist, bildet B das Zertifikat durch Verwendung des bekannten Teiles des bekannten Schlüssels von A, wie er von A über die Leitung 103 zur Verfügung gestellt worden ist. B gibt den vollen Namen von A, den Titel von A und weitere wichtige Angaben wie dessen Adresse und Telefonnummer an. B kann weiterhin einen mit der Bestätigung mitübertragenen Kommentar einschließen, der für jede Person, die in der Zukunft das Zertifikat von A zu untersuchen hat, verfügbar ist.
- B kann weiterhin einen Ablauftermin für das Zertifikat angeben. Dieser Termin spiegelt das Datum wider, nach dem A das Zertifikat nicht mehr benutzen kann. Alternativ kann das Datum jedes von A erzeugte Zertifikat als zu diesem Termin abgelaufen kennzeichnen. B kann in dem Zertifikat weiterhin eine Eintragungsnummer für A angeben, die ein interner Identifikationscode innerhalb der Organisation von B darstellt.
- Weiterhin kann B in dem Zertifikat ein finanzielles Limit angeben. Diese finanzielle Befugnis oder das Kreditlimit wird gegenüber dem Limit in dem eigenen Zertifikat von B überprüft, um sicherzustellen, daß B nicht mehr delegiert als er zu delegieren befugt ist. Diese gleiche Beziehung wird von zukünftigen Empfängern als ein Teil ihres Vorganges zur Gültigerklärung überprüft.
- Wie oben beschrieben gibt B ebenso den Grad an Verantwortlichkeit an, den B für von A ausgeführte Unterbeglaubigungen zu übernehmen bereit ist. Dieser Bereich muß mit der Vertrauensstufe, die in dem eigenen Zertifikat von B gestattet ist, in Übereinstimmung sein. Die Beziehung zwischen der B erteilten Vertrauensstufe und der durch B erteilten ist eine andere der für gültig erklärten Beziehungen, wann immer zukünftige Empfänger die Hierarchie von Zertifikaten, die ihnen vorgelegt sind, für gültig erklären. Wie oben beschrieben können eine oder mehrere der Vertrauensstufen eine zugeordnete Befugnis zum Löschen von Zertifikaten tragen. Alternativ kann eine besondere Vertrauensstufe mit einer Befugnis zum Löschen von Zertifikaten vorgesehen sein. Weiterhin kann, wie oben beschrieben, ein Sicherheitsstufenfeld verwendet sein, um Stufen von Sicherheitsfreigaben in dem Zertifikat einzuschließen.
- B fügt Kounterzeichnungserfordernisse in das Zertifikat von A ein, um anzugeben, wieviele und welche Art von Kounterzeichnungen in Verbindung mit der Unterschrift von A erforderlich sind, wann immer A dieses neue Zertifikat benutzt. Wie oben erwähnt können Kounterzeichnung die Form von Mitunterschriften und/oder Gegenzeichnungen aufweisen. Die Gegenzeichnung gibt eine Zustimmung zu der Benutzung eines Zertifikates an, und die Zustimmung folgt zwangsweise der zugeordneten Unterschrift nach. Mitunterschriften können in beliebiger Reihenfolge ausgeführt werden und spiegeln nicht notwendigerweise die Zustimmung der anderen Unterschriften wider, sondern lediglich die Zustimmung (oder das Anerkenntnis) eines gemeinsamen Objektes.
- Kounterzeichnungserfordernisse können beispielsweise auf verschiedene Art und Weisen in dem Zertifikat angegeben sein. Eine anwendbare Technik ist es, explizit eine Liste von gültigen Mitunterschreibern und eine Liste von gültigen Gegenzeichnern mit deren bekanntem Schlüssel oder Zertifikatsidentifikation zu bilden. Mit jeder Liste verbunden ist eine das Minimum von zugeordneten Unterschriften angebende Zahl, die angegeben sein muß, um für einen Empfänger erkennbar zu machen, daß die Unterschrift vollständig genehmigt ist, wobei diese Zahl zwischen eins und unendlich liegen kann. Die Mitunterschriftsliste kann ein Vektor von Hash-Werten jedes Satzes von anderen bekannten Schlüsseln oder bestimmten Zertifikaten sein. Eine angegebene Minimalanzahl von diesen Schlüsseln muß in den Zertifikaten von anderen auf das von A unterzeichnete Objekt angewandten Unterschriften auftauchen, wenn dieses neue Zertifikat benutzt wird. Andernfalls darf ein Empfänger die Unterschrift von A nicht als gültig behandeln.
- Die Gegenzeichnungsliste kann ein Vektor von Hash-Werten der anderen Beglaubigungen mit bekanntem Schlüssel sein, die zum Unterzeichnen von unter der Befugnis dieses Zertifikates angefertigten Unterschriften verwendet werden muß. Bezugnahmen auf Zertifikate (anstatt auf bekannte Schlüssel) machen die erzwungene Benutzung von bestimmten Zertifikaten möglich, die selbst weitere Mitunterschrift oder Gegenzeichnung erfordern. Durch Auswahl der hier erscheinenden geeigneten Zertifikate ist es möglich, eine Hierarchie von Gegenzeichnungserfordernissen bis zu einer beliebigen Stufe zu erzeugen, mit der eine Organisation zufriedenstellend arbeiten kann. Für jede Kategorie ist eine genaue Anzahl von Kounterzeichnern erforderlich. Dies kann sich von allen Kandidaten bis zu einer bestimmten Teilmenge, beispielsweise 0, 1, 2 oder 3 oder allen, bewegen.
- Ein Satz von möglichen Kounterzeichnern kann explizit in einer hier beschriebenen Liste angegeben sein oder implizit durch die Angabe einiger Eigenschafts- oder Attributsangaben erfolgen, die in dem Zertifikat jedes möglichen Kounterzeichners angegeben ist.
- B schließt zusätzlich seinen eigenen bekannten Schlüssel beziehungsweise dessen Hash in das Zertifikat ein, das B als den Primärbürgen des Zertifikates von A identifiziert. Es ist vorgesehen, daß B als der Erzeuger des Zertifikates von A die Befugnis zum Löschen des Zertifikates von A hat. B kann ebenso weitere Stellen angeben, die das Zertifikat von A zum Erteilen von verschiedenen Arten von Befugnissen an A zu unterzeichnen haben.
- Es können weitere Felder in dem Zertifikat enthalten sein, beispielsweise das laufende Datum und die Zeit, die den Augenblick der Ersterzeugung des Zertifikates angeben. Wie in Fig. 5 dargestellt besteht das vollständige Zertifikat aus einem Zertifikatspaket, das das Zertifikat 116 von A und das Unterschriftspaket 114 der Unterschrift von B zu dem Zertifikat von A einschließt.
- Die Unterschrift von B und die Hierarchie von allen Zertifikaten und Unterschriften, die sie für gültig erklären, werden durch A verwaltet und mitversendet, wann immer A sein Zertifikat benutzt. Es ist vorgesehen, daß B oder andere Stellen für A verschiedene Zertifikate erzeugen. Beispielsweise kann ein Zertifikat A gestatten, sich ohne weitere angegebene Befugnis vertrauenswürdig als er selbst zu identifizieren. Ein anderes Zertifikat kann A die Befugnis über einen beschränkten Geldbetrag ohne das Erfordernis von Kounterzeichnungen einräumen. Ein drittes kann die Befugnis für einen größeren Betrag gestatten, der jedoch eine oder mehrere Kounterzeichnungen erfordert. Noch eine weitere kann A gestatten, anderen Personen weitere verschiedene finanzielle und/oder Befugnisbeschränkungen und/oder Kounterzeichnungsangaben unterzubeglaubigen.
- Unter der Annahme, daß B wie in Fig. 5 dargestellt ein Zertifikat für A erzeugt hat, ist das Zertifikat vollständig, wenn B keine Kounterzeichner erfordert. Das Zertifikat, das B zum Erzeugen des Zertifikates von A ermächtigt, kann jedoch erfordert haben, daß B Kounterzeichner hat. Es können ein oder mehrere Mitunterschrifts- und/oder Gegenzeichnungserfordernisse bestehen.
- Fig. 6 verbildlicht die von der Partei C zum gemeinsamen Bestätigen des Zertifikates von A unternommenen Schritte. Das Erfordernis für einen Mitunterzeichner ist in dem eigenen Zertifikat von B angegeben. In diesem Fall würde ein übermitteltes, mit dem Zertifikat von B unterzeichnetes Objekt (in diesem Fall das neue Zertifikat von A) von einem Empfänger rückgewiesen, falls die Mitunterschrift von C nicht an dem Objekt vorhanden ist.
- Wenn eine derartige Mitunterschrift erforderlich ist, wird, wie in Fig. 6 dargestellt, eine Kopie des Zertifikates von B für A zu C gesandt (120), der das Zertifikat mitunterschreiben muß (132). Dann untersucht C das Zertifikat von A (122) und überprüft, daß in Übereinstimmung mit dem in Verbindung mit Fig. 3 beschriebenen Vorgang der bekannte Schlüssel des Zertifikates tatsächlich zu A gehört.
- C untersucht dann die in dem Zertifikat angegebenen unterzeichneten Attribute und Befugnissen einschließlich des finanziellen Niveaus, der Vertrauensstufe und so weiter. Nach der Feststellung, daß alle Felder in dem Zertifikat von B für A zutreffend sind, wählt C dann sein eigenes Zertifikat aus, mit dem er die Unterschrift ausführt (126). C unterzeichnet mit seinem eigenen Zertifikat 128 das Zertifikat 132 von B für A (130). Nach dem Unterschreiben des Zertifikates erscheint die Unterschrift von C im wesentlichen parallel zu der Unterschrift von B und zu allen anderen Kounterzeichnern, wie mit dem Bezugszeichen 134 und 136 der Fig. 6 dargestellt ist. Es ist daher wichtig, daß C die gleiche Sorgfalt wie B bei dem Überprüfen des Zertifikates von A aufwendet. Ist einmal das Zertifikat von A erzeugt, darf kein Kounterzeichner das Zertifikat ändern, da dadurch grundsätzlich ein anderes Objekt erzeugt werden würde, auf das keine der vorangehenden Unterschriften angewendet worden wäre. Wenn C das Zertifikat nicht bestätigt, darf er es nicht unterzeichnen und sollte ein anderes Zertifikat haben, das von allen erforderlichen Parteien gebildet und wieder unterzeichnet ist. Nachdem C sein Mitzertifikat dem Zertifikat von B für A hinzugefügt hat, besteht das Zertifikatspaket aus dem Zertifikat 132 für A, dem Unterschriftspaket 134 für das Zertifikat von A und schließlich dem Unterschriftspaket 136 von C für das Zertifikat von A.
- Bezug nehmend auf das Unterschriftspaket von C sei angemerkt, daß zum gültigen Unterzeichnen des Zertifikates durch C dieser eines seiner eigenen Zertifikate auswählen muß, das ihm ausreichend Befugnis erteilt, jeden Teil des Zertifikates von A abzudecken, das C autorisiert. Wenn C kein derartiges Zertifikat besitzt, ist es ihm unmöglich, das Zertifikat gültig zu unterzeichnen, da zukünftige Empfänger sein Zertifikat als nicht ausreichend befugt zurückweisen würden.
- Es sei angemerkt, daß das Zertifikat von C ebenso die Gegenzeichnung durch eine andere Partei erfordern kann. Wenn dem so ist, leitet C das Zertifikat und alle damit verbundenen Unterschriften an die betreffende Partei, beispielsweise D, zum Gegenzeichnen der Unterschrift von C weiter. Wenn D das Material erhält, führt er die gleichen Überprüfungsschritte wie C auf das neue Zertifikat aus. Wenn D einwilligt, fügt er seine Unterschrift diesem Satz hinzu. Allerdings unterzeichnet D die Unterschrift von C und nicht das ursprüngliche Zertifikatsobjekt. Das heißt, daß das Objekt der Unterschrift von D nicht das Objekt der Unterschrift von C ist (das in diesem Fall das Zertifikat für A war), sondern das Objekt ist die Unterschrift von C selbst. Diese Gegenzeichnung unterscheidet sich daher von der Mitunterschrift, die lediglich eine weitere Unterschrift des gleichen Objektes ist.
- Die Anwendung von Mitunterschriften und/oder Gegenzeichnungen kann bis zu einer erforderlichen Tiefe verschachtelt werden. Somit kann, falls für D Mitunterschriften erforderlich sind, das Paket zu einem der möglichen Mitunterzeichner von D zur Billigung der Unterschrift von C weitergeleitet werden. Dies wäre eine Mit-Gegen-Unterschrift. In ähnlicher Weise ist es in Organisationshierarchien möglich, daß D Gegenzeichnungen erfordert, wobei in diesem Fall ein anderer die Unterschrift von D zu unterzeichnen hat.
- Wie oben erwähnt bearbeitet der Empfänger eines Primärobjektes (wie beispielsweise einer Kaufbestellung) und dessen zugeordnete Unterschriften das empfangene Material, um sicherzustellen, daß das Objekt identisch zu dem Material ist, das bei der Unterzeichnung durch den Besitzer des bekannten Schlüssels vorgelegen hat. Der Prozeß zum Überprüfen der Unterschrift und zum Überprüfen, daß das Objekt nicht verfälscht worden ist, wurde oben unter Bezug auf Fig. 3 erläutert.
- Zusätzlich muß der Empfänger überprüfen, daß die Identität des Unterzeichners korrekt ist, und weiterhin, daß der Unterzeichner die ordnungsgemäße Befugnis innerhalb seiner Organisation zum Eingehen der mit dem empfangenen Objekt verbundenen Verpflichtungen aufweist. Der Absender des Objektes (beispielsweise der Kaufbestellung) hat die Verantwortung zum Übersenden aller vorangehenden Zertifikate und Unterschriften (bis zu dem und einschließlich des Meta-Zertifikat(es)), die für einen Empfänger zum Durchführen der Überprüfungsvorgänge erforderlich sind.
- Bei der Überprüfung des Objektes und seiner Unterschriften kann der Empfänger beispielsweise wie folgt vorgehen. Zuerst stellt der Empfänger sicher, daß das Primärobjekt 150 wenigstens eine Unterschrift aufweist. In dem in Fig. 7 dargestellten Beispiel hat das Primärobjekt 150 vier zugeordnete Mitunterschriften 152, 168, 180 und 200, wobei jede von diesen ein zugeordnetes Zertifikat 154, 170, 182 und 202 aufweist.
- Das Zertifikat 154 wurde unter Erfordernis der Mitunterschriften durch die Besitzer der Zertifikate 170, 182 und 202, der Gegenzeichnungen durch die Besitzer der Zertifikate 162 und 166 unter Benutzung dieser spezifischen Zertifikate erstellt. Das Zertifikat 164 selbst wurde durch den Besitzer des Zertifikates 158 durch die Anwesenheit der Unterschrift 156 autorisiert.
- In diesem Beispiel hat der Besitzer des Zertifikates 154 die notwendigen Gegenzeichnungen 160 und 164 durch die Besitzer der Zertifikate 162 und 166 sowie die notwendigen Mitunterschriften 168, 180 und 200 erhalten.
- Um eine Gültigerklärung für seine Unterschrift 168 zu schaffen, muß der Besitzer des Zertifikates 170 die Autorisation für sein Zertifikat miteinschließen. Sein Zertifikat wurde durch den Besitzer 174 des Zertifikates (wie durch das Bezugszeichen 172 gekennzeichnet) unterzeichnet, allerdings ist in dem Zertifikat von dem Besitzer 174 angegeben, daß eine Mitunterschrift durch den Eigentümer von 178 erforderlich war, um die Unterschrift 172 des Besitzers 174 vollständig zu ratifizieren. Somit erfüllt die Unterschrift 176, die irgendwann in der Vergangenheit ausgeführt worden ist, alle Erfordernisse der Mitunterschrift des Besitzers 174 und erklärt (ratifiziert) die Benutzung des Zertifikates 170 für gültig.
- Unter Bezug auf die Mitunterschrift 180 durch den Besitzer des Zertifikates 182 ist erkennbar, daß der Besitzer 182 die Gegenzeichnungen durch den Besitzer des Zertifikates 186 durch das spezifische Zertifikat 186 erfordert. Der Eigentümer des Zertifikates 182 hat in der Tat die Gegenzeichnung 184 durch den Besitzer des Zertifikates 186 erhalten. Allerdings erfordert das Zertifikat 186, daß jegliche Unterschrift durch das Zertifikat 186 selbst durch die Eigentümer der Zertifikate 190 und 194 (mit ihren jeweiligen Zertifikaten) gegenzuzeichnen ist. Diese beiden Besitzer haben tatsächlich, wie durch die Bezugszeichen 188 und 192 gekennzeichnet, gegengezeichnet (184). Bei der nächsthöheren Stufe ist erkennbar, daß das Zertifikat 194 der Unterschrift 192 durch den Besitzer des Zertifikates 198 gegenzuzeichnen ist, dessen Unterschrift 196 erhalten worden ist. Das Zertifikat 202 erfordert keine Kounterzeichnung.
- Alle Zertifikate sind durch Unterschriften begleitet, die selbst durch vorangehende Zertifikate autorisiert sind. Letztendlich kann die gesamte Befugnis auf einen Satz von Zertifikaten zurückgeführt werden, die durch den Besitzer des Meta-Zertifikates (oder möglicherweise durch einen kleinen Satz von Meta-Zertifikaten) unterschrieben sind. Jedes Meta-Zertifikat ist allgemein bekannt und an alle Parteien "weltweit" verteilt.
- Der Empfänger untersucht jede zur Verfügung gestellte Unterschrift und überprüft, daß jeder genau sein betreffendes Objekt (das Objekt ist ein Primärobjekt, ein Zertifikat oder eine andere Unterschrift) mit der in Fig. 3 ausgeführten Prozedur unterschrieben hat. Der Empfänger stellt sicher, daß jede Unterschrift ein zugehöriges, für gültig erklärtes Zertifikat aufweist.
- Wenn ein Zertifikat Mitunterschriften erfordert, dann stellt der Empfänger sicher, daß die erforderliche Anzahl von diesen notwendigen Unterschriften (zu dem gleichen Objekt) vorhanden sind. Wenn das Zertifikat Gegenzeichnungen erfordert, dann stellt der Empfänger sicher, daß die erforderliche Anzahl von dem angegebenen Teilsatz vorhanden sind (die Gegenunterschriften haben Unterschriften als Objekt).
- Dann werden alle Zertifikate untersucht. Für das spezielle Meta-Zertifikat, das keine Unterschrift hat, aber das allgemein bekannt sowie vertrauenswürdig ist und von dem bereits in dem Computer des Empfängers eine Kopie abgespeichert ist, wird eine Kontrolle durchgeführt. Wenn ein Zertifikat empfangen worden ist, das beansprucht, das Meta-Zertifikat zu sein, aber das nicht gleich dem bereits bekannten und durch den Empfänger akzeptierten ist, dann wird eine Zurückweisung ausgegeben. Wenn das Meta-Zertifikat ordnungsgemäß erkannt ist, dann wird mit dem Prozeß der Gültigerklärung fortgefahren.
- Zusätzlich ist eine Kontrolle durchgeführt, um sicherzustellen, daß alle Zertifikate außer dem Meta-Zertifikat wenigstens eine Unterschrift aufweisen. Wie oben angemerkt ist eine Kontrolle durchgeführt, um sicherzustellen, daß alle notwendigen Kounterzeichnungen für alle vorhandenen Objekte vorliegen. Zusätzlich erfolgt eine Kontrolle, um festzustellen, daß alle vorangehenden Zertifikate eine ausreichende Befugnis für die mit einer Unterbefugnis ausgestatteten Unterzeichner erteilen, um ihnen ein gültiges Unterzeichnen des Zertifikates zu gestatten.
- Die Vertrauensstufen in dem Zertifikat müssen dafür konsistent mit den vorangehenden (das heißt den Zertifikaten ihrer Unterzeichner) sein. In lediglich beispielhafter Weise sind die nachfolgenden Kombinationen für Vertrauenfelder gültig (unter Verwendung des vorangehend spezifizierten Beispiels): unmittelbarer Vertrauenswert Vertrauenswert und vorangehendes Zertifikat (des Bürgen)
- Weiterhin sind in dem Zertifikat angegebene finanzielle Beschränkungen festzustellen. Das durch ein Zertifikat eingeräumte finanzielle Limit darf das seiner Vorläufer nicht überschreiten. Weiterhin sollte eine Kontrolle durchgeführt werden, um sicherzustellen, daß der Ablauftermin jedes Zertifikates kompatibel mit dem Ablauftermin seines Vorläufers ist. In lediglich beispielhafter Weise ist eine Kontrolle durchgeführt, um zu überprüfen, daß der Ablauftermin in jedem Zertifikat das Datum jeder darauf bezogenen Unterschrift übersteigt. In einigen Fällen kann es erwünscht sein, jedes Material, das durch ein veraltetes Zertifikat kontrolliert ist, zurückzuweisen.
- Um "geschlossene" Befugnisschleifen festzustellen (bei denen eine Serie von Zertifikaten fälschlicherweise in einer Schleife strukturiert ist, bei der das letzte Glied der Schleife Befugnis an das erste erteilt) ist es notwendig sicherzustellen, daß alle Befugnis letztendlich von einem anerkannten Meta-Zertifikat ausgeht. Auf diese Weise durchläuft eine Kette von falschen oder unechten Zertifikaten, die sich gegenseitig für gültig erklären, nicht unbeabsichtigt in unkorrekter Weise den Prozeß der Gültigerklärung.
- Ein dafür gangbarer Weg ist es, Zertifikate in einer Serie von Iterationen abzuhaken, wobei zu Beginn mit dem Meta-Zertifikat begonnen wird. Bei jeder Iteration werden die Zertifikate durchlaufen, und in dem Prozeß werden Zertifikate mit wenigstens einem abgehakten Vorläufer wiederum überprüft. Wenn die gesamte notwendige Befugnis durch die vorangehenden Zertifikate, die bereits vollständig "abgehakt" sind (einschließlich Abfragen für Erfordernisse von gültigen Mitunterschriften und Gegenzeichnungen), dann wird das Zertifikat als abgehakt betrachtet. Die Iteration endet, wenn keine neuen Zertifikate abzuhaken sind. Wenn irgendwelche Zertifikate nicht abgehakt worden sind, dann sind dies "Waisen", die nie hätten angewendet werden sollen, und diese werden ignoriert.
- Wenn die Unterschriften und Zertifikate für gültig erklärt worden sind (auf der Grundlage der obersten Befugnis des/der Meta-Zertifikate/s), besteht der abschließende Schritt darin sicherzustellen, daß die implizit in dem Primärobjekt eingegangene Verpflichtung innerhalb der dem unmittelbaren (abgehakten) (Mit-) Unterzeichner erteilten Befugnis liegt. Dies wird durch Abklären des dem Primärobjekt durch die Zertifikate der Unterzeichner zugeschriebenen Wertes durchgeführt.
- Obwohl die Benutzung eines Meta-Beglaubigers sicherstellt, daß die gesamte Befugnis letztlich von einer vertrauenswürdigen Quelle ausgeht und Schutz schafft, ist die vorliegende Erfindung nicht auf eine Beglaubigungsverfahrensweise beschränkt, die notwendigerweise einen einzelnen Meta-Beglaubiger aufweist. Bei der vorliegenden Erfindung ist vorgesehen, den Einsatz von mehreren Meta-Beglaubigern zu gestatten. Dies sollten Zertifikate sein, die von vollständig unabhängigen Quellen verwaltet werden und möglichst die Spitze von vollständig unabhängig autorisierenden Hierarchien (beispielsweise der Verwaltungsbereich gegen den privaten Bereich) widerspiegeln.
- Es sei angemerkt, daß jeder Benutzer zu irgendeiner Zeit jedes Meta-Zertifikat durch die Angabe des Anerkenntnisses an sein Computersystem auf irgendeine Art und Weise "akzeptieren" sollte, so daß die Vertrauensbereitschaft des Benutzers erkannt wird. Ein Weg für den Benutzer ist es, eine verschlüsselte oder unterschriebene Kopie jedes Meta-Zertifikates (oder eines Hash davon) auf zubewahren.
- Eine andere Anwendung von mehreren Meta-Beglaubigern könnte sein, eine Konzentration von der vollständigen Meta-Beglaubigungsverantwortung innerhalb einer Gruppe zu vermeiden. Beispielsweise könnte es unangenehm sein zu wissen, daß es eine einzelne Einheit gibt, die theoretisch im Namen von irgend jemand anderen durch das Erzeugen von falschen Zertifikaten Fälschungen erzeugen könnte. Diese Bedenken könnten dadurch gelindert werden, wenn die Befugnis zur Meta-Beglaubigung unter verschiedenen vertrauenswürdigen Meta-Beglaubigern verteilt werden würde. Jeder Meta-Beglaubiger würde vollständig unabhängig operieren, aber jedes Zertifikat würde spezifisch die anderen als Mitunterzeichner erfordern. Dies würde wesentlich die Möglichkeit eliminieren, daß vereinzelte Korruption innerhalb einer einzelnen Organisation das System in Gefahr bringen würde. Beispielsweise wäre es für jede Organisation, die wünscht, für gültig erklärt zu werden, notwendig, ihre eigenen hochrangigen Haupt-Zertifikate zu haben, die durch jede einzelne Einheit bestätigt sind. Große Organisationen können in ähnlicher Weise wünschen, ihre eigenen Master- Zertifikate so zu strukturieren, daß sie mit Erfordernis von Mitunterschriften gebildet sind, um mehrfache Sicherheiten gegen die Gefahr von vereinzelter Korruption innerhalb der Organisation zu schaffen.
- Fig. 8 zeigt eine beispielhafte Mitteilung, die von einer Partei zur anderen elektronisch als ein digitales Dokument zu übertragen ist. Nach Erzeugen des Nachrichtenteils der Mitteilung (über dem "digitalen Unterschriftsteil" gezeigt) betätigt die das Dokument übermittelnde Partei eine Steuertaste auf der in Fig. 1 dargestellten Tastatur/Bildröhre 4, um eine digitale Unterschrift und eine Zusammenfassung der die digitale Unterschrift betreffenden Zertifikate zu schaffen (von denen Beispiele in Fig. 8 dargestellt sind).
- Die in Fig. 8 dargestellte digitale Unterschrift kann, wie oben in Verbindung mit Fig. 2 beschrieben, erzeugt werden. Die Unterschrift und das Siegel, das aus einem länglichen Ausdruck von Hexadezimaldaten besteht, schließt Daten wie den Hash des Objektes, die Art des Objektes, das Unterzeichnungsdatum und das Siegel und so weiter ein, wie weiter unten in Verbindung mit Fig. 9 beschrieben werden wird.
- Weiterhin weist Fig. 8 eine Zusammenfassung von die digitale Unterschrift betreffenden Zertifikaten auf, die das Zertifikat identifizieren, welches, wie in Block 28 der Fig. 2 angezeigt, zum Erzeugen der digitalen Unterschrift benutzt worden ist. Die Zusammenfassung der Zertifikatsinformation weist von dem Zertifikat extrahierte Daten wie die Zertifikatsidentität auf, welche das Zertifikat eindeutig durch eine 32-stellige Hexadezimalziffer identifiziert. Die 32-stellige Hexadezimalziffer in der Zertifikatsidentifikation ist der Hash der Daten in dem Zertifikat und repräsentiert dadurch eindeutig das Zertifikat. Somit werden keine zwei Zertifikate jemals die gleiche Identifikation aufweisen.
- Weiterhin schließen die Zusammenfassungsdaten das Datum der Gültigerklärung und beispielsweise das autorisierte finanzielle Limit ein, über das die beglaubigte Partei zu verfügen befugt ist. Falls erwünscht können in den Zusammenfassungsdaten ebenso Sicherheitsstufen und Vertrauensstufen eingeschlossen sein. Die Zusammenfassungsdaten können einige oder alle der oberhalb in Block 116 der Fig. 5 angezeigten Daten enthalten.
- Bei Empfang in dem Computerdatensatz des Empfängers werden die digitale Unterschrift und Zertifikate gemäß der im Detail in Verbindung mit den Fig. 3 und 7 beschriebenen Prozedur für gültig erklärt. Diesbezüglich sei angemerkt, daß der in Fig. 8 dargestellte Brief nicht ausgedruckt werden würde, bis die oben beschriebenen Prozeduren zur Gültigerklärung festgestellt haben, daß er beispielsweise gültig, ordnungsmäßig autorisiert und authentifiziert ist.
- Eine weitere durch die vorliegende Erfindung geschaffene Verbesserung für digitale Unterschriften ist es, daß für Objekte, die zu drucken sind, ein "Weißabstand-Hash" beziehungsweise ein Leerzeichen-Hash berechnet wird. Wie weiter unten beschrieben ist, wird dieser Leerzeichen- Hash ein Teil der Unterschrift, der zusammen mit dem Objekt, dem Hash des Objektes, der Art des Objektes und optionalem Kommentar mit einer Hash-Funktion verarbeitet wird und der ein Teil der digitalen Unterschrift wird, die letztlich mit dem privaten Schlüssel des Unterzeichners zum Erzeugen eines Siegels verarbeitet wird.
- Viele Dokumente, die digital übermittelt worden sind, werden wie die Fig. 8 dargestellte Mitteilung schließlich ausgedruckt. Wenn ein derartiges Dokument von einem Computer erzeugt und digital unterschrieben worden ist, dann kann in der Zukunft die Notwendigkeit bestehen, eine Gültigerklärung der Unterschrift und des Dokumentes zu gestatten, auch wenn das Dokument nicht länger in einem Computerspeicher abgespeichert ist.
- Bei der Überprüfung einer derartigen digitalen Unterschrift, die ausgedruckt worden ist, treten mehrere Probleme auf. Eine einfache Wiedereingabe des Dokumentes in einen Computer und eine erneute Berechnung des einen "Fingerabdruck" bildenden Unterschrifts-Hash würde vermutlich aus mehreren Gründen nicht funktionieren. Beispielsweise enthält das ursprüngliche Computerdokument Tabulatoren, Leerzeichen, Steuerzeichen für den Vorschub und andere nicht druckbare Steuerzeichen, die von der gedruckten Ausgabe allein nicht feststellbar sind. Da die digitale Unterschrift auf dem exakten Bit- für-Bit-Bild des ursprünglichen Computerdatensatzes begründet ist, ist es in den meisten Fällen im wesentlichen unmöglich, das Dokument jemals wie ursprünglich erzeugt Bit für Bit wieder einzugeben. Selbst wenn der Benutzer den Ausdruck mit dem gleichen Aussehen wie das Original erhält, wird das Original wahrscheinlich eine geringfügig andere Mischung von Tabulatoren, Leerzeichen oder anderen Steuerzeichen enthalten.
- Die vorliegende Erfindung vermeidet dieses Problem durch das Anwenden einer Verfahrensweise zum digitalen Unterschreiben von Dokumenten, bei dem die Unterschriften sowohl für eine computergestützte Überprüfung als auch für eine mögliche Wiederüberprüfung im Notfall erzeugt werden, wenn ein Dokument jemals wieder durch Wiedereingabe von einer Wiedergabe auf Papier erneut bestätigt werden muß. Gemäß der vorliegenden Erfindung enthalten digitale Unterschriften für dokumentartige Computermitteilungen zwei verschiedene Arten von Hash-Werten. Der erste Hash-Wert bezieht sich auf die exakten Bit- für-Bit-Daten des Datensatzes und ist zum Schaffen einer oben beschriebenen digitalen Unterschrift verwendet. Dies gestattet eine Gültigerklärung des exakten Originaldokumentes, solange es in einer computerlesbaren Form zugänglich ist.
- Zusätzlich ist ein zweiter Hilfs-Hash-Wert über die gesamten Daten des Datensatzes genommen, außer daß die für den zweiten Hash-Wert verwendeten Daten gemäß einer unten beschriebenen Weise "weißabstandsnormiert" beziehungsweise leerzeichennormiert sind. Diese Leerzeichennormierung gestattet eine Wiedereingabe der Daten von einem Ausdruck in der Zukunft, ohne darauf Rücksicht nehmen zu müssen, welche Art von nicht druckbaren, unsichtbaren Steuerzeichen in dem Originaldokument existiert haben könnten. Durch das Einschließen eines leerzeichennormierten Hash-Wertes in der digitalen Unterschrift kann eine ausgedruckte Version eines Originaldokumentes später als echt überprüft werden.
- Diesbezüglich ist ein Weißabstands-Hash-Wert beziehungsweise ein Leerzeichen-Hash-Wert für das wiedergewonnene Dokument berechnet, und dieser berechnete Wert wird mit der digitalen Unterschrift und den Siegeldaten verglichen. Wenn der abgespeicherte Leerzeichen-Hash-Wert in Übereinstimmung mit dem berechneten Wert ist, ist das Dokument als echt überprüft.
- Es gibt zahlreiche Wege wie ein Dokument "normiert" werden könnte, wobei der nachfolgend beschriebene Algorithmus beispielhaft ist.
- Bevor beschrieben wird, wie der Leerzeichen-Hash berechnet wird, sei angemerkt, daß der in Fig. 8 dargestellte Brief und andere ähnlich erzeugte Dokumente üblicherweise als ein ASCII-Datensatz abgespeichert sind. Ein derartiger Datensatz schließt Vorschubsteuerzeichen, Tabulatoren und andere Steuerzeichen ein. Der von einem derartigen Computerdatensatz berechnete Hash- Wert ist eine Funktion jedes Bit dieses Computerdatensatz. Somit wird ein anderer Hash-Wert erzeugt, wenn beispielweise ein einzelnes Steuerzeichen verändert wird.
- Die weiter unten in Verbindung mit den Fig. 9A und 9B beschriebene Leerzeichen-Hash-Funktion gestattet dem Empfänger eines digitalen Dokumentes, die Echtheit des Dokumentes zu überprüfen, unabhängig davon, ob der Empfänger lediglich das ausgedruckte Dokument oder den übermittelten Computerdatensatz hat. Unter Bezug auf die Fig. 9A ist der Leerzeichen-Hash berechnet, indem zuerst das Dokument, für das der Leerzeichen-Hash zu erzeugen ist, eingegeben wird (250). Die Verarbeitungsroutine des Leerzeichen-Hash wird initialisiert, um den Hash für das neue Material zu erzeugen (252). Diesbezüglich werden alle mit der Erzeugung des Leerzeichen-Hash verknüpften Register gelöscht.
- Danach wird das Dokument, das eingegeben worden ist, gemäß der Art und Weise, wie es zu drucken ist, in einzelne Zeilen aufgeteilt. Dies wird üblicherweise durch Untersuchen von Wagenrücklauf- und/oder Zeilenvorschubszeichen durchgeführt. Nachdem das Dokument in Zeilen aufgeteilt ist, wird die erste (oder nächste) Zeile des Dokumentes abgerufen (254).
- Nach Abrufen der ersten Zeile ist eine Schleife zum Bearbeiten der Zeile aufgerufen, und es wird eine anfängliche Überprüfung durchgeführt, um festzustellen, ob das Ende des Datensatzes erreicht worden ist (256). Wenn, wie durch die Überprüfung in dem Block 256 festgestellt, das Ende des Datensatzes erreicht worden ist, dann wird der endgültige Hash-Wert von einer Hash- Funktionsverarbeitungsroutine gewonnen (258). Dieser endgültige Hash-Wert wird dann wie weiter unten beschrieben als Teil der digitalen Unterschrift (256) verwendet.
- Wenn die Überprüfung in dem Block 256 ergibt, daß das Ende des Datensatzes nicht erreicht worden ist, wird die abgerufene Zeile in einen Arbeitsbereich im Speichers verschoben (262). In dem Arbeitsspeicherbereich werden alle Tabulatorzeichen in Abstands- oder Leerzeichen umgewandelt (264). Danach wird die gesamte weitere Steuerinformation eliminiert, die kein druckbares Zeichen erzeugt (266). In diesem Zusammenhang wird alle verbleibende Steuerinformation, wie Information zum Setzen von Schriftarten, zur Gestaltung, zum Unterstreichen, zur Kursivschrift und so weiter, entfernt. Alle Steuerinformationen, die zu einem oder mehreren Leerzeichen führen würde, wird durch ein Leerzeichen ersetzt (268). Somit werden in einer Zeile auftauchende mehrere Leerzeichen durch einzelnes Leerzeichen ersetzt. Auf diese Art und Weise ist das Dokument auf den zugrundeliegenden Zeichensatz, der typischerweise als ASCII vorliegt, reduziert.
- Danach werden die Anfangs- und Endbereiche der Zeile überprüft und vorstehende Leerzeichen sowie nachstehende Leerzeichen eliminiert (270). Dann ist eine Überprüfung durchgeführt, um zu bestimmen, ob eine Zeile vollständig leer ist (272). Wenn dem so ist, wird die vollständig leere Zeile eliminiert und die Routine verzweigt zu dem Block 254 zurück, um die nächste Zeile des Dokumentes abzurufen.
- Wenn die Zeile wie in Fig. 9B dargestellt keine vollständig leere Zeile ist, werden mehrere aufeinanderfolgende Leerzeichen in ein einzelnes Leerzeichen umgewandelt (274). Da einige Drucker lediglich in Großbuchstaben drucken, werden alle verbleibenden Zeichen in Großbuchstaben umgewandelt (276). Dieser Schritt ist zum Standardisieren der Verarbeitung verwendet, da wie erwähnt einige Drucker lediglich in Großbuchstaben drucken. Es wäre möglich, diesen Schritt zu übergehen, wenn alle empfangenden Drucker gemischt Großbuchstaben und Kleinbuchstaben unterstützen würden.
- Anschließend wird ein Begrenzungszeichen verwendet, um eindeutig und unverwechselbar das Ende einer Zeile zu kennzeichnen, so daß die Zeilen unterscheidbar gehalten sind (278). Beispielsweise könnte ein Spezialzeichen wie ein Zeilenumbruchszeichen wieder eingefügt werden, um die nunmehr normierten Zeilen zu trennen. Das benutzte Steuerzeichen sollte ein Zeichen sein, das ansonsten nie in dem Text des Dokumentes auftauchen würde. Alternativ könnte zu Beginn der Zeile ein Vorspann verwendet sein, um die Länge der durchgesehenen Zeile anzugeben. Die wie oben beschrieben verarbeitete, durchgesehene Zeile wird dann als Datenteil der Hash-Funktionsverarbeitungsroutine zugeführt (280), die wie oben beschrieben einen Hash-Wert bestimmt, der unverwechselbar die Zeile des Textes identifiziert.
- Danach wird die nächste Zeile des Dokumentes in dem Block 254 abgerufen, bis schließlich, wie in dem Block 256 bestimmt, das Ende des Datensatzes erreicht ist. Nach Verarbeitung des gesamten Dokumentes ist der sich ergebende endgültige Hash-Wert ein leerzeichennormierter Hash-Wert des Dokumentes, der als ein Teil der digitalen Unterschrift, wie weiter unten beschrieben, verwendet wird.
- Fig. 10 ist ein Beispiel wie der berechnete Leerzeichen- Hash in einer digitalen Unterschrift verwendet wird. Fig. 10 stellt zusätzlich beispielhaft dar, wie mehrere Dokumente und/oder Datensätze als eine Gruppe gemäß der vorliegenden Erfindung unterzeichnet werden.
- Wie in Fig. 10 dargestellt, schließt ein "mehrfaches Dokument" eine Vielzahl von miteinander verbundenen, aber verschiedenen Objekten wie beispielsweise einen Deckbrief 300, einen Anlagebrief 302 (mit einer zugehörigen Unterschrift und Zertifikaten 303), eine Kalkulationstabelle 304 und einen Graphikdatensatz 306 ein. Der Anlagebrief 302 kann beispielsweise ein Brief sein, der an den Empfänger weitergeleitet wird und in dem Deckbrief 300 erwähnt ist.
- Das digitale Paket ist mit einer digitalen Unterschrift 308 unterschrieben und schließt, wie oben dargelegt, ein mit der digitalen Unterschrift verbundenes Siegel 310 ein. In dem digitalen Paket sind weiterhin das Zertifikat und vorangehende Zertifikate 312 eingeschlossen, die es dem Empfänger zu seiner Befriedigung gestatten, wie oben beschrieben zu überprüfen, daß die Unterschrift gültig und ordnungsgemäß autorisiert ist.
- Die mit dem Bezugszeichen 308A dargestellte Datenstruktur in Fig. 10 ist eine Vergrößerung der Unterschriftsdefinition 308, die mit dem digitalen Paket übermittelt ist. Diese Datenstruktur 308A wird dann einer Hash-Funktion 320 unterworfen. Das Ergebnis der Hash-Funktion 320 wird dann mit dem privaten Schlüssel des Unterzeichners verarbeitet (322). Das Ergebnis des Blockes 322 ist, wie durch das Bezugszeichen 310A gekennzeichnet, das Siegel der digitalen Unterschrift und ist an dem Bezugszeichen 310 in das zu übermittelnde digitale Paket eingefügt.
- Wie in Fig. 8 dargestellt ist der die Unterschrift und das Siegel bildende Datenteil im unteren Bereich des übermittelten digitalen Paketes in einer Hexadezimal- oder Oktaldarstellung gedruckt. Vorzugsweise enthält diese Information Prüfsummen oder andere Fehler feststellende und/oder korrigierende Codes, so daß jegliche Datenfalscheingabe in einfacher Weise erkennbar ist. Durch den oben erwähnten Einschluß der digitalen Unterschriften als einen Teil des digitalen Ausdrucks des Paketes kann das ausgedruckte Dokument, wie weiter unten beschrieben, unter Benutzung des Leerzeichen-Hash-Wertes wieder überprüft werden.
- Weiterhin kann bei Vorgabe der zusammengestellten Unterschriftsliste jedes diesbezügliche Dokument als unterschrieben überprüft werden, und dessen Zusammenhang mit anderen Dokumenten wird erkennbar, auch wenn die anderen Dokumente nicht verfügbar sind.
- Unter Bezug auf die Fig. 10 ist wie oben erwähnt an dem Bezugszeichen 308A eine ausführliche Version der Unterschriftsdefinition 308 dargestellt. Wie oben in Verbindung mit Fig. 2 erläutert schließt die Unterschriftsdefinition Daten ein, die das Datum und die Zeit des Unterzeichnens des digitalen Paketes sowie den sich auf das Paket beziehenden Gesamtkommentar betreffen. Weiterhin schließt wie oben beschrieben die Unterschriftsdefinition das Zertifikat des Unterzeichners mit der Identifikation des autorisierenden Zertifikates und/oder dem zugehörigen bekannten Schlüssel ein.
- Danach wird eine Liste der unterschriebenen Objekte unter detaillierter Angabe jedes der vier Abschnitte des oben beschriebenen digitalen Paketes (das heißt des Deckbriefes, des Anlagebriefes, der Kalkulationstabelle und des Graphikdatensatzes) eingeschlossen. Mit jedem aufgeführten Objekt ist eine Definition des Typs des Objektes verbunden, die anzeigt, ob beispielsweise das Objekt eine Kaufbestellung, eine andere Unterschrift oder Zertifikat, ein Brief und so weiter ist.
- Bei Betrachtung der Liste der unterzeichneten Dokumente ist beginnend mit dem ersten Dokument (beispielsweise dem Deckbrief) von jedem Dokument in der genau zu übertragenden Form ein Hash 313A, 315A, 317 und 319 berechnet. Weiterhin wird für den Deckbrief und den Anlagebrief, wie im Detail oben in Verbindung mit Fig. 9A und 9B beschrieben, ein Leerzeichen-Hash 313B und 315B berechnet. Zusätzlich wird ein Hash 316 von der Unterschrift und den Zertifikaten 303 in Verbindung mit dem Anlagebrief genommen. Da die Kalkulationstabelle 304 und der Graphikdatensatz 306 Binärdatensätze sind, sei angemerkt, daß von diesen Datensätzen kein Leerzeichen- Hash berechnet werden.
- Nach Erzeugung des Siegels 310A unter Verwendung der oben genannten Hash-Funktionen kann das sich ergebende Siegel nur durch die in der Unterschriftsdefinition 308A auftauchenden Daten erzeugt worden sein. Dementsprechend kann der Empfänger durch rückwärts vorgenommene Bearbeitung von dem Siegel die Echtheit der in der Unterschriftsdefinition enthaltenen Daten überprüfen.
- Wie oben erwähnt ist der Zweck der Berechnung und Abspeicherung des Leerzeichen-Hash, daß es irgendwann in der Zukunft notwendig sein könnte, ein digitales Dokument neu zu überprüfen oder für authentisch zu erklären, von dem in der Hartkopie des Empfängers lediglich eine ausgedruckte Version existiert. Ein derartiges Dokument kann gemäß dem in Fig. 11 dargestellten Flußdiagramm neu überprüft werden.
- Das in Fig. 11 dargestellte gedruckte Dokument 325 kann beispielsweise das in Fig. 8 dargestellte Dokument sein. Wie in dem Block 327 dargestellt fordert eine Unterroutine zur Wiederüberprüfung den Benutzer auf, den Textkörper des Dokument es wieder einzugeben und so einzutippen, daß er wie das gedruckte Dokument erscheint. Dazu muß das Dokument nicht so eingegeben werden, daß die Anordnung der Leerzeichen in dem Dokument dupliziert ist, da die Leerzeichennormierung alle mehrfachen Leerzeichen ignoriert.
- Nachdem der Textkörper des Dokumentes eingegeben worden ist, wird wie oben in Verbindung mit Fig. 9A und 9B beschrieben der Leerzeichen-Hash berechnet (329). Der in Fig. 11 identifizierte Leerzeichen-Hash-Wert wird als Wert D abgespeichert (330).
- Danach fordert die Routine zur Wiederüberprüfung den Benutzer auf, die Unterschrift und das Siegel genau wie dargestellt wieder einzugeben (331). Da die Unterschrift und das Siegel genau wie dargestellt eingegeben werden müssen, ist es zweckmäßig, Prüfsummen oder andere Fehlerdetektions/Korrekturcodes zu verwenden, um zu überprüfen, daß die Hexadezimalcodes korrekt eingegeben worden sind.
- Es sei angemerkt, daß die wieder eingegebene Unterschrift und das Siegel die digitalen Versionen der in Fig. 10 mit dem Bezugszeichen 308A und 310A dargestellten Unterschriftsdefinition und Siegel sind (die in Fig. 11 jeweils mit dem Bezugszeichen 333 und 335 gekennzeichnet sind). Die an dem Bezugszeichen 331 eingegebenen Codes geben implizit an, wo der Unterschriftsteil 333 endet und der Siegelteil 335 beginnt.
- Wie in dem Block 339 dargestellt wird von dem mit dem Bezugszeichen 333 gekennzeichneten Unterschriftsteil der Hash genommen, und der Hash-Wert A wird abgespeichert (340).
- Danach wird das Siegel der Unterschrift (335) mit dem bekannten Schlüssel (337) des Unterzeichners verarbeitet, um einen Hexadezimalwert B zu erzeugen, der in der nachfolgenden Kontrolle verwendet wird (338). Wenn der durch den Wert A angegebene Hash der Unterschrift gleich dem Wert B ist, dann sind das Siegel und die Unterschrift als korrekt überprüft. Wenn daher, wie durch die Kontrolle bei dem Bezugszeichen 342 angezeigt, A gleich B ist, ist somit die Bestimmung durchgeführt, daß das Dokument mit dem zugeordneten Zertifikat unterzeichnet worden ist (344). Wenn hingegen A nicht gleich B ist, dann wurde das Dokument nicht mit dem zugeordneten Zertifikat unterzeichnet (345).
- Der in dem Block 337 verwendete bekannte Schlüssel ist von der Unterschriftsinformation 333 erhalten, die das Zertifikat des Unterzeichners angibt. Unter Benutzung der Identifikation des Zertifikates wird das zugehörige Zertifikat abgerufen (341). Das zugehörige Zertifikat kann immer noch gültig und in der Datenbank des Empfängers vorhanden sein. Alternativ kann es archiviert sein und muß rückgespeichert werden oder kann auf Papier aufgezeichnet sein und muß, wie in dem Block 341 angezeigt, neu eingegeben werden.
- Wie in dem Block 343 gezeigt wird dann eine Kontrolle durchgeführt, um zu bestimmen, ob die in dem zugehörigen Zertifikat angezeigte Zertifikatsidentität in Übereinstimmung mit der Zertifikatsidentität ist, die beispielsweise in Fig. 8 unter der Zusammenfassung der die digitale Unterschrift betreffenden Zertifikate identifiziert ist. Wenn dem so ist, wird angenommen, daß das zugehörige Zertifikat ein echtes Zertifikat ist, das bei Empfang des Originaldokumentes durch das System wie oben identifiziert überprüft worden ist. Alternativ kann das Zertifikat unabhängig durch Aufsuchen und Kontrollieren aller seiner Vorläufer überprüft werden. Der mit dem Zertifikat verbundene bekannte Schlüssel wird dann in Block 337 zum Erzeugen des Wertes B verwendet.
- Danach wird der zu der Unterschrift bei dem Bezugszeichen 333 gehörige Leerzeichen-Hash mit einem Wert C, wie mit dem Bezugszeichen 334 dargestellt, abgespeichert. Dann wird ein Vergleich zwischen den Werten C und D durchgeführt, um sicherzustellen, daß das Dokument tatsächlich das unterzeichnete Objekt ist. Wenn, wie durch das Bezugszeichen 364 angezeigt, C gleich D ist, dann ist bestimmt, daß sich die Unterschrift mit dem Dokument 325 deckt. Wenn C nicht gleich D ist, dann deckt sich die Unterschrift nicht mit dem Dokument (350) und der Prozeß wird abgebrochen. Wenn sich die Unterschrift mit dem Dokument 348 deckt und wenn die Unterschrift mit dem angegebenen Zertifikat 344 ausgeführt worden ist, dann ist das Dokument als von dem Besitzer des angeführten Zertifikates 351 unterzeichnet überprüft.
- Fig. 12 zeigt, wie Unterschriften durch einen Empfänger eines Dokumentenpaketes mit einer mehrschichtigen Dokument/Datensatzarchitektur überprüft werden. Die empfangene digitale Unterschrift und das Siegel werden kontrolliert, um sicherzustellen, daß sie exakt dem Dokumentenpaket entsprechen, das den Deckbrief 300, den Anlagebrief 302, die Kalkulationstabelle 304, den Graphikdatensatz 306, das Unterschriftsdefinitionsfeld 308 und das Siegel des Unterschriftsfeldes 310, wie oben in Verbindung mit Fig. 10 beschrieben, enthält. Auf diese Art und Weise kann bestimmt werden, daß die empfangenen Daten nicht beschädigt oder unterwegs verloren gegangen und daß die Dokumente nicht auf irgendeine Art und Weise gefälscht und abgeändert worden sind.
- Die Hauptvorteile eines derartigen Verfahrens sind zweifach:
- jedes einzelne Objekt wird als getrennte Einheit erkannt und kann getrennt überprüft werden sowie
- der Kontext jedes Objektes in dem Satz einschließlich der Ordnung dieser Objekte als Teil des Paketes wird erkannt.
- Zuerst wird Hash jedes dieser Objekte 300, 302, 304, 306, wie jeweils mit den Bezugszeichen 400, 402, 404 und 406 gekennzeichnet, berechnet. Die Hash-Werte B, D, F und H werden, wie jeweils mit dem Bezugszeichen 401, 403, 405 und 407 gekennzeichnet, abgespeichert. Dann wird die in Fig. 12 in vergrößerter Form durch das Bezugszeichen 308A gekennzeichnete Unterschriftsdefinition überprüft, und es wird auf die Unterschriftselemente A, C, E, G zurückgegriffen. Die Elemente A, C, E und G stellen jeweils den Hash des Deckbriefes, den Hash des Anlagebriefes, den Hash der Kalkulationstabelle und den Hash des Graphikdatensatzes dar.
- Um zu bestimmen, ob die Unterschrift tatsächlich das erste Objekt, das heißt den Deckbrief, widerspiegelt, wird ein Vergleich zwischen dem Hash des Deckbriefes in der Unterschrift, wie durch das Element A angezeigt, und B, dem berechneten Hash des Deckbriefes, durchgeführt. Wenn A gleich B ist, dann ist der Hash des Deckbriefes in der Unterschrift enthalten. Ähnliche Vergleiche werden zwischen den Werten C und D, E und F sowie G und H durchgeführt, um zu bestimmen, daß jedes der verbleibenden Objekte korrekt in der Unterschrift enthalten sind. Führt jeder dieser Vergleiche zu einer Übereinstimmung, dann sind jeweils die Textkörperteile 300, 302, 304 und 306 als genau durch die Unterschrift 308 gedeckt überprüft.
- Danach wird die Unterschrift überprüft, um sicherzustellen, daß sie korrekt ist. Wie mit dem Bezugszeichen 410 gekennzeichnet, wird der Hash der Unterschrift berechnet. Dann wird der berechnete Wert J abgespeichert (412). Danach wird das Siegel 310 der Unterschrift mit dem bekannten Schlüssel des Unterzeichners verarbeitet, um einen Wert K zu erhalten, der abgespeichert wird (416).
- Der Wert K, der ein von dem bekannten Schlüssel des Unterzeichners gewonnener Hash ist, wird kontrolliert, um zu bestimmen, ob er mit dem neuberechneten Hash J übereinstimmt. Es wird dann, wie durch das Bezugszeichen 418 gekennzeichnet, eine Kontrolle durchgeführt, um zu bestimmen, ob J gleich K ist. Wenn J gleich K ist, dann war der angegebene private Schlüssel tatsächlich zum Unterschreiben jedes der Objekte in dem digitalen Paket in der dargestellten Ordnung und mit den vorgeschriebenen Kommentaren benutzt (420). Somit stellt die Unterschrift die gültige digitale Unterschrift des Paketes dar. Die Unterschriften und Zertifikate werden dann kontrolliert, um sicherzustellen, daß sie tatsächlich, wie in Verbindung mit Fig. 7 beschrieben, autorisiert sind.
- Während die Erfindung im Bezug auf eine für zweckmäßig gehaltene Ausgestaltung beschrieben worden ist, versteht es sich von selbst, daß die Erfindung nicht auf die beschriebenen Ausgestaltungen beschränkt ist, sondern im Gegenteil zahlreiche Abänderungen und äquivalente Anordnungen, die innerhalb der Weite der beigefügten Ansprüche enthalten sind, vorgesehen sind.
Claims (18)
1. Verfahren zum digitalen Signieren einer zu
übertragenden Nachricht in einem Kommunikationssystem zum
Austausch von Nachrichten über einen
Kommunikationskanal, bestehend aus den Schritten
des Erzeugens eines Hash-Wertes (250, 313A) der zu
übertragenden Nachricht, der auf den zu übertragenden
genauen Bit-für-Bit-Daten beruht, gekennzeichnet durch
die Schritte
des Erzeugens eines Hilfs-Hash-Wertes (252, 313B), der
zum Verifizieren der Echtheit einer gedruckten Fassung
der Nachricht gebildet ist, und
des Einschließens beider Hash-Werte als einen Teil der
digitalen Unterschrift.
2. Verfahren nach Anspruch 1, bei dem der Schritt des
Erzeugens des Hilfs-Hash-Wertes den Schritt
des Umwandelns aller Tabulatorzeichen in wenigstens
einem ersten Teil der Nachricht in Leerzeichen
einschließt (264).
3. Verfahren nach Anspruch 1, bei dem der Schritt des
Erzeugens des Hilfs-Hash-Wertes den Schritt
des Eliminierens von Steuerzeichen, die kein druckbares
Zeichen erzeugen, in wenigstens einem ersten Teil der
Nachricht einschließt (266).
4. Verfahren nach Anspruch 1, bei dem der Schritt des
Erzeugens des Hilfs-Hash-Wertes den Schritt
des Umwandelns wenigstens eines ersten Teiles der
Nachrichtinformation, die ein Drucken von einem oder
mehreren Leerzeichen ergibt, in Leerzeichen einschließt
(268).
5. Verfahren nach Anspruch 1, bei dem der Schritt des
Erzeugens des Hilfs-Hash-Wertes die Schritte
des Eliminierens von voranstehenden und nachstehenden
Leerzeichen in wenigstens einem ersten Teil der
Nachricht (270) und
des Eliminierens von Zeilen in der Nachricht, die
vollständig leer sind (272), einschließt.
6. Verfahren nach Anspruch 1, bei dem der Schritt des
Erzeugens des Hilfs-Hash-Wertes den Schritt
des Umwandelns von mehreren aufeinanderfolgenden
Leerzeichen in der Nachricht in ein einzelnes Leerzeichen
einschließt (274).
7. Verfahren nach Anspruch 1, bei dem der Schritt des
Erzeugens des Hilfs-Hash-Wertes den Schritt
des zeilenweisen Verarbeitens der Nachricht und des
Anhängens von Steuerinformation an die verarbeitete
Zeile zur genauen Kennzeichnung des Zeilenendes
einschließt (278).
8. Verfahren nach Anspruch 1, das weiterhin den
Schritt des Verifizieren der Echtheit des gedruckten
Dokumentes, das die Nachricht enthält, unter Benutzung
des Hilfs-Hash-Wertes einschließt.
9. Verfahren nach Anspruch 8, bei dem der Schritt des
Verifizierens der Echtheit die Schritte
des Eingebens des Textkörpers der Nachricht,
des Berechnens eines Leerzeichen-Hash-Wertes für den
eingebenen Textkörper der Nachricht,
des Eingebens der digitalen Unterschrift der gedruckten
Fassung des Dokumentes und
des Vergleiches des Leerzeichen-Hash-Wertes der
digitalen Unterschrift mit dem berechneten Leerzeichen-
Hash-Wert einschließt.
10. Verfahren nach Anspruch 1, das weiterhin die
Schritte
des Erzeugens der digitalen Unterschrift mit einem
ausgewählten Zertifikat,
des Verifizierens der Echtheit des die Nachricht
beinhaltenden Dokumentes durch
die Eingabe der digitalen Unterschrift auf ein
gedrucktes Dokument und des der digitalen Unterschrift
zugeordneten Siegels,
das Berechnen des Hash der digitalen Unterschrift zum
Erzeugen eines ersten Wertes,
das Verarbeiten des Hash des Siegels mit dem bekannten
Schlüssel des Unterzeichnens zum Erzeugen eines zweiten
Wertes und
den Vergleich des ersten Wertes mit dem zweiten Wert, um
zu bestimmen, ob das Dokument mit dem ausgewählten
Zertifikat unterschrieben wurde, einschließt.
11. Vorrichtung zum digitalen Signieren einer zu
übertragenden Nachricht in einem Kommunikationssystem
zum Austausch von Nachrichten über einen
Kommunikationskanal, bestehend aus
Mittel zum Erzeugen eines Hash-Wertes (230, 313A) der zu
übertragenden Nachricht, der auf den zu übertragenden
genauen Bit-für-Bit-Daten beruht, gekennzeichnet durch
Mittel zum Erzeugen eines Hilfs-Hash-Wertes (252, 313B),
der zum Verifizieren der Echtheit einer gedruckten
Fassung der Nachricht gebildet ist, und
Mittel zum Einschließen beider Hash-Werte als einen Teil
der digitalen Unterschrift.
12. Vorrichtung nach Anspruch 11, bei der die Mittel
zum Erzeugen des Hilfs-Hash-Wertes
Mittel zum Eliminieren von Steuerzeichen in der
Nachricht aufweisen, die kein druckbares Zeichen erzeugen
(266).
13. Vorrichtung nach Anspruch 11, bei der die Mittel
zum Erzeugen des Hilfs-Hash-Wertes
Mittel zum Umwandeln der Information, die ein Drucken
von einem oder mehreren Leerzeichen ergibt, in
Leerzeichen aufweisen (268).
14. Verfahren nach Anspruch 11, bei dem die Mittel
zum Erzeugen des Hilfs-Hash-Wertes
Mittel zum Eliminieren von voranstehenden und
nachstehenden Leerzeichen in der Nachricht (270) und
Mittel zum Eliminieren von Zeilen in der Nachricht, die
vollständig leer sind (272), aufweisen.
15. Vorrichtung nach Anspruch 11, bei der die Mittel
zum Erzeugen des Hilfs-Hash-Wertes
Mittel zum Umwandeln von mehreren aufeinanderfolgenden
Leerzeichen in der Nachricht in ein einzelnes
Leerzeichen aufweisen (274).
16. Vorrichtung nach Anspruch 11, die weiterhin
Mittel zum Verifizieren der Echtheit des gedruckten
Dokumentes, das die Nachricht enthält, unter Benutzung
des Hilfs-Hash-Wertes aufweist.
17. Vorrichtung nach Anspruch 16, bei der die Mittel
zum Verifizieren der Echtheit des gedruckten Dokumentes
Mittel zum Eingeben des Textkörpers der Nachricht,
Mittel zum Berechnen eines Leerzeichen-Hash-Wertes für
den eingebenen Textkörper der Nachricht,
Mittel zum Eingeben der digitalen Unterschrift der
gedruckten Fassung des Dokumentes und
Mittel zum Vergleich des Leerzeichen-Hash-Wertes der
digitalen Unterschrift mit dem berechneten Leerzeichen-
Hash-Wert aufweisen.
18. Vorrichtung nach Anspruch 11, die weiterhin
Mittel zum Erzeugen der digitalen Unterschrift mit einem
ausgewählten Zertifikat zum Verifizieren der Echtheit
des die Nachricht beinhaltenden Dokumentes durch
Mittel zum Eingeben der digitalen Unterschrift auf ein
gedrucktes Dokument und des mit der digitalen
Unterschrift verbundenen Siegels,
Mittel zum Berechnen des Hash der digitalen Unterschrift
zum Erzeugen eines ersten Wertes,
Mittel zum Verarbeiten des Hash des Siegels mit dem
bekannten Schlüssel des Unterzeichners zum Erzeugen
eines zweiten Wertes und
Mittel zum Vergleich des ersten Wertes mit dem zweiten
Wert um zu bestimmen, ob das Dokument mit dem
vorbestimmten Zertifikat unterschrieben wurde, aufweist.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US07/319,780 US5005200A (en) | 1988-02-12 | 1989-03-07 | Public key/signature cryptosystem with enhanced digital signature certification |
Publications (2)
Publication Number | Publication Date |
---|---|
DE69013541D1 DE69013541D1 (de) | 1994-12-01 |
DE69013541T2 true DE69013541T2 (de) | 1995-03-09 |
Family
ID=23243621
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE199090300322T Pending DE386867T1 (de) | 1989-03-07 | 1990-01-11 | Kryptosystem mit oeffentlichem schluessel und/oder unterschrift und mit digitaler unterschriftsbeglaubigung. |
DE69030268T Expired - Lifetime DE69030268T2 (de) | 1989-03-07 | 1990-01-11 | Verbessertes Kryptosystem mit öffentlichem Schlüssel und/oder Unterschrift und mit verbessertem digitalen Unterschriftsbeglaubigungsfeld |
DE69013541T Expired - Lifetime DE69013541T2 (de) | 1989-03-07 | 1990-01-11 | Kryptosystem mit öffentlichem Schlüssel und/oder Unterschrift und mit digitaler Unterschriftsbeglaubigung. |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE199090300322T Pending DE386867T1 (de) | 1989-03-07 | 1990-01-11 | Kryptosystem mit oeffentlichem schluessel und/oder unterschrift und mit digitaler unterschriftsbeglaubigung. |
DE69030268T Expired - Lifetime DE69030268T2 (de) | 1989-03-07 | 1990-01-11 | Verbessertes Kryptosystem mit öffentlichem Schlüssel und/oder Unterschrift und mit verbessertem digitalen Unterschriftsbeglaubigungsfeld |
Country Status (10)
Country | Link |
---|---|
US (1) | US5005200A (de) |
EP (2) | EP0586022B1 (de) |
JP (1) | JP3520081B2 (de) |
AT (2) | ATE150605T1 (de) |
AU (1) | AU620291B2 (de) |
CA (1) | CA2000400C (de) |
DE (3) | DE386867T1 (de) |
DK (1) | DK0386867T3 (de) |
ES (2) | ES2036978T3 (de) |
GR (1) | GR930300050T1 (de) |
Families Citing this family (406)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5742677A (en) * | 1995-04-03 | 1998-04-21 | Scientific-Atlanta, Inc. | Information terminal having reconfigurable memory |
US5214702A (en) * | 1988-02-12 | 1993-05-25 | Fischer Addison M | Public key/signature cryptosystem with enhanced digital signature certification |
US5001752A (en) * | 1989-10-13 | 1991-03-19 | Fischer Addison M | Public/key date-time notary facility |
DE4003386C1 (de) * | 1990-02-05 | 1991-05-23 | Siemens Ag, 1000 Berlin Und 8000 Muenchen, De | |
US5204966A (en) * | 1990-03-09 | 1993-04-20 | Digital Equipment Corporation | System for controlling access to a secure system by verifying acceptability of proposed password by using hashing and group of unacceptable passwords |
FR2662007B1 (fr) * | 1990-05-10 | 1992-07-10 | Bull Sa | Procede d'obtention d'une attestation en clair securisee dans un environnement de systeme informatique distribue. |
DE69133502T2 (de) * | 1990-06-01 | 2006-09-14 | Kabushiki Kaisha Toshiba, Kawasaki | Geheimübertragungsverfahren und -gerät |
US5142577A (en) * | 1990-12-17 | 1992-08-25 | Jose Pastor | Method and apparatus for authenticating messages |
US5231668A (en) * | 1991-07-26 | 1993-07-27 | The United States Of America, As Represented By The Secretary Of Commerce | Digital signature algorithm |
US5200999A (en) * | 1991-09-27 | 1993-04-06 | International Business Machines Corporation | Public key cryptosystem key management based on control vectors |
US5164988A (en) * | 1991-10-31 | 1992-11-17 | International Business Machines Corporation | Method to establish and enforce a network cryptographic security policy in a public key cryptosystem |
US5453601A (en) | 1991-11-15 | 1995-09-26 | Citibank, N.A. | Electronic-monetary system |
US5557518A (en) | 1994-04-28 | 1996-09-17 | Citibank, N.A. | Trusted agents for open electronic commerce |
US5157726A (en) * | 1991-12-19 | 1992-10-20 | Xerox Corporation | Document copy authentication |
US5210795A (en) * | 1992-01-10 | 1993-05-11 | Digital Equipment Corporation | Secure user authentication from personal computer |
US5261002A (en) * | 1992-03-13 | 1993-11-09 | Digital Equipment Corporation | Method of issuance and revocation of certificates of authenticity used in public key networks and other systems |
CA2093094C (en) * | 1992-04-06 | 2000-07-11 | Addison M. Fischer | Method and apparatus for creating, supporting, and using travelling programs |
US5276737B1 (en) * | 1992-04-20 | 1995-09-12 | Silvio Micali | Fair cryptosystems and methods of use |
USRE36918E (en) * | 1992-04-20 | 2000-10-17 | Certco Llc | Fair cryptosystems and methods of use |
ES2128393T3 (es) * | 1992-05-15 | 1999-05-16 | Addison M Fischer | Metodo y aparato para sistemas de ordenador con estructuras de datos de informacion para programas de autorizacion. |
US5412717A (en) * | 1992-05-15 | 1995-05-02 | Fischer; Addison M. | Computer system security method and apparatus having program authorization information data structures |
US5369705A (en) * | 1992-06-03 | 1994-11-29 | International Business Machines Corporation | Multi-party secure session/conference |
US5349642A (en) | 1992-11-03 | 1994-09-20 | Novell, Inc. | Method and apparatus for authentication of client server communication |
JPH06223041A (ja) * | 1993-01-22 | 1994-08-12 | Fujitsu Ltd | 広域環境利用者認証方式 |
US5422953A (en) | 1993-05-05 | 1995-06-06 | Fischer; Addison M. | Personal date/time notary device |
US5367573A (en) * | 1993-07-02 | 1994-11-22 | Digital Equipment Corporation | Signature data object |
NL9301348A (nl) * | 1993-08-02 | 1995-03-01 | Stefanus Alfonsus Brands | Elektronisch betalingssysteem. |
AU683038B2 (en) * | 1993-08-10 | 1997-10-30 | Addison M. Fischer | A method for operating computers and for processing information among computers |
US5497422A (en) * | 1993-09-30 | 1996-03-05 | Apple Computer, Inc. | Message protection mechanism and graphical user interface therefor |
US5371794A (en) * | 1993-11-02 | 1994-12-06 | Sun Microsystems, Inc. | Method and apparatus for privacy and authentication in wireless networks |
US5475753A (en) * | 1993-11-12 | 1995-12-12 | Matsushita Electric Corporation Of America | Apparatus and method for certifying the delivery of information |
US5475826A (en) * | 1993-11-19 | 1995-12-12 | Fischer; Addison M. | Method for protecting a volatile file using a single hash |
US5499294A (en) * | 1993-11-24 | 1996-03-12 | The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration | Digital camera with apparatus for authentication of images produced from an image file |
JPH09506730A (ja) * | 1993-12-17 | 1997-06-30 | クインテット、インコーポレイテッド | 自動署名検証の方法 |
JP2762909B2 (ja) * | 1993-12-27 | 1998-06-11 | 日本電気株式会社 | 電子署名装置 |
US5434919A (en) * | 1994-01-11 | 1995-07-18 | Chaum; David | Compact endorsement signature systems |
US20020013898A1 (en) * | 1997-06-04 | 2002-01-31 | Sudia Frank W. | Method and apparatus for roaming use of cryptographic values |
US5825880A (en) | 1994-01-13 | 1998-10-20 | Sudia; Frank W. | Multi-step digital signature method and system |
NZ329891A (en) * | 1994-01-13 | 2000-01-28 | Certco Llc | Method of upgrading firmware of trusted device using embedded key |
NL9400222A (nl) * | 1994-02-11 | 1995-09-01 | Seerp Westra | Werkwijze voor zgn. bewijsvergrendeling. |
DE69535935D1 (de) | 1994-02-24 | 2009-05-28 | Comcast Cable Holdings Llc | Verfahren und Vorrichtung zur Erstellung einer kryptographischen Verbindung zwischen Elementen eines Systems |
US5668878A (en) * | 1994-02-28 | 1997-09-16 | Brands; Stefanus Alfonsus | Secure cryptographic methods for electronic transfer of information |
US5604805A (en) * | 1994-02-28 | 1997-02-18 | Brands; Stefanus A. | Privacy-protected transfer of electronic information |
US7039214B2 (en) | 1999-11-05 | 2006-05-02 | Digimarc Corporation | Embedding watermark components during separate printing stages |
JPH07271865A (ja) | 1994-04-01 | 1995-10-20 | Mitsubishi Corp | データベース著作権管理方法 |
GB2288476A (en) * | 1994-04-05 | 1995-10-18 | Ibm | Authentication of printed documents. |
US5572590A (en) * | 1994-04-12 | 1996-11-05 | International Business Machines Corporation | Discrimination of malicious changes to digital information using multiple signatures |
DE4413678C1 (de) * | 1994-04-20 | 1995-05-04 | Siemens Ag | Elektronisches Einschreibeverfahren bei der Datenübertragung |
US6088797A (en) * | 1994-04-28 | 2000-07-11 | Rosen; Sholom S. | Tamper-proof electronic processing device |
DE4416253B4 (de) * | 1994-05-07 | 2005-09-22 | Deutsche Telekom Ag | Verfahren zur datenschutzgerechten Verteilung von Schlüsselinformationen |
US5515441A (en) * | 1994-05-12 | 1996-05-07 | At&T Corp. | Secure communication method and apparatus |
US7904722B2 (en) * | 1994-07-19 | 2011-03-08 | Certco, Llc | Method for securely using digital signatures in a commercial cryptographic system |
RU2144269C1 (ru) * | 1994-07-19 | 2000-01-10 | Сертко, Ллс | Способ секретного использования цифровых подписей в коммерческой криптографической системе |
US5557346A (en) * | 1994-08-11 | 1996-09-17 | Trusted Information Systems, Inc. | System and method for key escrow encryption |
US5557765A (en) * | 1994-08-11 | 1996-09-17 | Trusted Information Systems, Inc. | System and method for data recovery |
US5544255A (en) * | 1994-08-31 | 1996-08-06 | Peripheral Vision Limited | Method and system for the capture, storage, transport and authentication of handwritten signatures |
US6091835A (en) * | 1994-08-31 | 2000-07-18 | Penop Limited | Method and system for transcribing electronic affirmations |
US5606609A (en) * | 1994-09-19 | 1997-02-25 | Scientific-Atlanta | Electronic document verification system and method |
CA2158290A1 (en) * | 1994-09-29 | 1996-03-30 | Leon A. Pintsov | Postage evidencing system with secure summary reports |
US7302415B1 (en) | 1994-09-30 | 2007-11-27 | Intarsia Llc | Data copyright management system |
US5606617A (en) * | 1994-10-14 | 1997-02-25 | Brands; Stefanus A. | Secret-key certificates |
US6424715B1 (en) * | 1994-10-27 | 2002-07-23 | Mitsubishi Corporation | Digital content management system and apparatus |
DE69535013T2 (de) | 1994-10-27 | 2006-12-28 | Intarsia Software LLC, Las Vegas | Urheberrechtsdatenverwaltungssystem |
DE69532434T2 (de) | 1994-10-27 | 2004-11-11 | Mitsubishi Corp. | Gerät für Dateiurheberrechte-Verwaltungssystem |
US6237096B1 (en) | 1995-01-17 | 2001-05-22 | Eoriginal Inc. | System and method for electronic transmission storage and retrieval of authenticated documents |
US7743248B2 (en) * | 1995-01-17 | 2010-06-22 | Eoriginal, Inc. | System and method for a remote access service enabling trust and interoperability when retrieving certificate status from multiple certification authority reporting components |
US7162635B2 (en) * | 1995-01-17 | 2007-01-09 | Eoriginal, Inc. | System and method for electronic transmission, storage, and retrieval of authenticated electronic original documents |
US5748738A (en) * | 1995-01-17 | 1998-05-05 | Document Authentication Systems, Inc. | System and method for electronic transmission, storage and retrieval of authenticated documents |
CN100452072C (zh) * | 1995-02-13 | 2009-01-14 | 英特特拉斯特技术公司 | 用于管理在第一装置和第二装置之间的数字文档的分布的方法 |
US6948070B1 (en) | 1995-02-13 | 2005-09-20 | Intertrust Technologies Corporation | Systems and methods for secure transaction management and electronic rights protection |
US5943422A (en) | 1996-08-12 | 1999-08-24 | Intertrust Technologies Corp. | Steganographic techniques for securely delivering electronic digital rights management control information over insecure communication channels |
US6157721A (en) | 1996-08-12 | 2000-12-05 | Intertrust Technologies Corp. | Systems and methods using cryptography to protect secure computing environments |
US6658568B1 (en) | 1995-02-13 | 2003-12-02 | Intertrust Technologies Corporation | Trusted infrastructure support system, methods and techniques for secure electronic commerce transaction and rights management |
US5892900A (en) | 1996-08-30 | 1999-04-06 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
US7133846B1 (en) | 1995-02-13 | 2006-11-07 | Intertrust Technologies Corp. | Digital certificate support system, methods and techniques for secure electronic commerce transaction and rights management |
US6272632B1 (en) | 1995-02-21 | 2001-08-07 | Network Associates, Inc. | System and method for controlling access to a user secret using a key recovery field |
CN1192834A (zh) | 1995-06-05 | 1998-09-09 | 塞特科有限公司 | 多步数字签名方法和*** |
US5689565A (en) * | 1995-06-29 | 1997-11-18 | Microsoft Corporation | Cryptography system and method for providing cryptographic services for a computer application |
US5790677A (en) * | 1995-06-29 | 1998-08-04 | Microsoft Corporation | System and method for secure electronic commerce transactions |
US5606616A (en) * | 1995-07-03 | 1997-02-25 | General Instrument Corporation Of Delaware | Cryptographic apparatus with double feedforward hash function |
US5625693A (en) * | 1995-07-07 | 1997-04-29 | Thomson Consumer Electronics, Inc. | Apparatus and method for authenticating transmitting applications in an interactive TV system |
US5812669A (en) * | 1995-07-19 | 1998-09-22 | Jenkins; Lew | Method and system for providing secure EDI over an open network |
US6393566B1 (en) | 1995-07-28 | 2002-05-21 | National Institute Of Standards And Technology | Time-stamp service for the national information network |
JPH0950465A (ja) * | 1995-08-04 | 1997-02-18 | Hitachi Ltd | 電子ショッピング方法、電子ショッピングシステムおよび文書認証方法 |
US6907399B1 (en) * | 1995-08-21 | 2005-06-14 | Pitney Bowes Inc. | Secure user certification for electronic commerce employing value metering system |
US5796841A (en) * | 1995-08-21 | 1998-08-18 | Pitney Bowes Inc. | Secure user certification for electronic commerce employing value metering system |
US5638446A (en) * | 1995-08-28 | 1997-06-10 | Bell Communications Research, Inc. | Method for the secure distribution of electronic files in a distributed environment |
US5966446A (en) * | 1995-09-29 | 1999-10-12 | Intel Corporation | Time-bracketing infrastructure implementation |
WO1998034403A1 (en) * | 1995-09-29 | 1998-08-06 | Intel Corporation | Apparatus and method for securing captured data transmitted between two sources |
US5712914A (en) * | 1995-09-29 | 1998-01-27 | Intel Corporation | Digital certificates containing multimedia data extensions |
US8595502B2 (en) | 1995-09-29 | 2013-11-26 | Intarsia Software Llc | Data management system |
US6175626B1 (en) * | 1995-09-29 | 2001-01-16 | Intel Corporation | Digital certificates containing multimedia data extensions |
US5666416A (en) * | 1995-10-24 | 1997-09-09 | Micali; Silvio | Certificate revocation system |
US8015597B2 (en) | 1995-10-02 | 2011-09-06 | Corestreet, Ltd. | Disseminating additional data used for controlling access |
US7337315B2 (en) | 1995-10-02 | 2008-02-26 | Corestreet, Ltd. | Efficient certificate revocation |
US7716486B2 (en) | 1995-10-02 | 2010-05-11 | Corestreet, Ltd. | Controlling group access to doors |
US6766450B2 (en) * | 1995-10-24 | 2004-07-20 | Corestreet, Ltd. | Certificate revocation system |
US7353396B2 (en) | 1995-10-02 | 2008-04-01 | Corestreet, Ltd. | Physical access control |
US7822989B2 (en) * | 1995-10-02 | 2010-10-26 | Corestreet, Ltd. | Controlling access to an area |
US6487658B1 (en) | 1995-10-02 | 2002-11-26 | Corestreet Security, Ltd. | Efficient certificate revocation |
US7600129B2 (en) | 1995-10-02 | 2009-10-06 | Corestreet, Ltd. | Controlling access using additional data |
US8732457B2 (en) * | 1995-10-02 | 2014-05-20 | Assa Abloy Ab | Scalable certificate validation and simplified PKI management |
US8261319B2 (en) | 1995-10-24 | 2012-09-04 | Corestreet, Ltd. | Logging access attempts to an area |
US6301659B1 (en) | 1995-11-02 | 2001-10-09 | Silvio Micali | Tree-based certificate revocation system |
US5699431A (en) * | 1995-11-13 | 1997-12-16 | Northern Telecom Limited | Method for efficient management of certificate revocation lists and update information |
US5608801A (en) * | 1995-11-16 | 1997-03-04 | Bell Communications Research, Inc. | Efficient cryptographic hash functions and methods for amplifying the security of hash functions and pseudo-random functions |
US6026163A (en) * | 1995-12-13 | 2000-02-15 | Micali; Silvio | Distributed split-key cryptosystem and applications |
US5754659A (en) * | 1995-12-22 | 1998-05-19 | General Instrument Corporation Of Delaware | Generation of cryptographic signatures using hash keys |
US5926551A (en) * | 1995-12-28 | 1999-07-20 | International Business Machines Corporation | System and method for certifying content of hard-copy documents |
US5781635A (en) * | 1995-12-29 | 1998-07-14 | Intel Corporation | Method and apparatus for improved digital message transaction model |
JPH09223085A (ja) * | 1996-02-19 | 1997-08-26 | Fuji Xerox Co Ltd | 電子文書承認装置及び電子文書承認システム |
US20010011253A1 (en) * | 1998-08-04 | 2001-08-02 | Christopher D. Coley | Automated system for management of licensed software |
US20060265337A1 (en) * | 1996-02-26 | 2006-11-23 | Graphon Corporation | Automated system for management of licensed digital assets |
US5923763A (en) | 1996-03-21 | 1999-07-13 | Walker Asset Management Limited Partnership | Method and apparatus for secure document timestamping |
US5850442A (en) * | 1996-03-26 | 1998-12-15 | Entegrity Solutions Corporation | Secure world wide electronic commerce over an open network |
US5778069A (en) * | 1996-04-10 | 1998-07-07 | Microsoft Corporation | Non-biased pseudo random number generator |
US6088450A (en) * | 1996-04-17 | 2000-07-11 | Intel Corporation | Authentication system based on periodic challenge/response protocol |
US5978484A (en) * | 1996-04-25 | 1999-11-02 | Microsoft Corporation | System and method for safety distributing executable objects |
US5956409A (en) * | 1996-04-29 | 1999-09-21 | Quintet, Inc. | Secure application of seals |
US6002768A (en) * | 1996-05-07 | 1999-12-14 | International Computer Science Institute | Distributed registration and key distribution system and method |
US6085320A (en) | 1996-05-15 | 2000-07-04 | Rsa Security Inc. | Client/server protocol for proving authenticity |
US5825877A (en) * | 1996-06-11 | 1998-10-20 | International Business Machines Corporation | Support for portable trusted software |
US5987123A (en) * | 1996-07-03 | 1999-11-16 | Sun Microsystems, Incorporated | Secure file system |
US5764769A (en) * | 1996-07-31 | 1998-06-09 | International Business Machines Corporation | Digital recording system with time-bracketed authentication by on-line challenges and method of authenticating recordings |
KR100397601B1 (ko) * | 1996-07-31 | 2003-10-23 | 삼성전자주식회사 | 메시지 부가형 디지털서명 방법 및 그에 대한 검증 방법 |
US6023509A (en) * | 1996-09-30 | 2000-02-08 | Intel Corporation | Digital signature purpose encoding |
US6181803B1 (en) | 1996-09-30 | 2001-01-30 | Intel Corporation | Apparatus and method for securely processing biometric information to control access to a node |
DE19640526A1 (de) * | 1996-10-01 | 1998-04-02 | Deutsche Telekom Ag | Verfahren zur Übertragung von Signalen |
US5946396A (en) * | 1996-10-25 | 1999-08-31 | Intel Corporation | System and method for ensuring integrity of audio |
JPH10133576A (ja) * | 1996-10-31 | 1998-05-22 | Hitachi Ltd | 公開鍵暗号方法および装置 |
US6253323B1 (en) * | 1996-11-01 | 2001-06-26 | Intel Corporation | Object-based digital signatures |
US5958051A (en) * | 1996-11-27 | 1999-09-28 | Sun Microsystems, Inc. | Implementing digital signatures for data streams and data archives |
US6021491A (en) * | 1996-11-27 | 2000-02-01 | Sun Microsystems, Inc. | Digital signatures for data streams and data archives |
WO1998026537A1 (de) * | 1996-12-12 | 1998-06-18 | Ascom Systec Ag | Verfahren zur elektronisch gesicherten speicherung von daten in einer datenbank |
US5903882A (en) | 1996-12-13 | 1999-05-11 | Certco, Llc | Reliance server for electronic transaction system |
CA2275574C (en) | 1996-12-20 | 2003-07-29 | Financial Services Technology Consortium | Method and system for processing electronic documents |
JP4436459B2 (ja) * | 1996-12-24 | 2010-03-24 | エックスアールティ・リミテッド | 位相回収式の位相コントラスト画像 |
US5917911A (en) * | 1997-01-23 | 1999-06-29 | Motorola, Inc. | Method and system for hierarchical key access and recovery |
US7366900B2 (en) * | 1997-02-12 | 2008-04-29 | Verizon Laboratories, Inc. | Platform-neutral system and method for providing secure remote operations over an insecure computer network |
US5872848A (en) * | 1997-02-18 | 1999-02-16 | Arcanvs | Method and apparatus for witnessed authentication of electronic documents |
US6317832B1 (en) * | 1997-02-21 | 2001-11-13 | Mondex International Limited | Secure multiple application card system and process |
US6575372B1 (en) | 1997-02-21 | 2003-06-10 | Mondex International Limited | Secure multi-application IC card system having selective loading and deleting capability |
US5920861A (en) | 1997-02-25 | 1999-07-06 | Intertrust Technologies Corp. | Techniques for defining using and manipulating rights management data structures |
US5982898A (en) * | 1997-03-07 | 1999-11-09 | At&T Corp. | Certification process |
US6035041A (en) * | 1997-04-28 | 2000-03-07 | Certco, Inc. | Optimal-resilience, proactive, public-key cryptographic system and method |
JPH11143840A (ja) * | 1997-11-05 | 1999-05-28 | Hitachi Ltd | 分散オブジェクトシステムおよびその方法 |
US6164549A (en) * | 1997-05-15 | 2000-12-26 | Mondex International Limited | IC card with shell feature |
SE512748C2 (sv) * | 1997-05-15 | 2000-05-08 | Access Security Sweden Ab | Förfarande, aktivt kort, system samt användning av aktivt kort för att genomföra en elektronisk transaktion |
US6488211B1 (en) | 1997-05-15 | 2002-12-03 | Mondex International Limited | System and method for flexibly loading in IC card |
US6328217B1 (en) | 1997-05-15 | 2001-12-11 | Mondex International Limited | Integrated circuit card with application history list |
US6220510B1 (en) | 1997-05-15 | 2001-04-24 | Mondex International Limited | Multi-application IC card with delegation feature |
US6385723B1 (en) | 1997-05-15 | 2002-05-07 | Mondex International Limited | Key transformation unit for an IC card |
US6335972B1 (en) | 1997-05-23 | 2002-01-01 | International Business Machines Corporation | Framework-based cryptographic key recovery system |
US6243466B1 (en) | 1997-08-29 | 2001-06-05 | Adam Lucas Young | Auto-escrowable and auto-certifiable cryptosystems with fast key generation |
US6282295B1 (en) | 1997-10-28 | 2001-08-28 | Adam Lucas Young | Auto-recoverable and auto-certifiable cryptostem using zero-knowledge proofs for key escrow in general exponential ciphers |
US6202150B1 (en) | 1997-05-28 | 2001-03-13 | Adam Lucas Young | Auto-escrowable and auto-certifiable cryptosystems |
US6122742A (en) * | 1997-06-18 | 2000-09-19 | Young; Adam Lucas | Auto-recoverable and auto-certifiable cryptosystem with unescrowed signing keys |
US6389136B1 (en) | 1997-05-28 | 2002-05-14 | Adam Lucas Young | Auto-Recoverable and Auto-certifiable cryptosystems with RSA or factoring based keys |
US6105131A (en) * | 1997-06-13 | 2000-08-15 | International Business Machines Corporation | Secure server and method of operation for a distributed information system |
GB2327831B (en) * | 1997-07-23 | 2002-10-09 | Chantilley Corp Ltd | Document or message security arrangements |
US6357004B1 (en) * | 1997-09-30 | 2002-03-12 | Intel Corporation | System and method for ensuring integrity throughout post-processing |
US6424712B2 (en) * | 1997-10-17 | 2002-07-23 | Certicom Corp. | Accelerated signature verification on an elliptic curve |
US6330549B1 (en) * | 1997-10-30 | 2001-12-11 | Xerox Corporation | Protected shareware |
US7092914B1 (en) * | 1997-11-06 | 2006-08-15 | Intertrust Technologies Corporation | Methods for matching, selecting, narrowcasting, and/or classifying based on rights management and/or other information |
US6112181A (en) | 1997-11-06 | 2000-08-29 | Intertrust Technologies Corporation | Systems and methods for matching, selecting, narrowcasting, and/or classifying based on rights management and/or other information |
DE19750522A1 (de) * | 1997-11-14 | 1999-05-20 | Wilhelm Wolter | Authentifizierungssystem für elektronische Dateien |
US6385728B1 (en) | 1997-11-26 | 2002-05-07 | International Business Machines Corporation | System, method, and program for providing will-call certificates for guaranteeing authorization for a printer to retrieve a file directly from a file server upon request from a client in a network computer system environment |
US6314521B1 (en) | 1997-11-26 | 2001-11-06 | International Business Machines Corporation | Secure configuration of a digital certificate for a printer or other network device |
US6601172B1 (en) * | 1997-12-31 | 2003-07-29 | Philips Electronics North America Corp. | Transmitting revisions with digital signatures |
US6195447B1 (en) | 1998-01-16 | 2001-02-27 | Lucent Technologies Inc. | System and method for fingerprint data verification |
US6736325B1 (en) | 1998-01-22 | 2004-05-18 | Mondex International Limited | Codelets |
US6357665B1 (en) | 1998-01-22 | 2002-03-19 | Mondex International Limited | Configuration of IC card |
US6742120B1 (en) | 1998-02-03 | 2004-05-25 | Mondex International Limited | System and method for controlling access to computer code in an IC card |
WO1999041878A1 (en) * | 1998-02-17 | 1999-08-19 | At & T Corp. | Method and apparatus for compliance checking in a trust-management system |
US6314517B1 (en) * | 1998-04-02 | 2001-11-06 | Entrust Technologies Limited | Method and system for notarizing digital signature data in a system employing cryptography based security |
US6128738A (en) * | 1998-04-22 | 2000-10-03 | International Business Machines Corporation | Certificate based security in SNA data flows |
DE19820484C1 (de) * | 1998-05-07 | 1999-11-18 | Sc Info & Inno Gmbh & Co | Verfahren zur Prüfung der Unversehrtheit und der Echtheit eines Textes |
US6195433B1 (en) * | 1998-05-08 | 2001-02-27 | Certicom Corp. | Private key validity and validation |
US6892300B2 (en) | 1998-06-04 | 2005-05-10 | International Business Machines Corporation | Secure communication system and method of operation for conducting electronic commerce using remote vault agents interacting with a vault controller |
US6931526B1 (en) | 1998-06-04 | 2005-08-16 | International Business Machines Corporation | Vault controller supervisor and method of operation for managing multiple independent vault processes and browser sessions for users in an electronic business system |
US6438690B1 (en) | 1998-06-04 | 2002-08-20 | International Business Machines Corp. | Vault controller based registration application serving web based registration authorities and end users for conducting electronic commerce in secure end-to-end distributed information system |
US6684332B1 (en) | 1998-06-10 | 2004-01-27 | International Business Machines Corporation | Method and system for the exchange of digitally signed objects over an insecure network |
US6269446B1 (en) | 1998-06-26 | 2001-07-31 | Canon Kabushiki Kaisha | Authenticating images from digital cameras |
US7134024B1 (en) | 1998-07-15 | 2006-11-07 | International Business Machines Corporation | Method of establishing the trustworthiness level of a participant in a communication connection |
JP2000059771A (ja) * | 1998-08-04 | 2000-02-25 | Hitachi Ltd | 画像撮像装置および画像データ利用システム |
US6983371B1 (en) * | 1998-10-22 | 2006-01-03 | International Business Machines Corporation | Super-distribution of protected digital content |
US6859791B1 (en) | 1998-08-13 | 2005-02-22 | International Business Machines Corporation | Method for determining internet users geographic region |
US6389403B1 (en) | 1998-08-13 | 2002-05-14 | International Business Machines Corporation | Method and apparatus for uniquely identifying a customer purchase in an electronic distribution system |
US6959288B1 (en) | 1998-08-13 | 2005-10-25 | International Business Machines Corporation | Digital content preparation system |
US7110984B1 (en) | 1998-08-13 | 2006-09-19 | International Business Machines Corporation | Updating usage conditions in lieu of download digital rights management protected content |
US6226618B1 (en) | 1998-08-13 | 2001-05-01 | International Business Machines Corporation | Electronic content delivery system |
US6611812B2 (en) | 1998-08-13 | 2003-08-26 | International Business Machines Corporation | Secure electronic content distribution on CDS and DVDs |
RU2153191C2 (ru) * | 1998-09-29 | 2000-07-20 | Закрытое акционерное общество "Алкорсофт" | Способ изготовления вслепую цифровой rsa-подписи и устройство для его реализации (варианты) |
US6463535B1 (en) | 1998-10-05 | 2002-10-08 | Intel Corporation | System and method for verifying the integrity and authorization of software before execution in a local platform |
US6370250B1 (en) | 1998-10-29 | 2002-04-09 | International Business Machines Corporation | Method of authentication and storage of private keys in a public key cryptography system (PKCS) |
DE19851709A1 (de) * | 1998-10-30 | 2000-05-04 | Siemens Ag | Verfahren zum Online-Update sicherheitskritischer Software in der Eisenbahn-Signaltechnik |
AU760021B2 (en) * | 1998-11-25 | 2003-05-08 | Commonwealth Of Australia, The | High assurance digital signatures |
RU2157001C2 (ru) | 1998-11-25 | 2000-09-27 | Закрытое акционерное общество "Алкорсофт" | Способ проведения платежей (варианты) |
AUPP728398A0 (en) * | 1998-11-25 | 1998-12-17 | Commonwealth Of Australia, The | High assurance digital signatures |
US6473508B1 (en) | 1998-12-22 | 2002-10-29 | Adam Lucas Young | Auto-recoverable auto-certifiable cryptosystems with unescrowed signature-only keys |
US7171000B1 (en) | 1999-06-10 | 2007-01-30 | Message Secure Corp. | Simplified addressing for private communications |
CA2290170C (en) * | 1999-01-29 | 2005-06-14 | International Business Machines Corporation | Improved digital signature |
AU761317B2 (en) * | 1999-01-29 | 2003-06-05 | General Instrument Corporation | Self-generation of certificates using a secure microprocessor in a device for transferring digital information |
US6567917B1 (en) * | 1999-02-01 | 2003-05-20 | Cisco Technology, Inc. | Method and system for providing tamper-resistant executable software |
US6477645B1 (en) | 1999-02-03 | 2002-11-05 | Intel Corporation | Authority and integrity check in systems lacking a public key |
US6601171B1 (en) | 1999-02-18 | 2003-07-29 | Novell, Inc. | Deputization in a distributed computing system |
EP1159799B1 (de) * | 1999-02-26 | 2006-07-26 | Bitwise Designs, Inc. | Digitales datenverwaltungs-und abbildherstellungssystem und verfahren mit gesicherter datenmarkierung |
US6981023B1 (en) * | 1999-03-09 | 2005-12-27 | Michael Hamilton | Message routing |
US20020019814A1 (en) | 2001-03-01 | 2002-02-14 | Krishnamurthy Ganesan | Specifying rights in a digital rights license according to events |
US6829708B1 (en) | 1999-03-27 | 2004-12-07 | Microsoft Corporation | Specifying security for an element by assigning a scaled value representative of the relative security thereof |
US7073063B2 (en) | 1999-03-27 | 2006-07-04 | Microsoft Corporation | Binding a digital license to a portable device or the like in a digital rights management (DRM) system and checking out/checking in the digital license to/from the portable device or the like |
US7103574B1 (en) * | 1999-03-27 | 2006-09-05 | Microsoft Corporation | Enforcement architecture and method for digital rights management |
US7136838B1 (en) * | 1999-03-27 | 2006-11-14 | Microsoft Corporation | Digital license and method for obtaining/providing a digital license |
US6711679B1 (en) | 1999-03-31 | 2004-03-23 | International Business Machines Corporation | Public key infrastructure delegation |
US6587947B1 (en) | 1999-04-01 | 2003-07-01 | Intel Corporation | System and method for verification of off-chip processor code |
WO2000062242A1 (en) * | 1999-04-09 | 2000-10-19 | Ivaylo Nicolaev Popov | Method for human-machine interface by documents |
US6163361A (en) * | 1999-04-23 | 2000-12-19 | Eastman Kodak Company | Digital camera including a printer for receiving a cartridge having security control circuitry |
US6757827B1 (en) | 1999-04-26 | 2004-06-29 | Unisys Corporation | Autonomously secured image data |
DE19923807A1 (de) * | 1999-05-19 | 2000-11-23 | Deutsche Telekom Ag | Verfahren zur Erhöhung der Sicherheit bei digitalen Unterschriften |
EP1055989A1 (de) * | 1999-05-28 | 2000-11-29 | Hewlett-Packard Company | System zum digitalen Unterschreiben von einem Dokument |
EP1056014A1 (de) | 1999-05-28 | 2000-11-29 | Hewlett-Packard Company | System und Verfahren zur Versorgung einer vertrauenswürdigen Benutzerschnittstelle |
US20020101998A1 (en) * | 1999-06-10 | 2002-08-01 | Chee-Hong Wong | Fast escrow delivery |
US6988199B2 (en) | 2000-07-07 | 2006-01-17 | Message Secure | Secure and reliable document delivery |
US20020019932A1 (en) * | 1999-06-10 | 2002-02-14 | Eng-Whatt Toh | Cryptographically secure network |
GB9914262D0 (en) * | 1999-06-18 | 1999-08-18 | Nokia Mobile Phones Ltd | WIM Manufacture certificate |
CA2377706A1 (en) * | 1999-06-18 | 2000-12-28 | Echarge Corporation | Method and apparatus for ordering goods, services and content over an internetwork using a virtual payment account |
US6795920B1 (en) | 1999-06-30 | 2004-09-21 | International Business Machines Corporation | Vault controller secure depositor for managing secure communication |
US6202159B1 (en) | 1999-06-30 | 2001-03-13 | International Business Machines Corporation | Vault controller dispatcher and methods of operation for handling interaction between browser sessions and vault processes in electronic business systems |
CA2310535A1 (en) * | 1999-06-30 | 2000-12-30 | International Business Machines Corporation | Vault controller context manager and methods of operation for securely maintaining state information between successive browser connections in an electronic business system |
US7058817B1 (en) | 1999-07-02 | 2006-06-06 | The Chase Manhattan Bank | System and method for single sign on process for websites with multiple applications and services |
US7243236B1 (en) * | 1999-07-29 | 2007-07-10 | Intertrust Technologies Corp. | Systems and methods for using cryptography to protect secure and insecure computing environments |
US7366702B2 (en) * | 1999-07-30 | 2008-04-29 | Ipass Inc. | System and method for secure network purchasing |
US7885899B1 (en) * | 2000-02-08 | 2011-02-08 | Ipass Inc. | System and method for secure network purchasing |
US7249259B1 (en) * | 1999-09-07 | 2007-07-24 | Certicom Corp. | Hybrid signature scheme |
US6732113B1 (en) | 1999-09-20 | 2004-05-04 | Verispan, L.L.C. | System and method for generating de-identified health care data |
AU7596500A (en) | 1999-09-20 | 2001-04-24 | Quintiles Transnational Corporation | System and method for analyzing de-identified health care data |
GB9925227D0 (en) | 1999-10-25 | 1999-12-22 | Internet Limited | Data storage retrieval and access system |
US6826690B1 (en) | 1999-11-08 | 2004-11-30 | International Business Machines Corporation | Using device certificates for automated authentication of communicating devices |
US6754908B1 (en) | 1999-11-12 | 2004-06-22 | General Instrument Corporation | Intrusion detection for object security |
US20010013121A1 (en) * | 1999-11-12 | 2001-08-09 | Kimball Bridget D. | Authorization conditioned object message download |
ES2197894T3 (es) * | 1999-11-12 | 2004-01-16 | General Instrument Corporation | Implementacion de la seguridad de un objeto. |
JP3725384B2 (ja) * | 1999-11-24 | 2005-12-07 | 富士通株式会社 | 認証装置、認証方法及びその装置での処理をコンピュータに行なわせるためのプログラムを格納した記憶媒体 |
GB2357229B (en) * | 1999-12-08 | 2004-03-17 | Hewlett Packard Co | Security protocol |
GB2357228B (en) * | 1999-12-08 | 2003-07-09 | Hewlett Packard Co | Method and apparatus for discovering a trust chain imparting a required attribute to a subject |
GB2357225B (en) * | 1999-12-08 | 2003-07-16 | Hewlett Packard Co | Electronic certificate |
GB2357227B (en) | 1999-12-08 | 2003-12-17 | Hewlett Packard Co | Security protocol |
GB2357226B (en) * | 1999-12-08 | 2003-07-16 | Hewlett Packard Co | Security protocol |
US6834110B1 (en) | 1999-12-09 | 2004-12-21 | International Business Machines Corporation | Multi-tier digital TV programming for content distribution |
US7213005B2 (en) | 1999-12-09 | 2007-05-01 | International Business Machines Corporation | Digital content distribution using web broadcasting services |
US6636975B1 (en) * | 1999-12-15 | 2003-10-21 | Identix Incorporated | Accessing a secure resource using certificates bound with authentication information |
US20030130955A1 (en) * | 1999-12-17 | 2003-07-10 | Hawthorne William Mcmullan | Secure transaction systems |
US6912285B2 (en) * | 2000-02-24 | 2005-06-28 | Tumbleweed Communications Corp. | Mechanism for efficient private bulk messaging |
WO2001063567A2 (en) * | 2000-02-25 | 2001-08-30 | Identix Incorporated | Secure transaction system |
US7240202B1 (en) | 2000-03-16 | 2007-07-03 | Novell, Inc. | Security context sharing |
US6990581B1 (en) * | 2000-04-07 | 2006-01-24 | At&T Corp. | Broadband certified mail |
KR20010096814A (ko) * | 2000-04-14 | 2001-11-08 | 홍기융 | 전자서명 인증기반 파일시스템 해킹방지용 보안커널 방법 |
EP1253564A3 (de) * | 2000-04-19 | 2002-12-11 | Magicaxess | Verfahren und Vorrichtung für elektronische Bezahlung |
US20060064596A1 (en) * | 2000-05-09 | 2006-03-23 | Microsoft Corporation | Restricted software and hardware usage on a computer |
US20020003884A1 (en) * | 2000-05-26 | 2002-01-10 | Sprunk Eric J. | Authentication and/or authorization launch |
GB2362970B (en) * | 2000-05-31 | 2004-12-29 | Hewlett Packard Co | Improvements relating to information storage |
GB2363297B (en) * | 2000-06-09 | 2004-04-07 | Hewlett Packard Co | Secure network communications |
EP1297654A1 (de) * | 2000-06-14 | 2003-04-02 | Smarttrust Systems Oy | Interpretation der identität einer entität |
US20020013899A1 (en) * | 2000-06-17 | 2002-01-31 | Faul Jacob Joel | Automated document distribution and transaction verification |
US20040073617A1 (en) | 2000-06-19 | 2004-04-15 | Milliken Walter Clark | Hash-based systems and methods for detecting and preventing transmission of unwanted e-mail |
US7251728B2 (en) | 2000-07-07 | 2007-07-31 | Message Secure Corporation | Secure and reliable document delivery using routing lists |
FR2812781A1 (fr) | 2000-08-04 | 2002-02-08 | Thomson Multimedia Sa | Methode de distribution securisee de donnees numeriques representatives d'un contenu multimedia |
US20020143987A1 (en) * | 2000-08-22 | 2002-10-03 | Sadler Andrew Paul | Message management systems and method |
GB2366469B (en) * | 2000-08-25 | 2005-02-23 | Hewlett Packard Co | Improvements relating to document transmission techniques II |
US6978375B1 (en) | 2000-09-08 | 2005-12-20 | International Business Machines Corporation | System and method for secure authentication of external software modules provided by third parties |
WO2002025409A2 (en) | 2000-09-21 | 2002-03-28 | Research In Motion Limited | Software code signing system and method |
US6700076B2 (en) * | 2000-09-28 | 2004-03-02 | Eic Corporation | Multi-layer interconnect module and method of interconnection |
US7039615B1 (en) | 2000-09-28 | 2006-05-02 | Microsoft Corporation | Retail transactions involving digital content in a digital rights management (DRM) system |
US20020048372A1 (en) * | 2000-10-19 | 2002-04-25 | Eng-Whatt Toh | Universal signature object for digital data |
US7571199B1 (en) | 2000-11-15 | 2009-08-04 | Microsoft Corporation | Method and apparatus for generating random numbers |
US20020112175A1 (en) * | 2000-12-13 | 2002-08-15 | Makofka Douglas S. | Conditional access for functional units |
US7039807B2 (en) * | 2001-01-23 | 2006-05-02 | Computer Associates Think, Inc. | Method and system for obtaining digital signatures |
JP4093723B2 (ja) * | 2001-01-24 | 2008-06-04 | ケープレックス・インク | 構造を持った文書に対する電子署名方法及び装置 |
US6954740B2 (en) * | 2001-02-26 | 2005-10-11 | Albert Israel Talker | Action verification system using central verification authority |
US7085925B2 (en) * | 2001-04-03 | 2006-08-01 | Sun Microsystems, Inc. | Trust ratings in group credentials |
US8849716B1 (en) | 2001-04-20 | 2014-09-30 | Jpmorgan Chase Bank, N.A. | System and method for preventing identity theft or misuse by restricting access |
US7607018B2 (en) * | 2001-05-08 | 2009-10-20 | Ip.Com, Inc. | Method and apparatus for collecting electronic signatures |
US7143285B2 (en) * | 2001-05-22 | 2006-11-28 | International Business Machines Corporation | Password exposure elimination for digital signature coupling with a host identity |
GB2376313A (en) | 2001-06-04 | 2002-12-11 | Hewlett Packard Co | Indicating to a user if they are connected to a trusted computer platform |
US7689506B2 (en) | 2001-06-07 | 2010-03-30 | Jpmorgan Chase Bank, N.A. | System and method for rapid updating of credit information |
US7266839B2 (en) | 2001-07-12 | 2007-09-04 | J P Morgan Chase Bank | System and method for providing discriminated content to network users |
US7773730B1 (en) | 2001-08-09 | 2010-08-10 | Voice Signature Llc | Voice record integrator |
US20030200447A1 (en) * | 2001-08-17 | 2003-10-23 | Lotta Almroth | Identification system |
GB2379146A (en) * | 2001-08-23 | 2003-02-26 | Inventec Corp | Transmission of encrypted and digitally signed files over the internet |
US6954770B1 (en) * | 2001-08-23 | 2005-10-11 | Cavium Networks | Random number generator |
WO2003019449A2 (en) * | 2001-08-31 | 2003-03-06 | Digimarc Corporation | Digitally watermarking checks and other value documents |
EP1425680A4 (de) * | 2001-08-31 | 2006-05-03 | Trac Medical Solutions Inc | System zur interaktiven verarbeitung von formulardokumenten |
US20030050981A1 (en) * | 2001-09-13 | 2003-03-13 | International Business Machines Corporation | Method, apparatus, and program to forward and verify multiple digital signatures in electronic mail |
US7987501B2 (en) | 2001-12-04 | 2011-07-26 | Jpmorgan Chase Bank, N.A. | System and method for single session sign-on |
US7305556B2 (en) * | 2001-12-05 | 2007-12-04 | Canon Kabushiki Kaisha | Secure printing with authenticated printer key |
AUPR960601A0 (en) * | 2001-12-18 | 2002-01-24 | Canon Kabushiki Kaisha | Image protection |
JP3997085B2 (ja) * | 2001-12-28 | 2007-10-24 | キヤノン株式会社 | 画像生成装置 |
US7152048B1 (en) | 2002-02-07 | 2006-12-19 | Oracle International Corporation | Memphis: multiple electronic money payment highlevel integrated security |
US7194630B2 (en) | 2002-02-27 | 2007-03-20 | Canon Kabushiki Kaisha | Information processing apparatus, information processing system, information processing method, storage medium and program |
US20180165441A1 (en) | 2002-03-25 | 2018-06-14 | Glenn Cobourn Everhart | Systems and methods for multifactor authentication |
DE60308251T2 (de) * | 2002-04-17 | 2007-08-30 | Canon K.K. | Vorrichtung zur Bereitstellung von öffentlichen Schlüsselzertifikaten |
EP1361527A1 (de) * | 2002-05-07 | 2003-11-12 | Sony Ericsson Mobile Communications AB | Verfahren zum Laden einer Anwendung in einem Gerät, Gerät und Chipkarte dafür |
US20040254890A1 (en) * | 2002-05-24 | 2004-12-16 | Sancho Enrique David | System method and apparatus for preventing fraudulent transactions |
US20030221109A1 (en) * | 2002-05-24 | 2003-11-27 | Pure Edge Solutions, Inc. | Method of and apparatus for digital signatures |
US7184985B2 (en) * | 2002-05-30 | 2007-02-27 | Microsoft Corporation | Method, system, and apparatus for providing secure access to a digital work |
US7047488B2 (en) | 2002-07-19 | 2006-05-16 | Open Invention Network | Registry driven interoperability and exchange of documents |
US7200674B2 (en) * | 2002-07-19 | 2007-04-03 | Open Invention Network, Llc | Electronic commerce community networks and intra/inter community secure routing implementation |
US7469210B1 (en) | 2002-08-08 | 2008-12-23 | Voice Signature Llc | Outbound voice signature calls |
US7729922B2 (en) | 2002-08-15 | 2010-06-01 | Open Invention Network, Llc | Dynamic interface between BPSS conversation management and local business management |
DE60208614T2 (de) | 2002-09-17 | 2006-08-03 | Errikos Pitsos | Verfahren und Vorrichtung zur Bereitstellung einer Liste von öffentlichen Schlüsseln in einem Public-Key-System |
US7444522B1 (en) | 2002-09-18 | 2008-10-28 | Open Invention Network, Llc | Dynamic negotiation of security arrangements between web services |
US7340508B1 (en) | 2002-09-18 | 2008-03-04 | Open Invention Network, Llc | Exposing process flows and choreography controllers as web services |
US20050005116A1 (en) * | 2002-09-18 | 2005-01-06 | Commerce One Operations, Inc. | Dynamic interoperability contract for web services |
US7058660B2 (en) | 2002-10-02 | 2006-06-06 | Bank One Corporation | System and method for network-based project management |
US8301493B2 (en) | 2002-11-05 | 2012-10-30 | Jpmorgan Chase Bank, N.A. | System and method for providing incentives to consumers to share information |
GB0229894D0 (en) | 2002-12-21 | 2003-01-29 | Ibm | Methods, apparatus and computer programs for generating and/or using conditional electronic signatures and/or for reporting status changes |
KR100510129B1 (ko) * | 2003-01-27 | 2005-08-26 | 삼성전자주식회사 | 팩시밀리 장치용 보안 시스템 및 팩시밀리용 보안 시스템을 이용한 문서 데이터 선택적 출력 방법 |
US20040208828A1 (en) * | 2003-02-04 | 2004-10-21 | Lutz Lehmann | Enantiomer-pure (4S,8S)- and (4R,8R)-4-p-nitrobenzyl-8-methyl-3,6,9-triaza-3N,6N,9N-tricarboxymethyl-1,11-undecanedioic acid and derivatives thereof, process for their production and use for the production of pharmaceutical agents |
DE10311634A1 (de) * | 2003-03-14 | 2004-09-30 | Authentidate International Ag | Elektronisches Übermitteln von Dokumenten |
US8261062B2 (en) * | 2003-03-27 | 2012-09-04 | Microsoft Corporation | Non-cryptographic addressing |
US10063523B2 (en) * | 2005-09-14 | 2018-08-28 | Oracle International Corporation | Crafted identities |
US9781154B1 (en) | 2003-04-01 | 2017-10-03 | Oracle International Corporation | Systems and methods for supporting information security and sub-system operational protocol conformance |
US10275723B2 (en) * | 2005-09-14 | 2019-04-30 | Oracle International Corporation | Policy enforcement via attestations |
CA2525398C (en) * | 2003-05-13 | 2014-03-11 | Corestreet, Ltd. | Efficient and secure data currentness systems |
EP1636682A4 (de) * | 2003-06-24 | 2009-04-29 | Corestreet Ltd | Zugangskontrolle |
US8468330B1 (en) | 2003-06-30 | 2013-06-18 | Oracle International Corporation | Methods, systems, and data structures for loading and authenticating a module |
US7500100B1 (en) | 2003-09-10 | 2009-03-03 | Cisco Technology, Inc. | Method and apparatus for verifying revocation status of a digital certificate |
JP4585189B2 (ja) * | 2003-09-19 | 2010-11-24 | 富士通株式会社 | 電子署名付与装置、電子署名付与方法および電子署名付与プログラム |
US8453196B2 (en) | 2003-10-14 | 2013-05-28 | Salesforce.Com, Inc. | Policy management in an interoperability network |
US20060184452A1 (en) * | 2003-10-14 | 2006-08-17 | Maccord Mason Pllc, | Electronic document management system |
CN101124765B (zh) * | 2003-11-19 | 2013-08-07 | 科尔街有限公司 | 分布式代表路径发现与确认 |
US8775654B2 (en) | 2003-12-19 | 2014-07-08 | Salesforce.Com, Inc. | Apparatus and methods for mediating messages |
CA2551819C (en) * | 2004-01-09 | 2015-02-24 | Corestreet, Ltd. | Signature-efficient real time credentials for ocsp and distributed ocsp |
AU2005210510B2 (en) * | 2004-02-04 | 2006-06-29 | Globecharge Pty Ltd | A system and method for electronic commerce |
CA2555382A1 (en) * | 2004-02-04 | 2005-08-18 | Globecharge Pty Ltd | A system and method for electronic commerce |
JP4569118B2 (ja) * | 2004-02-05 | 2010-10-27 | 株式会社日立製作所 | 署名検証ログを作成する検証結果記録方法とその装置 |
JP4036838B2 (ja) * | 2004-03-12 | 2008-01-23 | インターナショナル・ビジネス・マシーンズ・コーポレーション | セキュリティ装置、情報処理装置、セキュリティ装置が実行する方法、情報処理装置が実行する方法、該方法を実行させるための装置実行可能なプログラムおよびチケット・システム |
US7853790B2 (en) * | 2004-03-19 | 2010-12-14 | Microsoft Corporation | Enhancement to volume license keys |
JP2005303779A (ja) * | 2004-04-14 | 2005-10-27 | Nippon Telegr & Teleph Corp <Ntt> | 証明書発行サービス方法、証明書発行サービス装置及び証明書発行サービスプログラム |
JP2005309780A (ja) * | 2004-04-21 | 2005-11-04 | Ntt Docomo Inc | Icカード及び権限委譲制御方法 |
US7929689B2 (en) * | 2004-06-30 | 2011-04-19 | Microsoft Corporation | Call signs |
US7725605B2 (en) | 2004-08-06 | 2010-05-25 | Salesforce.Com, Inc. | Providing on-demand access to services in a wide area network |
WO2006031723A2 (en) * | 2004-09-13 | 2006-03-23 | Coretrace Corporation | Method and system for license management |
US8312431B1 (en) * | 2004-09-17 | 2012-11-13 | Oracle America, Inc. | System and computer readable medium for verifying access to signed ELF objects |
US9645712B2 (en) | 2004-10-01 | 2017-05-09 | Grand Central Communications, Inc. | Multiple stakeholders for a single business process |
JP4999300B2 (ja) * | 2004-10-22 | 2012-08-15 | 株式会社リコー | スキャン装置、スキャンサービス利用装置、認証サービス提供装置、スキャンサービスプログラム、スキャンサービス利用プログラム、認証サービスプログラム、記録媒体、スキャン方法、スキャンサービス利用方法及び認証サービス提供方法 |
US7205882B2 (en) * | 2004-11-10 | 2007-04-17 | Corestreet, Ltd. | Actuating a security system using a wireless device |
US8438645B2 (en) | 2005-04-27 | 2013-05-07 | Microsoft Corporation | Secure clock with grace periods |
FR2884089B1 (fr) * | 2005-04-04 | 2007-05-18 | Lex Persona Soc Par Actions Si | Signature electronique renforcee |
US9436804B2 (en) | 2005-04-22 | 2016-09-06 | Microsoft Technology Licensing, Llc | Establishing a unique session key using a hardware functionality scan |
US9363481B2 (en) | 2005-04-22 | 2016-06-07 | Microsoft Technology Licensing, Llc | Protected media pipeline |
WO2007028407A1 (en) * | 2005-09-06 | 2007-03-15 | Nero Ag | Method for signing a data package and signing apparatus |
US8560853B2 (en) * | 2005-09-09 | 2013-10-15 | Microsoft Corporation | Digital signing policy |
FR2892252B1 (fr) * | 2005-10-17 | 2008-01-25 | Oberthur Card Syst Sa | Procede et dispositif de creation d'une signature de groupe et procede et dispositif de verification d'une signature de groupe associes. |
JP2007232754A (ja) * | 2006-02-27 | 2007-09-13 | Toshiba Corp | ハッシュ値生成装置及びハッシュ値生成方法 |
WO2008054512A2 (en) * | 2006-04-19 | 2008-05-08 | Stepnexus Holdings | Methods and systems for ic card application loading |
US8086842B2 (en) * | 2006-04-21 | 2011-12-27 | Microsoft Corporation | Peer-to-peer contact exchange |
US8171523B2 (en) | 2006-04-29 | 2012-05-01 | Lenovo (Singapore) Pte. Ltd. | Embedded email receiver authentication |
US20080059803A1 (en) * | 2006-09-06 | 2008-03-06 | Zeon Corporation | Method for the authentication of printed document |
US9355273B2 (en) * | 2006-12-18 | 2016-05-31 | Bank Of America, N.A., As Collateral Agent | System and method for the protection and de-identification of health care data |
US8250664B2 (en) * | 2007-02-23 | 2012-08-21 | Panasonic Corporation | Copyright protection data processing system and reproduction device |
US20090031135A1 (en) * | 2007-07-27 | 2009-01-29 | Raghunathan Kothandaraman | Tamper Proof Seal For An Electronic Document |
JP4444998B2 (ja) * | 2007-10-12 | 2010-03-31 | 富士通株式会社 | 電子メール情報管理プログラム、電子メール情報管理装置、および電子メール情報管理方法 |
US20090106331A1 (en) * | 2007-10-22 | 2009-04-23 | General Electric Company | Dynamic two-stage clinical data archiving and retrieval solution |
DE102008008969B4 (de) * | 2008-02-13 | 2022-07-14 | Bayerische Motoren Werke Aktiengesellschaft | Bordnetz-System eines Kraftfahrzeugs mit einer Authentifizierungs-Vorrichtung |
US8875013B2 (en) * | 2008-03-25 | 2014-10-28 | International Business Machines Corporation | Multi-pass validation of extensible markup language (XML) documents |
US8051012B2 (en) * | 2008-06-09 | 2011-11-01 | Hewlett-Packard Development Company, L.P. | System and method for discounted printing |
US7530106B1 (en) | 2008-07-02 | 2009-05-05 | Kaspersky Lab, Zao | System and method for security rating of computer processes |
US20100114607A1 (en) * | 2008-11-04 | 2010-05-06 | Sdi Health Llc | Method and system for providing reports and segmentation of physician activities |
US9141758B2 (en) * | 2009-02-20 | 2015-09-22 | Ims Health Incorporated | System and method for encrypting provider identifiers on medical service claim transactions |
US8635442B2 (en) | 2009-04-28 | 2014-01-21 | Adobe Systems Incorporated | System and method for long-term digital signature verification utilizing light weight digital signatures |
DE102009031143B3 (de) * | 2009-06-30 | 2010-12-09 | Siemens Aktiengesellschaft | Vorrichtung und Verfahren zum Erstellen und Validieren eines digitalen Zertifikats |
US9251131B2 (en) | 2010-05-04 | 2016-02-02 | Docusign, Inc. | Systems and methods for distributed electronic signature documents including version control |
US20120011229A1 (en) * | 2010-06-04 | 2012-01-12 | Peter Heller | Enhanced network/domain name hashing techniques |
JP2012165293A (ja) * | 2011-02-09 | 2012-08-30 | Secom Co Ltd | 電子署名装置及び署名検証装置 |
US9400974B2 (en) * | 2011-09-02 | 2016-07-26 | Jn Projects, Inc. | Systems and methods for annotating and sending electronic documents |
US8949954B2 (en) | 2011-12-08 | 2015-02-03 | Uniloc Luxembourg, S.A. | Customer notification program alerting customer-specified network address of unauthorized access attempts to customer account |
AU2012100460B4 (en) | 2012-01-04 | 2012-11-08 | Uniloc Usa, Inc. | Method and system implementing zone-restricted behavior of a computing device |
AU2012100462B4 (en) | 2012-02-06 | 2012-11-08 | Uniloc Usa, Inc. | Near field authentication through communication of enclosed content sound waves |
US11250423B2 (en) * | 2012-05-04 | 2022-02-15 | Institutional Cash Distributors Technology, Llc | Encapsulated security tokens for electronic transactions |
US9276749B2 (en) * | 2012-07-31 | 2016-03-01 | Adobe Systems Incorporated | Distributed validation of digitally signed electronic documents |
EP2757737A1 (de) * | 2013-01-16 | 2014-07-23 | Gemalto SA | Verfahren zum Aufbau einer Unterstützungsstruktur öffentlicher Daten |
AU2013100355B4 (en) | 2013-02-28 | 2013-10-31 | Netauthority, Inc | Device-specific content delivery |
CN107851111A (zh) | 2015-05-05 | 2018-03-27 | 识卡公司 | 使用区块链的身份管理服务 |
US9876646B2 (en) | 2015-05-05 | 2018-01-23 | ShoCard, Inc. | User identification management system and method |
US11392944B2 (en) * | 2015-05-20 | 2022-07-19 | Ripple Luxembourg S.A. | Transfer costs in a resource transfer system |
US9912486B1 (en) * | 2015-08-27 | 2018-03-06 | Amazon Technologies, Inc. | Countersigned certificates |
US9888037B1 (en) | 2015-08-27 | 2018-02-06 | Amazon Technologies, Inc. | Cipher suite negotiation |
US10454689B1 (en) | 2015-08-27 | 2019-10-22 | Amazon Technologies, Inc. | Digital certificate management |
US10694352B2 (en) | 2015-10-28 | 2020-06-23 | Activision Publishing, Inc. | System and method of using physical objects to control software access |
US10587609B2 (en) | 2016-03-04 | 2020-03-10 | ShoCard, Inc. | Method and system for authenticated login using static or dynamic codes |
US10509932B2 (en) | 2016-03-07 | 2019-12-17 | ShoCard, Inc. | Large data transfer using visual codes with feedback confirmation |
US10007826B2 (en) | 2016-03-07 | 2018-06-26 | ShoCard, Inc. | Transferring data files using a series of visual codes |
JP6389350B2 (ja) * | 2016-03-31 | 2018-09-12 | 株式会社bitFlyer | トランザクション処理装置、トランザクション処理方法、及びそのためのプログラム |
EP4138339A1 (de) | 2016-07-29 | 2023-02-22 | Magic Leap, Inc. | Sicherer austausch von kryptographisch signierten aufzeichnungen |
US9838203B1 (en) * | 2016-09-28 | 2017-12-05 | International Business Machines Corporation | Integrity protected trusted public key token with performance enhancements |
EP3560136B1 (de) * | 2016-12-22 | 2020-12-02 | Itext Group NV | Verteiltes blockchain-basiertes verfahren zum speichern des orts einer datei |
USRE49968E1 (en) | 2017-02-06 | 2024-05-14 | Ping Identity Corporation | Electronic identification verification methods and systems with storage of certification records to a side chain |
US10498541B2 (en) | 2017-02-06 | 2019-12-03 | ShocCard, Inc. | Electronic identification verification methods and systems |
US10623188B2 (en) * | 2017-04-26 | 2020-04-14 | Fresenius Medical Care Holdings, Inc. | Securely distributing medical prescriptions |
US11170370B1 (en) * | 2017-07-14 | 2021-11-09 | Wells Fargo Bank, N.A. | Systems and methods for distributed management of negative certificates for blockchain-based value exchange transactions |
EP3721578B1 (de) | 2017-12-08 | 2022-09-07 | Ping Identity Corporation | Verfahren und systeme zur rückgewinnung von daten unter verwendung dynamischer passwörter |
US10979227B2 (en) | 2018-10-17 | 2021-04-13 | Ping Identity Corporation | Blockchain ID connect |
US11082221B2 (en) | 2018-10-17 | 2021-08-03 | Ping Identity Corporation | Methods and systems for creating and recovering accounts using dynamic passwords |
IT201900004201A1 (it) * | 2019-03-22 | 2020-09-22 | Carlo Tenca | Metodo per realizzare un registro di documenti pubblici certificati con firma elettronica |
US20200320622A1 (en) * | 2019-04-05 | 2020-10-08 | Secude Ag | Method and system for processing and documenting digital transactions |
US11170130B1 (en) | 2021-04-08 | 2021-11-09 | Aster Key, LLC | Apparatus, systems and methods for storing user profile data on a distributed database for anonymous verification |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4405829A (en) * | 1977-12-14 | 1983-09-20 | Massachusetts Institute Of Technology | Cryptographic communications system and method |
US4438824A (en) * | 1981-04-22 | 1984-03-27 | Siemens Corporation | Apparatus and method for cryptographic identity verification |
US4471163A (en) * | 1981-10-05 | 1984-09-11 | Donald Thomas C | Software protection system |
US4759064A (en) * | 1985-10-07 | 1988-07-19 | Chaum David L | Blind unanticipated signature systems |
US4759063A (en) * | 1983-08-22 | 1988-07-19 | Chaum David L | Blind signature systems |
US4799258A (en) * | 1984-02-13 | 1989-01-17 | National Research Development Corporation | Apparatus and methods for granting access to computers |
US4625076A (en) * | 1984-03-19 | 1986-11-25 | Nippon Telegraph & Telephone Public Corporation | Signed document transmission system |
US4633036A (en) * | 1984-05-31 | 1986-12-30 | Martin E. Hellman | Method and apparatus for use in public-key data encryption system |
DE3650533T2 (de) * | 1985-02-14 | 1996-10-31 | Nippon Electric Co | Funkübertragungssystem mit Einrichtung zur Verhinderung des Abhörens eines zwischen einer Feststation und einer mobilen Station übertragenen Funkübertragungssignals |
US4771461A (en) * | 1986-06-27 | 1988-09-13 | International Business Machines Corporation | Initialization of cryptographic variables in an EFT/POS network with a large number of terminals |
FR2601795B1 (fr) * | 1986-07-17 | 1988-10-07 | Bull Cp8 | Procede pour diversifier une cle de base et pour authentifier une cle ainsi diversifiee comme ayant ete elaboree a partir d'une cle de base predeterminee, et systeme pour la mise en oeuvre |
FR2620248B1 (fr) * | 1987-09-07 | 1989-11-24 | France Etat | Procedes d'authentification d'accreditations ou de messages a apport nul de connaissance et de signature de messages |
US4868877A (en) * | 1988-02-12 | 1989-09-19 | Fischer Addison M | Public key/signature cryptosystem with enhanced digital signature certification |
US4888801A (en) * | 1988-05-02 | 1989-12-19 | Motorola, Inc. | Hierarchical key management system |
US4924515A (en) * | 1988-08-29 | 1990-05-08 | International Business Machines Coprporation | Secure management of keys using extended control vectors |
-
1989
- 1989-03-07 US US07/319,780 patent/US5005200A/en not_active Expired - Lifetime
- 1989-10-03 AU AU42425/89A patent/AU620291B2/en not_active Expired
- 1989-10-10 CA CA002000400A patent/CA2000400C/en not_active Expired - Lifetime
-
1990
- 1990-01-11 AT AT93202945T patent/ATE150605T1/de not_active IP Right Cessation
- 1990-01-11 EP EP93202945A patent/EP0586022B1/de not_active Expired - Lifetime
- 1990-01-11 DE DE199090300322T patent/DE386867T1/de active Pending
- 1990-01-11 ES ES90300322T patent/ES2036978T3/es not_active Expired - Lifetime
- 1990-01-11 AT AT90300322T patent/ATE113429T1/de not_active IP Right Cessation
- 1990-01-11 DK DK90300322.6T patent/DK0386867T3/da active
- 1990-01-11 EP EP90300322A patent/EP0386867B1/de not_active Expired - Lifetime
- 1990-01-11 DE DE69030268T patent/DE69030268T2/de not_active Expired - Lifetime
- 1990-01-11 ES ES93202945T patent/ES2098651T3/es not_active Expired - Lifetime
- 1990-01-11 DE DE69013541T patent/DE69013541T2/de not_active Expired - Lifetime
- 1990-03-05 JP JP05348390A patent/JP3520081B2/ja not_active Expired - Fee Related
-
1993
- 1993-06-30 GR GR930300050T patent/GR930300050T1/el unknown
Also Published As
Publication number | Publication date |
---|---|
AU4242589A (en) | 1990-09-13 |
DE386867T1 (de) | 1993-04-29 |
DE69030268T2 (de) | 1997-06-26 |
ATE150605T1 (de) | 1997-04-15 |
CA2000400C (en) | 1996-10-08 |
ATE113429T1 (de) | 1994-11-15 |
ES2098651T3 (es) | 1997-05-01 |
EP0586022B1 (de) | 1997-03-19 |
ES2036978T1 (es) | 1993-06-16 |
JP3520081B2 (ja) | 2004-04-19 |
EP0386867A2 (de) | 1990-09-12 |
CA2000400A1 (en) | 1990-09-07 |
EP0386867A3 (de) | 1992-06-10 |
EP0586022A1 (de) | 1994-03-09 |
AU620291B2 (en) | 1992-02-13 |
DE69030268D1 (de) | 1997-04-24 |
DE69013541D1 (de) | 1994-12-01 |
DK0386867T3 (da) | 1995-04-03 |
US5005200A (en) | 1991-04-02 |
JPH02291043A (ja) | 1990-11-30 |
EP0386867B1 (de) | 1994-10-26 |
GR930300050T1 (en) | 1993-06-30 |
ES2036978T3 (es) | 1995-01-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE69013541T2 (de) | Kryptosystem mit öffentlichem Schlüssel und/oder Unterschrift und mit digitaler Unterschriftsbeglaubigung. | |
EP3596653B1 (de) | Ausstellen virtueller dokumente in einer blockchain | |
DE68922422T2 (de) | Kryptographisches Unterschriftssystem mittels öffentlichem Schlüssel und mit digitaler Unterschriftsbeglaubigung. | |
DE60304744T2 (de) | Verfahren,vorrichtung und computerprogramme zur erzeugung und/oder verwendungkonditionaler elektronischer signaturen zur meldung von statusänderungen | |
DE60034159T2 (de) | Verfahren zur elektronischen speicherung und wiedergewinnung von authentifizierten originaldokumenten | |
DE69932512T2 (de) | Gerät und verfahren zur elektronischen versendung, speicherung und wiedergewinnung von authentifizierten dokumenten | |
DE69534490T2 (de) | Verfahren zur sicheren anwendung digitaler unterschriften in einem kommerziellen verschlüsselungssystem | |
US7039805B1 (en) | Electronic signature method | |
DE60211841T2 (de) | Vorrichtung zur Aktualisierung und zum Entzug der Gültigkeit einer Marke in einer Infrastruktur mit öffentlichen Schlüsseln | |
US5214702A (en) | Public key/signature cryptosystem with enhanced digital signature certification | |
DE3841393C2 (de) | Zuverlässiges System zur Feststellung der Dokumentenechtheit | |
DE60026468T2 (de) | Digitales Zertifikat mit Berechtigungsdaten | |
US7539700B2 (en) | Method and system for transmitting secured electronic documents | |
EP3318999B1 (de) | Verfahren zum ausstellen einer virtuellen version eines dokuments | |
EP3993318B1 (de) | Blockchain-basiertes digitales dokumentensystem | |
EP3814970B1 (de) | Manipulationssicheres ausstellen und speichern von elektronischen urkunden | |
WO2000011833A1 (de) | Verfahren und anordnung zur bildung eines geheimen kommunikationsschlüssels zu einem zuvor ermittelten asymmetrischen kryptographischen schlüsselpaar | |
CN107229879A (zh) | 基于安全二维码的电子询证函自动生成方法及*** | |
DE60122349T2 (de) | Verahren zur erzeugung von nachweisen über das senden und empfangen eines elektronischen schreibens und seines inhaltes über ein netzwerk | |
WO2022200035A1 (de) | Verfahren und vorrichtung zum erzeugen, bereitstellen und weitergeben eines vertrauenswürdigen elektronischen datensatzes oder zertifikates basierend auf einem einen nutzer betreffenden elektronischen dokument | |
EP3913886A1 (de) | Ausstellen digitaler dokumente mit einer blockchain | |
DE69605654T2 (de) | Elektronisch verhandelbare dokumente | |
DE102022107718A1 (de) | Ausstellen eines digitalen Credentials für eine Entität | |
EP4174703A1 (de) | Wiederherstellen eines kryptografischen schlüssels | |
EP4174700A1 (de) | Bereitstellen eines digitalen dokuments |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8364 | No opposition during term of opposition |