DE60112546T2 - Bestätigungsdienst mit öffentlichem schlüssel - Google Patents

Bestätigungsdienst mit öffentlichem schlüssel Download PDF

Info

Publication number
DE60112546T2
DE60112546T2 DE60112546T DE60112546T DE60112546T2 DE 60112546 T2 DE60112546 T2 DE 60112546T2 DE 60112546 T DE60112546 T DE 60112546T DE 60112546 T DE60112546 T DE 60112546T DE 60112546 T2 DE60112546 T2 DE 60112546T2
Authority
DE
Germany
Prior art keywords
certificate
subject
pkvc
public key
unsigned
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
Application number
DE60112546T
Other languages
English (en)
Other versions
DE60112546D1 (de
Inventor
Francisco Corella
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Development Co LP
Original Assignee
Hewlett Packard Development Co LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Development Co LP filed Critical Hewlett Packard Development Co LP
Publication of DE60112546D1 publication Critical patent/DE60112546D1/de
Application granted granted Critical
Publication of DE60112546T2 publication Critical patent/DE60112546T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • 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/3236—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 using cryptographic hash functions
    • H04L9/3239—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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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/002—Countermeasures against attacks on cryptographic mechanisms
    • 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/006—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving public key infrastructure [PKI] trust models
    • 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/3268—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 validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • 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/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

  • Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich auf Öffentlicher-Schlüssel-Kryptosysteme und insbesondere auf ein Öffentlicher-Schlüssel-Validierungssystem zum Validieren eines öffentlichen Schlüssels.
  • Öffentlicher-Schlüssel-Kryptosysteme werden weltweit im World Wide Web verwendet, und auch bei einer wachsenden Anzahl von Firmennetzwerken, für die Einrichtung sicherer Kommunikationskanäle. Jeder Nutzer in einem Öffentlicher-Schlüssel-Kryptosystem hat ein Paar von Schlüsseln, einschließlich einem öffentlichen Schlüssel und einem privaten Schlüssel. Der öffentliche Schlüssel wird anderen Benutzern offenbart, während der private Schlüssel geheimgehalten wird. Ein Öffentlicher-Schlüssel-Kryptosystem hat typischerweise eine bestimmte Hauptverwendung, wie z. B. für Verschlüsselung, digitale Signatur oder Schlüsselübereinstimmung. Öffentlicher-Schlüssel-Kryptosysteme werden auch für Benutzerauthentifizierung verwendet. Beispielsweise kann sich ein Benutzer selbst für andere Benutzer authentifizieren durch Nachweisen seiner Kenntnis seines privaten Schlüssels, den andere Benutzer unter Verwendung des entsprechenden öffentlichen Schlüssels verifizieren können.
  • Bei einer Anwendung eines Öffentlicher-Schlüssel-Kryptosystems zum Authentifizieren eines Benutzers muss der öffentliche Schlüssel der Identität des Benutzers sicher zugeordnet sein, der den öffentlichen Schlüssel besitzt, durch Authentifizieren des öffentlichen Schlüssels selbst. Typischerweise werden Öffentlicher-Schlüssel-Zertifikate verwendet, um den öffentlichen Schlüssel zu authentifizieren. Ein Öffentlicher-Schlüssel-Zertifikat ist ein digitales Dokument, das durch eine Zertifikatautorität unterzeichnet ist, das einen öffentlichen Schlüssel mit einem oder mehreren Attributen verbindet, die den Besitzer des öffentlichen Schlüssels eindeutig identifizieren. Das Öffentlicher-Schlüssel-Zertifikat kann unter Verwendung des öffentlichen Schlüssels der Zertifikatautorität verifiziert werden, von dem angenommen wird, dass es gut bekannt ist oder rekursiv durch eine höhere Autorität zertifiziert. Beispielsweise kann in einer Firma ein Öffentlicher-Schlüssel-Zertifikat einen öffentlichen Schlüssel mit einer Angestelltennummer verbinden.
  • Eine Öffentlicher-Schlüssel-Infrastruktur (PKI = public key infrastructure) bezieht sich auf die Sammlung von Entitäten, Datenstrukturen und Prozeduren, die verwendet werden, um öffentliche Schlüssel zu authentifizieren. Eine traditionelle PKI umfasst eine Zertifikatautorität, Öffentlicher-Schlüssel-Zertifikate und Prozeduren zum Verwalten und Verwenden der Öffentlicher-Schlüssel-Zertifikate.
  • Ein Typ eines Benutzers einer PKI besitzt den öffentlichen Schlüssel, der in einem Öffentlicher-Schlüssel-Zertifikat enthalten ist und verwendet das Zertifikat, um die Identität des Benutzers nachzuweisen. Dieser Typ von Benutzer wird als das Subjekt des Zertifikats bezeichnet oder allgemeiner als das Subjekt. Ein weiterer Typ von Benutzer verlässt sich auf ein Öffentlicher-Schlüssel-Zertifikat, das durch einen anderen Benutzer präsentiert wird, um zu verifizieren, dass der andere Benutzer das Subjekt des Zertifikats ist und dass die Attribute, die in dem Zertifikat enthalten sind, für den anderen Benutzer gelten. Dieser Typ von Benutzer, der sich auf das Zertifikat verlässt, wird als ein Verifizierer oder eine Vertrauenspartei bezeichnet.
  • Die Zuordnung zwischen einem öffentlichen Schlüssel und einer Identität kann ungültig werden, wenn die Attribute, die die Identität definieren, nicht mehr für den Besitzer des öffentlichen Schlüssels gelten, oder weil der öffentliche Schlüssel, der dem öffentlichen Schlüssel entspricht, beeinträchtigt wurde. Eine PKI verwendet typischerweise zwei komplementäre Techniken zum Trennen eines öffentlichen Schlüssels von einer Identität. Bei der ersten Technik hat jeder öffentliche Schlüssel jedes Öffentlicher-Schlüssel-Zertifikat eine Gültigkeitsperiode, die durch ein Ablaufdatum definiert ist, das eine wesentliche Periode von dem Ausgabedatum entfernt ist, wie z. B. ein Jahr ab dem Ausgabedatum. Bei der zweiten Technik hebt die Zertifikatautorität ein Öffentlicher-Schlüssel-Zertifikat auf, falls die Bindung des Öffentlicher-Schlüssel-Zertifikats vor dem Ablaufdatum ungültig wird. Eine Möglichkeit zum Aufheben eines Öffentlicher-Schlüssel-Zertifikats ist das Aufnehmen einer Seriennummer des Öffentlicher-Schlüssel-Zertifikats in eine Zertifikat-Aufhebungsliste (CRL = certificate revocation list), die durch die Zertifikatautorität in bekannten regelmäßigen Intervallen, wie z. B. alle paar Stunden oder einmal am Tag, unterzeichnet und ausgegeben wird. Eine Entität, die sich auf ein Zertifikat verlässt, ist verantwortlich für das Erhalten der neuesten Version der CRL und für das Verifizieren, dass die Seriennummer des Öffentlicher-Schlüssel-Zertifikats nicht auf der Liste ist.
  • CRLs werden typischerweise sehr schnell sehr lang. Wenn die CRLs lang werden, ist die Leistungsfähigkeit stark beeinträchtigt. Zunächst verbraucht die CRL-Wiedergewinnung große Mengen an Netzwerkbandbreite. Zweitens muss jede Anwendung die CRL regelmäßig wiedergewinnen, die CRL syntaktisch analysieren und Speicher für die CRL zuweisen. Dann muss die Anwendung eine lineare Suche der CRL durchführen, nach der Öffentlicher-Schlüssel-Zertifikat-Seriennummer, wenn die Anwendung jedes Öffentlicher-Schlüssel-Zertifikat verifiziert. Als Folge steigen herkömmliche PKIs nicht über einige tausend Benutzer an.
  • Eine Lösung, die vorgeschlagen wurde, um das lineare Suchproblem zu lindern, ist das Unterteilen der CRLs. Die Seriennummer des Öffentlicher-Schlüssel-Zertifikats bestimmt, wo die CRL-Unterteilung positioniert ist, wenn das Öffentlicher-Schlüssel-Zertifikat aufgehoben wird. Mit unterteilten CRLs muss die Anwendung nach wie vor die gesamte CRL wiedergewinnen und speichern, oder andernfalls muss die Anforderung eine CRL-Unterteilung abrufen, um ein Zertifikat zu verifizieren. Da eine Zertifikats-Verifizierung ein wahrscheinlich kritischer Weg ist, beeinträchtigt das Abrufen einer CRL-Unterteilung die Zeit, die benötigt wird, um die Anwendung auszuführen.
  • Ein On-Line-Zertifikat-Statusprotokoll (OCSP; OCSP = on-line certificate status protocol) arbeitet, indem es dem Verifizierer des Öffentlicher-Schlüssel-Zertifikat ermöglicht, die Zertifikatautorität zu fragen, ob das Zertifikat aktuell gültig ist. Die Zertifikatautorität antwortet mit einer unterzeichneten Erklärung. Die OCSP ermöglicht es, dass CRLs umgangen werden, erfordert jedoch, dass der Verifizierer die Zertifikatautorität abfragt, als Teil der Transaktion, die die Öffentlicher-Schlüssel-Zertifikate verwendet. Der Verifizierer, der die Zertifikatautorität abfragt, erhöht die Zeit, die notwendig ist, um die Transaktion durchzuführen. Das OCSP-Schema ist stark anfällig für einen Dienstverweigerungsangriff, bei dem der Angreifer die Zertifikatautorität mit Abfragen überflutet. Das Antworten auf jede Abfrage ist rechentechnisch aufwendig, weil jede Antwort eine digitale Signatur erfordert.
  • Bei einem Zertifikat-Statusbeweisschema behält die Zertifikatautorität eine Datenstruktur bei, die den Satz von gültigen und ungültigen Zertifikaten in dem Verzeichnis beschreibt. Für jedes Öffentlicher-Schlüssel-Zertifikat, das noch nicht abgelaufen ist, kann ein kurzer kryptographischer Beweis von der Datenstruktur des aktuellen Status des Zertifikats (d. h. gültig oder ungültig) extrahiert werden. Eine CRL kann im wesentlichen als ein kryptographischer Beweis der Ungültigkeit für die Öffentlicher-Schlüssel-Zertifikate in der CRL gesehen werden, und ein Beweis für die Gültigkeit für diejenigen, die nicht in der CRL sind. Die CRL ist jedoch kein kurzer Beweis. Der kurze kryptographische Beweis kann durch den Verifizierer von dem Verzeichnis erhalten werden, oder derselbe kann durch das Subjekt erhalten werden und dem Verifizierer zusammen mit dem Öffentlicher-Schlüssel-Zertifikat präsentiert werden.
  • Die SPKI-Arbeitsgruppe (SPKI = Simple Public Key Infrastructure = einfache Öffentlicher-Schlüssel-Infrastruktur) der Internetgesellschaft (Internet Society) und der Internetarbeitsgruppe (Internet Engineering Task Force) hat die Möglichkeit vorgeschlagen, kurzlebige Zertifikate als ein Verfahren zum Erreichen einer dichten Steuerung über das Gültigkeitsintervall eines Zertifikats zu erhalten. Siehe C.M. Ellison, B. Frantz, B. Lampson, R. Rivest, B.M. Thomas and T. Ylonen, SPKI Certificate Theory, Request for Comments 2560 of the Internet Engineering Task Force, September 1999. Die SPKI-Zertifikats-Theorie-Referenz gibt an, dass es Fälle gibt, in denen ein kurzlebiges Zertifikat weniger Signaturen und weniger Netzwerkverkehr erfordert als verschiedene On-Line-Testoptionen. Die Verwendung eines kurzlebigen Zertifikats erfordert immer weniger Signaturverifizierungen als die Verwendung eines Zertifikats plus On-Line-Testergebnis.
  • RFC2510:Internetx509 Öffentlicher-Schlüssel-Infrastruktur, Zertifikationsveraltungsprotokoll (März 1999) offenbart Protokollmitteilungen von Zertifikatserzeugung und – verwaltung.
  • Trotzdem wurde kein praktisches Verfahren zum Ausgeben kurzlebiger Zertifikate vorgeschlagen. Traditionelle Zertifikate werden off-line erstellt, als Teil eines Prozesses, der Subjektregistrierung umfasst, bei der Geschwindigkeit von einem pro Jahr pro Benutzer. Im Gegensatz dazu müssten kurzlebige Zertifikate on-line bei einer Geschwindigkeit von zumindest einem pro Tag pro Benutzer ausgegeben werden, und vielleicht auch so oft wie alle paar Minuten für jeden Benutzer.
  • Der Begriff On-Line und der Begriff Off-Line haben im Zusammenhang einer PKI bestimmte Definitionen. Der Begriff On-Line bezieht sich hierin auf die alltägliche Verwendung von Öffentlicher-Schlüssel-Zertifikaten und Schlüsselpaaren für Authentifizierung. Der Begriff Off-Line bezieht sich hierin auf die weniger häufige Herstellung oder Auflösung von Öffentlicher-Schlüssel-Bindungen, die zu dem- Ausgeben oder Aufheben von Öffentlicher-Schlüssel-Zertifikaten führen kann. Beispielsweise ist die traditionelle Zertifikatautorität off-line, erteilt CRLs off-line und platziert die CRLs in ein Verzeichnis für eine On-Line-Wiedergewinnung. Das Schema, das Zertifikat-Statusbeweise umfasst, verwendet auch Off-Line-Zertifikatautoritäten. Das OCSP ist das einzige Schema, das oben beschrieben wurde, das eine On-Line-Zertifikatautorität verwendet.
  • Bei einer herkömmlichen PKI wird ein öffentlicher Schlüssel durch ein Zertifikat authentifiziert, das durch eine Zertifikatsautorität unterzeichnet ist. Falls der private Schlüssel, der dem öffentlichen Schlüssel zugeordnet ist, beeinträchtigt ist, benachrichtigt der Gegenstand des Zertifikats die Zertifikatsautorität, die das Zertifikat aufhebt.
  • Es ist jedoch denkbar, dass das gleiche Privater/Öffentlicher-Schlüssel-Paar für mehrere Zwecke verwendet werden könnte. Für einige Zwecke könnte der öffentliche Schlüssel herkömmlicherweise durch ein oder mehrere herkömmliche Zertifikate authentifiziert werden, die durch eine oder mehrere Zertifikatautoritäten ausgegeben werden. Zu anderen Zwecken kann der öffentliche Schlüssel einem oder mehreren Verifizierern direkt bekannt sein und muss somit nicht authentifiziert werden.
  • Falls ein Privater/Öffentlicher-Schlüssel-Paar für mehrere Zwecke verwendet wird, wird es notwendig, die weitere Verwendung des Schlüsselpaares für eine der mehreren Zwecke zu verhindern, wenn der private Schlüssel beeinträchtigt ist. Das Aufheben eines einzigen Zertifikats ist nicht länger ausreichend, um alle Verwendungen des Privater/Öffentlicher-Schlüssel-Paars zu verhindern. Somit wäre es wünschenswert, eine praktische Art und Weise für eine Einzelaktion zu liefern, die durch den Besitzer des Privater/Öffentlicher-Schlüssel-Paars durchgeführt wird, um jede weitere Verwendung des Schlüsselpaars zu verhindern, die es einem Eindringling ermöglichen würde, sich als der rechtmäßige Besitzer des Schlüsselpaares auszugeben.
  • E-Commerce-Szenario
  • In einem E-Commerce-Szenario wäre es wünschenswert, mehrere Verwendungen eines einzelnen Öffentlicher/Privater-Schlüssel-Paars zu haben. Bei derzeitigen E-Commerce-Anwendungen weist der Web-Server des Einzelhändlers seine Identität unter Verwendung eines Öffentlicher/Privater-Schlüssel-Paars und eines öffentlichen Schlüssel-Zertifikats nach, das durch eine Zertifikatautorität unterzeichnet ist, deren öffentlicher Schlüssel in den Browsern konfiguriert ist. Der Kunde andererseits weist die Kundenidentität durch ein Passwort nach, das verschlüsselt gesendet wird, nachdem eine Sicherheitssockelschicht- (SSL-) Verbindung zwischen dem Browser und dem Server hergestellt wurde. Das Passwort wird eingerichtet, wenn sich der Kunde bei der E-Commerce-Site des Einzelhändlers registriert und wird verwendet, um den Kunden bei wiederholten Besuchen auf der Site zu identifizieren.
  • Obwohl Passwörter verschlüsselt gesendet werden, ist diese Verwendung von Passwörtern verletzbar, weil Kunden wahrscheinlich das gleiche Passwort verwenden, um auf alle Sites zuzugreifen. Ein Insider-Angriff bei einer Web-Site kann dem Angreifer Passwörter liefern, die verwendet werden können, um sich als Benutzer an anderen Sites auszugeben, wie z. B. bei beliebten Sites, wo die meisten E-Commerce-Kunden ein Konto haben. Ein Angreifer könnte auch eine gefälschte E-Commerce-Site einrichten, mit dem einzigen Zweck, Passwörter von Kunden zu sammeln, um auf die Konten dieser Kunden auf anderen Sites zuzugreifen.
  • Aufgrund dieser Verletzbarkeit von Passwörtern gibt es einen Bedarf an der Verwendung von Öffentlicher-Schlüssel-Kryptographie für Client-Authentifizierung, zusätzlich zu ihrer aktuellen Verwendung für Web-Server-Authentifizierung. Das SSL-Protokoll ermöglicht es dem Web-Browser, dem Server ein Clientzertifikat vorzulegen und die Kenntnis des privaten Schlüssels zu zeigen, der dem öffentlichen Schlüssel zugeordnet ist, der in dem Zertifikat enthalten ist. Der private Schlüssel kann in einer Smartcard gespeichert sein, für den Schutz gegen einen Software-Angriff.
  • Das herkömmliche PKI-Paradigma für E-Commerce verlangt, dass das Clientzertifikat durch eine Zertifikatautorität unterzeichnet ist, die unabhängig ist von einem bestimmten E-Commerce-Einzelhändler, wie z. B. durch eine kommerzielle Zertifikatautorität (z. B. Verisign). Es ist jedoch unwahrscheinlich, dass eine E-Commerce-Site ein Zertifikat annimmt, das durch eine dritte Zertifikatautorität ausgestellt ist, weil die E-Commerce-Site der Zertifikatautorität vertrauen müsste, um die Identität des Kunden einzurichten. E-Commerce-Einzelhändler haben ihre eigenen Prozesse zum Registrieren von Kunden entwickelt, die für ihre spezifischen Bedürfnisse zugeschnitten sind. Daher ist es unwahrscheinlich, dass E-Commerce-Einzelhändler ihre eigenen Prozesse verlassen und sich statt dessen auf eine Registrierung durch eine oder mehrere dritte Zertifikats-Autoritäten verlassen, über die sie keine Kontrolle haben.
  • Daher gibt es einen Wunsch nach einem alternativen PKI-Paradigma für E-Commerce, in dem der Kunde den öffentlichen Schlüssel des Kunden direkt bei der E-Commerce-Site registrieren könnte, als Teil des Kundenregistrierungsprozesses. Es ist wünschenswert, dass der Kunde bei einem solchen alternativen PKI-Paradigma den öffentlichen Schlüssel des Kunden liefern könnte statt eines Passworts, wenn er sich bei der Site registriert. Um das Modifizieren von SSL zu vermeiden, wäre es wünschenswert, dass der Kunde den öffentlichen Schlüssel in einem selbstunterzeichneten Clientzertifikat sendet.
  • In einem solchen E-Commerce-Szenario hat jeder Kunde ein Privater/Öffentlicher-Schlüssel-Paar, wobei der private Schlüssel sicher gespeichert ist und in einer Smartcard verwendet wird, und registriert den öffentlichen Schlüssel bei vielen unterschiedlichen E-Commerce-Sites. Somit wird das Privater/Öffentlicher-Schlüssel-Paar für viele Zwecke verwendet. Wenn der private Schlüssel beeinträchtigt ist, muss der Kunde die Verwendung des Privater/Öffentlicher-Schlüssels bei allen E-Commerce-Sites verhindern, wo der Kunde den öffentlichen Schlüssel registriert hat, und allein das Erinnern an all diese Sites könnte eine schwierige Aufgabe für den Kunden sein. Somit gibt es einen Bedarf an einem neuen Mechanismus, der es dem Kunden ermöglicht, die weitere Verwendung des Privater/Öffentlicher-Schlüsel-Paars auf allen Sites zu verhindern, indem eine einzige Aktion durchgeführt wird.
  • Ron Rivest, R.L. Rivest, Can we Eliminate Certificate Revocation Lists?, Proceedings of Financial Cryptography, 1998, („die Rivest-Schrift") hat eine Möglichkeit zum Verhindern der Verwendung eines Privater/Öffentlicher-Schlüssel-Paars vorgeschlagen, nachdem der private Schlüssel beeinträchtigt wurde. Das Verfahren, das in der Rivest-Schrift vorgeschlagen wird, verwendet eine Zuordnung von Freitod-Abteilungen. Der Besitzer eines Privater/Öffentlicher-Schlüssel-Paars registriert den öffentlichen Schlüssel bei einer Freitod-Abteilung. Wenn das Privater/Öffentlicher-Schlüssel-Paar beeinträchtigt ist, unterzeichnet der Benutzer eine Freitodnachricht unter Verwendung des privaten Schlüssels und sendet die Freitodnachricht an die Freitod-Abteilung, die die Freitodnachricht an die Vereinigung rundsendet. Obwohl der private Schlüssel nicht beeinträchtigt ist, kann der Besitzer ein Gesundheitszertifikat für den öffentlichen Schlüssel erhalten und es dem Verifizierer zusammen mit einem Öffentlicher-Schlüssel-Zertifikat präsentieren. Das Gesundheitszertifikat ist ein digitales Dokument, das durch die Freitod-Abteilung unterzeichnet ist, und bestätigt, dass die Freitod-Abteilung den öffentlichen Schlüssel registriert hat und keine Kenntnis einer Freitodnachricht für diesen öffentlichen Schlüssel hat.
  • Ein Nachteil des Freitodabteilungs-Verfahrens, das in der Rivest-Schrift vorgeschlagen wird, ist, dass, nachdem der rechtmäßige Besitzer eines Privater/Öffentlicher-Schlüssel-Paars den öffentlichen Schlüssel bei einer ersten Freitod-Abteilung registriert hat, ein Angreifer den gleichen öffentlichen Schlüssel bei einer anderen Freitod-Abteilung registrieren kann, mit der Erwartung, Kenntnis des privaten Schlüssels zu erlangen. Falls der Angreifer später Kenntnis des privaten Schlüssels erlangt und die Beeinträchtigung erfasst wird, sendet der rechtmäßige Besitzer des Privater/Öffentlicher-Schlüssel-Paars eine Freitodnachricht an die erste Freitod-Abteilung, aber der Angreifer kann nach wie vor ein Gesundheitszertifikat von der zweiten Freitod-Abteilung erhalten. Um dies zu vermeiden, müssen alle Freitod-Abteilungen zu einer einzigen Vereinigung gehören und müssen durch ein zuverlässiges Rundsendenetz verbunden sein, was in der Praxis schwierig zu erreichen ist. Die zweite Freitod-Abteilung muss auf dem Netzwerk hören und ihre Aufzeichnung des privaten Schlüssels ungültig machen, selbst wenn die Freitodnachricht für einen öffentlichen Schlüssel ist, der bei der ersten Freitod-Abteilung registriert wurde.
  • Ein zweiter Nachteil des vorgeschlagenen Freitod-Abteilungs-Verfahrens ist, dass nachdem ein öffentlicher Schlüssel beeinträchtigt wurde und die Freitod-Nachricht an alle Freitod-Abteilungen rundgesendet wurde, ein Angreifer den öffentlichen Schlüssel in einer neuen Registrierung bei der gleichen oder bei einer anderen Freitod-Abteilung registrieren könnte, und dann auf der Basis der neuen Registrierung Gesundheitszertifikate erhalten könnte. Um dies zu verhindern, muss jede Freitod-Abteilung eine perfekte Aufzeichnung jedes öffentlichen Schlüssels beibehalten, der in jeder Freitod-Abteilung registriert ist, für den jemals eine Freitod-Nachricht ausgestellt wurde. Dies ist wiederum schwierig in der Praxis umzusetzen.
  • Ein dritter Verfahrens-Nachteil des vorgeschlagenen Freitod-Abteilung-Verfahrens ist, dass das Verfahren nur auf Privater/Öffentlicher-Schlüssel-Paare anwendbar ist, die zu einem Signatur-Kryptosystem gehören, weil der private Schlüssel verwendet werden muss, um die Freitodnachricht zu unterzeichnen. Insofern kann das Verfahren nicht für Schlüsselpaare verwendet werden, die zu dem Diffie-Hellman (DH-) Kryptosystem gehören, da ein Diffie-Hellman-Privater-Schlüssel nicht verwendet werden kann, um Dokumente zu unterzeichnen.
  • Somit gibt es einen Bedarf an einer verbesserten Möglichkeit zum Verhindern der Verwendung eines Privater/Öffentlicher-Schlüssel-Paars, nachdem der private Schlüssel beeinträchtigt wurde, die nicht die obigen Nachteile des Freitod-Abteilung-Verfahrens hat, das in der Rivest-Schrift vorgeschlagen wird.
  • Zusammenfassung der Erfindung
  • Ein Aspekt der vorliegenden Erfindung liefert einen Öffentlicher-Schlüssel-Validierungsagenten (PKVA), der eine Off-Line-Registrierungsautorität und einen On-Line-Berechtigungsnachweisserver umfasst. Die Registrierungsautorität gibt ein erstes nicht-unterzeichnetes Öffentlicher-Schlüssel-Validierungszertifikat (nicht-unterzeichnetes PKVC) off-Line an ein Subjekt aus, das einen öffentlichen Schlüssel des Subjekts an eine erste Öffentlicher-Schlüssel-Seriennummer (PKVN) bindet. Die Registrierungsautorität behält eine Zertifikatdatenbank von nicht-unterzeichneten PKVCs bei, in denen dieselbe das erste nicht-unterzeichnete PKVC speichert. Der Berechtigungsnachweisserver gibt ein einmaliges Öffentlicher-Schlüssel-Validierungszertifikat (Einmal-PKVC) on-Line an das Subjekt aus. Das Einmal-PKVC bindet den öffentlichen Schlüssel des Subjekts von dem ersten nicht-unterzeichneten PKVC an die erste PKVN von dem ersten nicht-unterzeichneten PKVC. Der Berechtigungsnachweisserver behält eine Tabelle bei, die Einträge enthält, die gültigen nicht-unterzeichneten PKVCs entsprechen, die in der Zertifikat-Datenbank gespeichert sind.
  • Kurze Beschreibung der Zeichnungen
  • 1 ist ein Blockdiagramm einer leichten Öffentlicher-Schlüssel-Infrastruktur (PKI) gemäß der vorliegenden Erfindung, die kurzfristige Einmalzertifikate verwendet.
  • 2 ist ein Diagramm eines nicht-unterzeichneten Zertifikats, das von einer Registrierungsautorität der PKI von 1 ausgegeben wurde.
  • 3 ist ein Flussdiagramm eines Off-Line-Protokolls zum Ausgeben eines nicht-unterzeichneten Zertifikats von einer Registrierungsautorität der PKI von 1.
  • 4 ist ein Diagramm eines nicht-strukturierten kurzfristigen Einmalzertifikats, wie es durch den Berechtigungsnachweisserver des PKI von 1 ausgegeben wird.
  • 5 ist ein Flussdiagramm, das ein On-Line-Protokoll zum Ausgeben eines kurzfristigen Einmalzertifikats von einem Berechtigungsnachweisserver der PKI von 1 darstellt.
  • 6 ist ein Flussdiagramm, das ein On-Line-Protokoll für ein Subjekt darstellt, zum Nachweisen seiner Identität an einen Verifizierer der PKI von 1.
  • 7 ist ein Flussdiagramm, das ein Protokoll für eine Registrierungsautorität darstellt, zum Aufheben eines nicht-unterzeichneten Zertifikats für den PKI von 1.
  • 8 ist ein Blockdiagramm einer leichten PKI, die kurzfristige Einmalzertifikate für eine Autorisierung gemäß der vorliegenden Erfindung verwendet.
  • 9 ist ein Diagramm eines strukturierten kurzfristigen Einmalzertifikats, wie es durch einen Berechtigungsnachweisserver der PKI von 8 ausgegeben wird.
  • 10 ist ein Flussdiagramm, das ein On-Line-Protokoll zum Ausgeben eines strukturierten kurzfristigen Einmalzertifikats von einem Berechtigungsnachweisserver der PKI von 8 darstellt.
  • 11 ist ein Flussdiagramm, das ein On-Line-Protokoll darstellt, das durch ein Subjekt verwendet wird, um seine Identität einem Verifizierer der PKI von 8 nachzuweisen.
  • 12 ist ein Blockdiagramm einer verteilten Zertifikatautorität mit verteilten Berechtigungsnachweisservern gemäß der vorliegenden Erfindung.
  • 13 ist ein Blockdiagramm einer PKI mit einem Öffentlicher-Schlüssel-Validierungsdienst (PKVS), die Authentifizierung mit herkömmlichen Öffentlicher-Schlüssel-Zertifikaten verwendet.
  • 14 ist ein Diagramm eines nicht-unterzeichneten Öffentlicher-Schlüssel-Validierungszertifikats.
  • 15 ist ein Diagramm eines einmaligen Öffentlicher-Schlüssel-Validierungszertifikats.
  • 16 ist ein Diagramm eines aufhebbaren Zertifikats.
  • 17 ist ein Blockdiagramm einer PKI mit einem PKVS, die die Authentifizierung mit Einmalzertifikaten verwendet.
  • 18 ist ein Diagramm eines regulären nicht-unterzeichneten Zertifikats.
  • 19 ist ein Diagramm eines regulären Einmalzertifikats.
  • 20 ist ein Blockdiagramm einer PKI mit einem PKVS, die Authentifizierung mit nicht-unterzeichneten Zertifikaten verwendet.
  • 21 ist ein Diagramm eines regulären nicht-unterzeichneten Zertifikats.
  • 22 ist ein Blockdiagramm einer PKI mit einem PKVS, die Authentifizierung ohne Zertifikate verwendet, wie z. B. in einem E-Commerce-Szenario.
  • 23 ist ein Blockdiagramm eines Computersystems und eines entsprechenden computerlesbaren Mediums, das eine oder mehrere Hauptsoftwareprogramm- Komponenten einer PKI gemäß der vorliegenden Erfindung umfasst.
  • Beschreibung der bevorzugten Ausführungsbeispiele
  • Bei der folgenden detaillierten Beschreibung der bevorzugten Ausführungsbeispiele wird auf die beiliegenden Zeichnungen Bezug genommen, die einen Teil derselben bilden, und in der durch die Darstellung spezifische Ausführungsbeispiele gezeigt sind, in denen die Erfindung praktiziert werden kann. Es ist klar, dass andere Ausführungsbeispiele verwendet werden können und strukturelle oder logische Änderungen durchgeführt werden können, ohne von dem Schutzbereich der vorliegenden Erfindung abzuweichen. Die folgende detaillierte Beschreibung ist daher nicht in beschränkendem Sinne zu sehen und der Schutzumfang der vorliegenden Erfindung ist durch die angehängten Ansprüche definiert.
  • Die vorliegende Erfindung bezieht sich auf einen Öffentlicher-Schlüssel-Validierungsdienst (PKVS) zum Validieren eines öffentlichen Schlüssels eines Subjekts, bevor das Privater/Öffentlicher-Schlüssel-Paar des Subjekts für Authentifizierungsprozesse verwendet wird. Der PKVS der vorliegenden Erfindung ist besser verständlich, indem zunächst eine leichte PKI beschrieben wird, die Einmalzertifikate verwendet, wie sie z. B. in der mitanhängigen Patentanmeldung mit dem Titel „LIGHTWEIGHT PUBLIC KEY INFRASTRUCTURE EMPLOYING DISPOSABLE CERTIFICATES" beschrieben ist.
  • Leichte Öffentlicher-Schlüssel-Infrastruktur, die Einmalzertifikate verwendet
  • Eine leichte Öffentlicher-Schlüssel-Infrastruktur (PKI) gemäß der vorliegenden Erfindung ist allgemein bei 30 in 1 dargestellt. Die PKI 30 umfasst mehrere Hauptkompo nenten, die jeweils ein Softwareprogramm sind. Die Hauptsoftware-Programmkomponenten der PKI 30 laufen auf einem oder mehreren Computersystemen. Bei einem Ausführungsbeispiel läuft jede der Hauptsoftware-Programmkomponenten auf ihrem eigenen Computersystem.
  • Eine Zertifikatautorität 32 gibt kurzfristige Einmalzertifikate an ein oder mehrere Subjekte aus, wie z. B. das Subjekt 34. Das Subjekt 34 ist ein Benutzer, der einen öffentlichen Schlüssel besitzt, der in dem kurzfristigen Einmalzertifikat enthalten ist und verwendet das kurzfristige Einmalzertifikat, um die Identität des Subjekts einem oder mehreren Verifizierern, wie z. B. dem Verifizierer 36, nachzuweisen, durch Nachweisen, dass das Subjekt Kenntnis eines privaten Schlüssels hat, der dem öffentlichen Schlüssel in dem kurzfristigen Einmalzertifikat entspricht. Der Verifizierer 36 ist ein Benutzer, der sich auf das kurzfristige Einmalzertifikat verlässt, das durch das Subjekt 34 präsentiert wird, um zu verifizieren, dass das Subjekt 34 das Subjekt des kurzfristigen Einmalzertifikats ist und dass die Attribute, die in dem kurzfristigen Einmalzertifikat enthalten sind, für das Subjekt 34 gelten. Bei einigen Ausführungsbeispielen der PKT 30 kann der gleiche Benutzer in unterschiedlichen Situationen die Rolle des Subjekts 34 und des Verifizierers 36 spielen.
  • Die PKI 30 gibt keine traditionellen langfristigen Zertifikate aus, wie sie z. B. durch herkömmliche PKIs ausgegeben werden. Traditionelle langfristige Zertifikate haben typischerweise eine Gültigkeitsperiode, die durch ein Ablaufdatum definiert ist, das eine wesentliche Periode von dem Ausgabedatum entfernt ist, wie z. B. ein Jahr ab dem Ausgabedatum. Eine herkömmliche Zertifikatautorität muss ein traditionelles langfristiges Zertifikat aufheben, falls die Bindung des Öffentlicher-Schlüssel-Zertifikats vor dem Ablaufdatum ungültig wird. Wie es in der Beschreibungseinleitung der vorliegenden Beschreibung erörtert wird, wurden eine Vielzahl von Verfahren verwendet, um traditionelle langfristige Zertifikate aufzuheben, wie z. B. durch Verwenden einer Zertifikats-Aufhebungsliste (CHL) oder eines On-Line-Zertifikats-Statusprotokolls (OCSP).
  • Im Gegensatz zu traditionellen langfristigen Zertifikaten sind die kurzfristigen Einmalzertifikate, die durch die Zertifikatautorität 32 gemäß der vorliegenden Erfindung ausgegeben werden, keiner Aufhebung unterworfen. Die kurzfristigen Einmalzertifikate werden als einmalig bezeichnet, weil das Subjekt 34 dieselben nach einigen Benutzungen wegwerfen kann. Als Folge werden bei einem Ausführungsbeispiel der vorliegenden Erfindung die kurzfristigen Einmalzertifikate in einem flüchtigen Speicher gespeichert und nicht auf einer Platte gespeichert. Die PKI 30 wird als eine leichte PKI bezeichnet, weil dieselbe wesentlich einfacher und effizienter ist als eine herkömmliche PKI.
  • Ein kurzfristiges Einmalzertifikat ist hierin definiert als ein Öffentlicher-Schlüssel-Zertifikat, das den öffentlichen Schlüssel des Subjekts an einen oder mehrere Namen oder Identifizierer bindet und eine kurze Gültigkeitsperiode hat, die durch ein Ablaufdatum/-zeit bestimmt ist. Eine beispielhafte Gültigkeitsperiode für ein kurzfristiges Einmalzertifikat ist ein Tag, einige Stunden oder sogar einige wenige Minuten. Da die Gültigkeitsperiode recht kurz ist, ist eine Aufhebung nicht notwendig. Das Subjekt 34 fordert nach Bedarf ein neues kurzfristiges Einmalzertifikat an, und legt es dem Verifizierer 36 vor. Der Verifizierer 36 muss nur das Ablaufdatum/-zeit prüfen, um zu verifizieren, dass das kurzfristige Einmalzertifikat gültig ist.
  • Aus der Sicht des Verifizierers 36 ist die Verwendung von kurzfristigen Einmalzertifikaten ein viel besseres Schema als das Verwenden traditioneller langfristiger Zertifikate, weil der Verifizierer 36 nur eine Signatur des kurzfristigen Einmalzertifikats verifizieren muss und das Ablaufdatum/-zeit des kurzfristigen Einmalzertifikats prüfen muss. Da die Zertifikatvalidierungsarbeit des Verifizierers 36 höchstwahrscheinlich ein kritischer Weg bei der Gesamtarbeit des Verifizierers 36 ist, sind kurzfristige Einmalzertifikate eine gute Lösung für den Verifizierer. In vielen Fällen ist der Verifizierer ein Leistungsfähigkeitsengpass und somit sind kurzfristige Einmalzertifikate eine gute Gesamtlösung für die PKI 30.
  • Die Zertifikatautorität 32 umfasst eine Registrierungsautorität 38, die eine Zertifikatdatenbank (DB) 40 beibehält, die nicht-unterzeichnete Zertifikate enthält. Die Zertifikatautorität 32 umfasst auch einen Berechtigungsnachweisserver 42, der eine Hash-Tabelle (HAT) 44 beibehält, die kryptographische Hash-Werte von nicht-unterzeichneten Zertifikaten enthält.
  • Die Registrierungsautorität 38 ist eine Off-Line-Komponente der Zertifikatautorität 32 und ist verantwortlich für Subjektregistrierung und für das Beibehalten einer Zertifikatdatenbank 40. Jedes nicht-unterzeichnete Zertifikat in einer Zertifikatdatenbank 40 bindet einen öffentlichen Schlüssel eines Subjekts an ein oder mehrere Attribute, die das Subjekt eindeutig identifizieren.
  • Der Berechtigungsnachweisserver 42 ist eine On-Line-Komponente der Zertifikatautorität 32 und ist verantwortlich für das Ausgeben der kurzfristigen Einmalzertifikate und für das Beibehalten der Liste von kryptographischen Hash-Werten von aktuell gültigen nicht-unterzeichneten Zertifikaten in der Hash-Tabelle 44. Jeder kryptographische Hash-Wert in der Hash-Tabelle 44 wird von einem nicht-unterzeichneten Zertifikat berechnet, unter Verwendung einer vereinbarten kollisionsresistenten Hash-Funktion, wie z. B. SHA-1 oder MD5. Die Hash-Tabelle 44 ist im wesentlichen eine Liste der aktuell gültigen nicht-unterzeichneten Zertifikate, die durch den kryptographischen Hash-Wert mit einem Schlüssel versehen wird. Kryptographische Hash-Werte funktionieren gut als Schlüssel für die Hash-Tabelle 44, weil sich kryptographische Hash-Werte statistisch als Zufallsgrößen verhalten.
  • Das Subjekt 34 hat einen privaten Schlüssel 46, der in einem sicheren Speichermedium 48 gespeichert ist, wie z. B. einer Smartcard oder einer sicheren Softwaretasche. Das Subjekt 34 hat auch einen öffentlichen Schlüssel, der mathematisch dem privaten Schlüssel 46 zugeordnet, ist. Das Subjekt 34 registriert den öffentlichen Schlüssel, der dem privaten Schlüssel 46 entspricht, bei der Registrierungsautorität 38, durch Senden des öffentlichen Schlüssels und eines oder mehrerer Attribute, die die Identität des Subjekts 34 eindeutig identifizieren, an die Registrierungsautorität 38 und Nachweisen, dass die Identifikations-Attribute für das Subjekt 34 gelten. Beispiele solcher Identifikationsattribute umfassen den Namen, die Sozialversicherungsnummer und die Angestelltennummer.
  • Die Komponenten der PKI 30 sind durch ein oder mehrere Computernetzwerke verbunden. Eine Netzwerkverbindung 50 koppelt den Berechtigungsnachweisserver 42 und das Subjekt 34. Eine Netzwerkverbindung 52 koppelt das Subjekt 34 und den Verifizierer 36. Netzwerkverbindungen 50 und 52 sind in 1 als durchgezogene Linien gezeigt und werden für On-Line-Kommunikation verwendet. Eine Netzwerkverbindung 54 koppelt die Registrierungsautorität 38 und das Subjekt 34. Eine Netzwerkverbindung 56 koppelt die Registrierungsautorität 38 und den Berechtigungsnachweisserver 42. Netzwerkverbindungen 54 und 56 sind in 1 als gestrichelte Linien dargestellt und werden für Off-Line-Kommunikation verwendet. Die Registrierungsautorität 38 ist nur bei Off-Line-Kommunikation beteiligt und kommuniziert durch Off-Line-Netzwerkverbindungen 54 und 56. Andererseits ist der Berechtigungsnachweisserver 42 durch die Netzwerkverbindung 50 bei der On-Line-Kommunikation beteiligt.
  • Ein Ausführungsbeispiel eines nicht-unterzeichneten Zertifikats, das durch die Registrierungsautorität 38 ausgegeben wird, ist in 2 allgemein bei 60 dargestellt. Das nicht-unterzeichnete Zertifikat 60 umfasst ein Metadaten- (MD-) Feld 61, das Daten über nicht- unterzeichnete Zertifikate 60 selbst anstatt Daten enthält, die sich auf das Subjekt beziehen. Beispiele von Daten, die in dem Metadatenfeld 61 gespeichert sind, umfassen Seriennummer und Ausgebername. Das nicht-unterzeichnete Zertifikat 60 umfasst einen öffentlichen Schlüssel (PK) 62 des Subjekts. Das nicht-unterzeichnete Zertifikat 60 umfasst ein Langfristige-Identifikationsinformationen- (LTI-) Feld 63, das Attribute enthält, die das Subjekt 34 eindeutig identifizieren, wie z. B. den Namen des Subjekts, die Sozialversicherungsnummer des Subjekts oder die Angestelltennummer des Subjekts.
  • Das nicht-unterzeichnete Zertifikat 60 umfasst optional ein Langfristiger-Ablauf- (EXP-) Feld 64, das ein Datum/eine Zeit des Ablaufs für das nicht-unterzeichnete Zertifikat 60 enthält. Das Ablaufdatum/-zeit, die in dem Langfristiger-Ablauf-Feld 64 enthalten ist, ist für Verwaltungszwecke sinnvoll, aber ist für eine ordnungsgemäße Funktion der PKI 30 nicht erforderlich. Im Gegensatz dazu ist bei einer herkömmlichen PKI das Ablaufdatum erforderlich, um die Größe der CRL zu reduzieren, wenn aufgehobene Zertifikate ihre Ablaufdaten erreichen. Das nicht-unterzeichnete Zertifikat 60 umfasst optional ein Dauer- (DUR-) Feld 65, das eine Dauer für die Gültigkeitsperiode aller kurzfristigen Einmalzertifikate spezifiziert, die für das nicht-unterzeichnete Zertifikat 60 ausgegeben wurden.
  • Ein Off-Line-Protokoll zum Ausgeben eines nicht-unterzeichneten Zertifikats 60 von der Registrierungsautorität 38 ist in 3 allgemein bei 100 dargestellt. Bei Schritt 102 sendet das Subjekt 34 seinen öffentlichen Schlüssel und ein oder mehrere Attribute, die das Subjekt 34 eindeutig identifizieren, an die Registrierungsautorität 38.
  • Bei Schritt 103 weist das Subjekt 34 Kenntnis des privaten Schlüssels 46 nach, der dem öffentlichen Schlüssel des Subjekts 34 zugeordnet ist. Schritt 103 wird auf eine Weise durchgeführt, die von dem Kryptosystem abhängt, für das das Privater-Öffentlicher-Schlüssel-Paar durch das Subjekt 34 erzeugt wurde. Beispielsweise weist das Subjekt 34 bei einem digitalen Signaturkryptosystem Kenntnis des privaten Schlüssels 46 nach durch Verwenden des privaten Schlüssels 46 zum digitalen Unterzeichnen einer Menge, die von einer Zufallsmenge abgeleitet wird, die durch die Registrierungsautorität 38 erzeugt wird. Die Registrierungsautorität 38 verifiziert dann diese digitale Signatur unter Verwendung des öffentlichen Schlüssels des Subjekts 34.
  • Bei Schritt 104 weist das Subjekt 34 der Registrierungsautorität 38 durch eine Außerbandverwaltungs-Einrichtung nach, dass die Identifikations-Attribute, die in Schritt 102 gesendet werden, für das Subjekt 34 gelten.
  • Bei Schritt 106 erzeugt die Registrierungsautorität 38 ein nicht-unterzeichnetes Zertifikat 60 und speichert das nicht-unterzeichnete Zertifikat 60 in der Zertifikatdatenbank 40. Bei Schritt 108 sendet die Registrierungsautorität 38 das nicht-unterzeichnete Zertifikat 60 an das Subjekt 34.
  • Bei Schritt 110 berechnet die Registrierungsautorität 38 einen kryptographischen Hash-Wert des nicht-unterzeichneten Zertifikats 60 unter Verwendung einer vereinbarten kollisionsresistenten Hash-Funktion, wie z. B. SHA-1 oder MD5. Bei Schritt 110 sendet die Registrierungsautorität 38 den berechneten kryptographischen Hash-Wert des nicht-unterzeichneten Zertifikats 60 an den Berechtigungsnachweisserver 42 über die Netzwerkverbindung 56, die Datenintegritätsschutz liefert, wie z. B. mit einer SSL-Verbindung (SSL = Secure Sockets Layer = Sicherheitssockelschicht).
  • Bei Schritt 112 speichert der Berechtigungsnachweisserver 42 den kryptographischen Hash-Wert des nicht-unterzeichneten Zertifikats 60, das in Schritt 110 berechnet wird, in der Hash-Tabelle 44.
  • Ein Ausführungsbeispiel eines kurzfristigen Einmalzertifikats, wie es durch den Berechtigungsnachweisserver 42 ausgegeben wird, ist in 4 allgemein bei 70 dargestellt. Das kurzfristige Einmalzertifikat 70 umfasst ein Metadaten- (MD-) Feld 71, das Daten über das kurzfristige Einmalzertifikat 70 enthält, anstatt über das Subjekt des kurzfristigen Einmalzertifikats 70. Das kurzfristige Einmalzertifikat 70 umfasst einen öffentlichen Schlüssel (PK) 72, der der gleiche öffentliche Schlüssel ist wie der öffentliche Schlüssel 62 des nicht-unterzeichneten Zertifikats 60. Das Subjekt des nicht-unterzeichneten Zertifikats 60 und des kurzfristigen Einmalzertifikats 70 hat nur ein Privater-Öffentlicher-Schlüssel-Paar, das dem privaten Schlüssel 46 zugeordnet ist, der in der Smartcard oder der sicheren Softwaretasche 48 gespeichert ist. Das kurzfristige Einmalzertifikat 70 umfasst ein Langfristige-Identifikationsinformationen- (LTI-) Feld 73, das Attribute enthält, die das Subjekt 34 eindeutig identifizieren. Das Langfristige-Identifikationsinformationen-Feld 73 ist identisch mit dem Langfristige-Identifikationsinformatione-Feld 63 des nicht-unterzeichneten Zertifikats 60.
  • Das kurzfristige Einmalzertifikat 70 umfasst auch ein Kurzfristiger-Ablauf- (EXP-) Feld 76, das ein Datum und eine Zeit des Ablaufs für ein kurzfristiges Einmalzertifikat 70 spezifiziert. Bei einem Ausführungsbeispiel, bei dem das nicht-unterzeichnete Zertifikat 60 ein Dauerfeld 65 enthält, das eine Dauer für die Gültigkeitsperiode der kurzfristigen Einmalzertifikate spezifiziert, die von demselben ausgegeben werden, werden das Datum und die Zeit, die durch das Kurzfristiger-Ablauf-Feld 56 spezifiziert sind, erhalten durch Hinzufügen der Dauer, die durch das Dauerfeld 65 spezifiziert wird, zu dem Datum und der Zeit, zu dem das kurzfristige Einmalzertifikat 70 durch den Berechtigungsnachweisserver 42 ausgegeben wird. Bei einem Ausführungsbeispiel ist die Dauer der Gültigkeitsperiode des kurzfristigen Einmalzertifikats 70 nicht explizit spezifiziert durch ein Dauerfeld 65 in dem nicht-unterzeichneten Zertifikat 60. Bei diesem Ausführungsbeispiel ist die Dauer der Gültigkeitsperiode des kurzfristigen Einmalzertifikats 70 durch eine Richtlinie festgelegt.
  • Das kurzfristige Einmalzertifikat 70 umfasst auch ein Signaturfeld 77, das eine Signatur eines Berechtigungsnachweisservers 42 enthält. Die Signatur in dem Signaturfeld 77 wird hergestellt durch den Bezugnachweisserver 42 auf der Sequenz der Felder 71, 72, 73 und 76 und auch, falls notwendig, der Spezifikation des Kryptosystems, das verwendet wurde, um die Signatur zu erzeugen, und verwendet werden muss, um die Signatur zu verifizieren.
  • Bei einem Ausführungsbeispiel ist das kurzfristige Einmalzertifikat 70 mit einem X.509v3-Zertifikat implementiert.
  • Ein On-Line-Protokoll zum Ausgeben eines kurzfristigen Einmalzertifikats 70 an das Subjekt 34 von dem Berechtigungsnachweisserver 42 für das nicht-unterzeichnete Zertifikat 60 ist in 5 allgemein bei 200 dargestellt. Bei Schritt 202 sendet das Subjekt 34 eine Mitteilung an den Berechtigungsnachweisserver 42, die das nicht-unterzeichnete Zertifikat 60 enthält und anfordert, dass ein kurzfristiges Einmalzertifikat für das nicht-unterzeichnete Zertifikat 60 ausgegeben wird.
  • Bei Schritt 204 berechnet der Berechtigungsnachweisserver 42 einen kryptographischen Hash-Wert des nicht-unterzeichneten Zertifikats 60 durch die vereinbarte kollisionsresistente Hash-Funktion. Bei Schritt 204 verifiziert der Berechtigungsnachweisserver 42 dann, dass der berechnete kryptographische Hash-Wert in der Hash-Tabelle 44 vorliegt. Bei Schritt 206 erzeugt der Berechtigungsnachweis server 42 das kurzfristige Einmalzertifikat 70 und sendet das kurzfristige Einmalzertifikat 70 an das Subjekt 34.
  • Bei Schritt 204 führt der Berechtigungsnachweisserver 42 den Nachschlag in der Hash-Tabelle 44 mit einer effizienten und rechentechnisch unaufwendigen Operation durch. Die Signaturoperation, die durch den Berechtigungsnachweisserver 42 in Schritt 206 durchgeführt wird, um das kurzfristige Einmalzertifikat 70 zu erzeugen, ist jedoch eine rechentechnisch aufwendige Operation. Trotzdem wird der Schritt 206 mit der rechentechnisch aufwendigen Signatur-Operation nur durchgeführt, falls der Nachschlag in der Hash-Tabelle 44 erfolgreich ist. Die Auswirkung eines Dienstverweigerungsangriffs gegen den Berechtigungsnachweisserver 42 ist reduziert, indem der Schritt 206 nur durchgeführt wird, falls der Nachschlag in Schritt 204 erfolgreich ist.
  • Ein On-Line-Protokoll, das durch das Subjekt 34 verwendet wird, um dem Verifizierer 36 seine Identität nachzuweisen, ist allgemein bei 300 in 6 dargestellt. Bei Schritt 302 sendet das Subjekt 34 das ausgegebene kurzfristige Einmalzertifikat 70 an den Verifizierer 36. Bei Schritt 304 verifiziert der Verifizierer 36, dass das Ablaufdatum und die Ablaufzeit, die in dem kurzfristigen Ablauffeld 76 des kurzfristigen Einmalzertifikats 70 spezifiziert sind, nicht erreicht wurden.
  • Bei Schritt 306 verwendet der Verifizierer 36 einen öffentlichen Schlüssel des Berechtigungsnachweisservers 42 zum Verifizieren der Signatur in dem Signaturfeld 77 des kurzfristigen Einmalzertifikats 70. Der Verifizierer 36 kennt den öffentlichen Schlüssel des Berechtigungsnachweisservers 42 entweder direkt oder durch die Zertifizierung durch eine höhere Zertifikatautorität.
  • Bei Schritt 308 weist das Subjekt 34 die Kenntnis des privaten Schlüssels 46 nach, der dem öffentlichen Schlüssel 72 zugeordnet ist, der in dem kurzfristigen Einmalzertifi kat 70 enthalten ist. Schritt 308 wird auf eine Weise durchgeführt, die von dem Kryptosystem abhängt, für das das private/öffentliche Schlüssel-Paar durch das Subjekt 34 erzeugt wurde. Beispielsweise weist das Subjekt 34 bei einem digitalen Signaturkryptosystem Kenntnis des privaten Schlüssels 46 nach durch Verwenden des privaten Schlüssels 46 zum digitalen Unterzeichnen einer Menge, die von einer Zufallsmenge abgeleitet wird, die durch den Verifizierer 36 erzeugt wird. Der Verifizierer 36 verifiziert dann die digitale Signatur unter Verwendung des öffentlichen Schlüssels 72 in dem kurzfristigen Einmalzertifikat 70.
  • Das Subjekt 34 kann das kurzfristige Einmalzertifikat 70 löschen, wenn das kurzfristige Einmalzertifikat abläuft, weil das Subjekt 34 ein neues kurzfristiges Einmalzertifikat erhalten kann durch Senden des nicht-unterzeichneten Zertifikats an den Berechtigungsnachweisserver 42. Bei einem Ausführungsbeispiel speichert das Subjekt 34 das kurzfristige Einmalzertifikat in dem flüchtigen Speicher und speichert es nicht auf Platte.
  • Ein Off-Line-Protokoll zum Aufheben des nicht-unterzeichneten Zertifikats 60 ist allgemein bei 400 in 7 dargestellt. Das Off-Line-Protokoll 400 wird durchgeführt, wenn der private Schlüssel 46 des Subjekts 34 verfälscht ist oder die Identifikations-Attribute in dem Langfristige-Identifikationsinformationen-Feld 63 nicht mehr für das Subjekt 34 gelten, weil in jedem Fall das Binden des öffentlichen Schlüssels 62 an die Identifikations-Attribute ungültig ist.
  • Bei Schritt 402 gewinnt die Registrierungsautorität 38 das nicht-unterzeichnete Zertifikat 60 von der Zertifikatdatenbank 40 wieder und berechnet einen kryptographischen Hash-Wert des nicht-unterzeichneten Zertifikats 60 unter Verwendung der vereinbarten kollisionsresistenten Hash-Funktion. Bei einem Ausführungsbeispiel markiert die Registrierungsautorität 38 das nicht-unterzeichnete Zertifikat 60 in der Zertifikatdatenbank 40 als ungültig für Prüfungszwecke. Bei einem alternativen Ausführungsbeispiel, wo die Beibehaltung des nicht-unterzeichneten Zertifikats 60 in der Zertifikatdatenbank 40 für Prüfungszwecke nicht erforderlich ist, löscht die Registrierungsautorität 38 das nicht-unterzeichnete Zertifikat 60 von der Zertifikatdatenbank 40.
  • Bei Schritt 404 sendet die Registrierungsautorität 38 eine Mitteilung an den Berechtigungsnachweisserver 42, die den kryptographischen Hash-Wert des nicht-unterzeichneten Zertifikats 60 enthält, der in Schritt 402 berechnet wird. Die Mitteilung, die in Schritt 404 gesendet wird, erfordert auch, dass der Berechtigungsnachweisserver 42 den entsprechenden kryptographischen Hash-Wert des nicht-unterzeichneten Zertifikats 60 von der Hash-Tabelle 44 entfernt.
  • Bei Schritt 406 entfernt der Berechtigungsnachweisserver 42 den kryptographischen Hash-Wert des nicht-unterzeichneten Zertifikats 60 von der Hash-Tabelle 44, was dem kryptographischen Hash-Wert entspricht, der in der Mitteilung von der Registrierungsautorität 38 in Schritt 404 gesendet wurde. Nachdem Schritt 406 abgeschlossen ist, gibt der Berechtigungsnachweisserver 42 keine kurzfristigen Einmalzertifikate 70 für das nicht-unterzeichnete Zertifikat 60 mehr aus. Sobald das Protokoll 40 ausgeführt wurde, kann folglich weder das Subjekt 34 noch ein Angreifer ein kurzfristiges Einmalzertifikat erhalten, indem er das nicht-unterzeichnete Zertifikat 60 dem Berechtigungsnachweisserver 42 präsentiert.
  • Ein alternatives Ausführungsbeispiel einer leichten PKI gemäß der vorliegenden Erfindung ist allgemein bei 30' in 8 dargestellt. Die Komponenten 32', 34', 36', 38', 40' , 42' , 44' , 46' , 48' , 50' , 52' , 54' und 56' der PKI 30' arbeiten im wesentlichen gleich und sind im allgemeinen wesentlich gleich gekoppelt wie die entsprechenden Kompo nenten 32, 34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54 und 56 der PKI 30, die oben beschrieben sind.
  • Die PKI 30' umfasst jedoch ein Verzeichnis 90. Bei einem Ausführungsbeispiel ist das Verzeichnis 90 ein leichtes Verzeichniszugriffsprotokoll- (LDAP-) Verzeichnis. Die PKI 30' umfasst auch eine Netzwerkverbindung 92 zum Koppeln des Berechtigungsnachweisservers 42' mit dem Verzeichnis 90, um es dem Berechtigungsnachweisserver 42' zu ermöglichen, auf das Verzeichnis 90 zuzugreifen. Der Berechtigungsnachweisserver 42' erhält kurzfristige Autorisierungs-Informationen, die in dem Verzeichnis 90 gespeichert sind. Der Berechtigungsnachweisserver 42' fügt die kurzfristigen Autorisierungs-Informationen, die von dem Verzeichnis 90 erhalten werden, den kurzfristigen Einmalzertifikaten hinzu, die durch den Berechtigungsnachweisserver 42' ausgegeben werden, auf eine ähnliche Weise, wie es in der mitanhängigen Anmeldung mit dem Titel „AUTHORIZATION INFRASTRUCTURE BASED ON PUBLIC KEY CRYPTOGRAPHY" beschrieben ist, um kurzfristige Berechtigungsnachweiszertifikate zu erzeugen, die für die Autorisierung des Subjekts 34' verwendet werden können.
  • Die kurzfristigen Autorisierungsinformationsdaten, die in dem Verzeichnis 90 enthalten sind, beziehen sich auf Attribute oder Autorisierungs-Informationen über das Subjekt 34'. Beispielhafte kurzfristige Autorisierungs-Informationen umfassen die Kostenautorisierungsgrenze für eine Firmenanwendung, die Mitfinanzierungsmenge für eine Versicherungsanwendung, die Plattenspeicherquote für eine Informationstechnologie- (IT-) Anwendung, und Benutzer-ID plus Gruppen-ID für Unix-Zugriffsanwendungen.
  • Bei der PKI 30' ist der Verifizierer 36' ein Anwendungsprogramm, das auf einem Servercomputersystem läuft und das Subjekt 34' ist ein Clientprogramm, das die Anwendung verwendet.
  • Nicht-unterzeichnete Zertifikate, die durch die Registrierungsautorität 38' ausgegeben werden, sind im wesentlichen ähnlich wie die nicht-unterzeichneten Zertifikate, die durch die Registrierungsautorität 38 ausgegeben werden, wie z. B. das nicht-unterzeichnete Zertifikat 60 von 2.
  • Die PKI 30' verwendet das Off-Line-Protokoll 100, das in 3 dargestellt ist, zum Ausgeben des nicht-unterzeichneten Zertifikats 60 von der Registrierungsautorität 38. Außerdem verwendet die PKI 30' das in 7 dargestellte Off-Line-Protokoll 400 für die Registrierungsautorität 38' zum Aufheben des nicht-unterzeichneten Zertifikats 60.
  • Ein Ausführungsbeispiel eines strukturierten kurzfristigen Einmalzertifikats, das durch den Berechtigungsnachweisserver 42 ausgegeben wird, ist in 9 allgemein bei 80 dargestellt. Das kurzfristige Einmalzertifikat 80 ist ein strukturiertes Zertifikat, wie die strukturierten Zertifikate, die in der mitanhängigen Anmeldung mit dem Titel „METHOD AND APPARATUS FOR PROVIDING FIELD CONFIDENTIALITY IN DIGITAL CERTIFICATES" definiert und beschrieben sind.
  • Das strukturierte kurzfristige Einmalzertifikat 80 umfasst ein Metadaten- (MD-) Feld 81, einen öffentlichen Schlüssel (PK) 82, ein Kurzfristiger-Ablauf-Feld 86 und ein Signaturfeld 87, die im wesentlichen ähnlich sind wie das Metadatenfeld 71, der öffentliche Schlüssel 72, das Kurzfristiger-Ablauf-Feld 76 und das Signaturfeld 77 des nicht strukturierten kurzfristigen Einmalzertifikats 70 von 4. Das strukturierte kurzfristige Einmalzertifikat 80 umfasst jedoch Ordner 88a–88n, die jeweils den Anwendungen 36'a–36'n entsprechen. Für jeden Verifizierer/Anwendung 36', auf die das Subjekt/der Client 34' zugreifen kann, wie es beispielsweise durch ein Benutzerprofil spezifiziert ist, gibt es einen kryptographischen Ordner 88. Jeder kryptographische Ordner 88 enthält langfristige Identifikationsinformationen 83 und/oder kurzfristige Autorisierungsin formationen 89, wie sie für den entsprechenden Verifizierer/die entsprechende Anwendung 36' zum Durchführen von Autorisierungs-Entscheidungen über das Subjekt/den Client 34' erforderlich sind. Bei einem Ausführungsbeispiel ist das strukturierte kurzfristige Einmalzertifikat 80 durch Hinzufügen einer Ordnererweiterung zu einem X.509v3-Zertifikat implementiert.
  • Ein On-Line-Protokoll zum Ausgeben eines strukturierten kurzfristigen Einmalzertifikats 80 an das Subjekt/den Client 34' von dem Berechtigungsnachweisserver 42' für das nicht-unterzeichnete Zertifikat 60 ist in 10 allgemein bei 500 dargestellt. Bei Schritt 502 sendet das Subjekt/der Client 34' eine Mitteilung an den Berechtigungsnachweisserver 42, die das nicht-unterzeichnete Zertifikat 60 enthält und fordert an, dass ein kurzfristiges Einmalzertifikat für das nicht-unterzeichnete Zertifikat 60 ausgegeben wird.
  • Bei Schritt 504 berechnet der Berechtigungsnachweisserver 42' einen kryptographischen Hash-Wert des nicht-unterzeichneten Zertifikats 60 mit einer vereinbarten kollisionsresistenten Hash-Funktion. Bei Schritt 504 verifiziert der Berechtigungsnachweisserver 42' dann, dass der berechnete kryptographische Hash-Wert in der Hash-Tabelle 44 vorliegt.
  • Bei Schritt 506 greift der Berechtigungsnachweisserver 42 über die Netzwerkverbindung 92 auf das Verzeichnis 90 zu und erhält kurzfristige Autorisierungs-Informationen für das strukturierte kurzfristige Einmalzertifikat 80.
  • Bei Schritt 508 kombiniert der Berechtigungsnachweisserver 42' die kurzfristigen Autorisierungs-Informationen, die von dem Verzeichnis 90 bei Schritt 506 erhalten werden, mit den Identifikationsattributen in dem Langfristige-Identifikationsinformationen-Feld 63 des nicht-unterzeichneten Zertifikats 60. Bei Schritt 508 erzeugt der Berechtigungsnachweisserver 42' einen kryptographischen Ordner 88 für jeden Verifizierer/jede Anwendung 36', auf die durch das Subjekt/den Client 34' zugegriffen werden kann, wobei jeder kryptographische Ordner 88 alle langfristigen Identifikationsinformationen und/oder kurzfristigen Autorisierungs-Informationen enthält, die durch den Verifizierer/die Anwendung 36' erforderlich sind, um Autorisierungsentscheidungen über das Subjekt/den Client 34' zu treffen. Bei Schritt 508 verwendet der Berechtigungsnachweisserver 42' kryptographische Ordner 88 zum Erzeugen des strukturierten kurzfristigen Einmalzertifikats 80.
  • Bei Schritt 510 sendet der Berechtigungsnachweisserver 42' das strukturierte kurzfristige Einmalzertifikat 80 an das Subjekt/den Client 34', wobei alle Ordner des kurzfristigen Einmalzertifikats offen sind.
  • Ein On-Line-Protokoll zum Autorisieren des Subjekts/Client 34' ist in 11 allgemein bei 600 dargestellt. Das On-Line-Protokoll 600 wird durch das Subjekt/den Client 34' verwendet, um dem Verifizierer/der Anwendung 36' seine Identität nachzuweisen. Das On-Line-Protokoll 600 wird auch durch den Verifizierer/die Anwendung 36' verwendet, um Autorisierungsentscheidungen bezüglich des Subjekts/Client 34' zu treffen, wie z. B. Erlauben/Verweigern von Zugriff oder Autorisieren von spezifischen Transaktionen.
  • Bei Schritt 602 schließt das Subjekt/der Client 34' alle Ordner 88 in dem strukturierten kurzfristigen Einmalzertifikat 80, außer dem Ordner, der die notwendigen Identifikations-/Autorisierungs-Informationen 83/89 enthält, die durch den Verifizierer/die Anwendung 36' erforderlich sind, um Autorisierungsentscheidungen bezüglich des Subjekts/des Client 34' zu treffen. Bei Schritt 604 sendet das Subjekt/der Client 34' das strukturierte kurzfristige Einmalzertifikat 80 an den Verifizierer/die Anwendung 36'.
  • Bei Schritt 606 verifiziert der Verifizierer/die Anwendung 36', dass das Ablaufdatum/-zeit, die in dem Ablauffeld 86 des strukturierten kurzfristigen Einmalzertifikats 80 spezifiziert ist, nicht abgelaufen ist.
  • Bei Schritt 608 verwendet der Verifizierer/die Anwendung 36' einen öffentlichen Schlüssel des Berechtigungsnachweisservers 42' zum Verifizieren der Signatur in dem Signaturfeld 87 des strukturierten kurzfristigen Einmalzertifikats 80. Der Verifizierer/die Anwendung 36' kennt den öffentlichen Schlüssel des Berechtigungsnachweisservers 42 entweder direkt oder durch Zertifizierung durch eine höhere Zertifikatautorität.
  • Bei Schritt 610 weist das Subjekt/der Client 34' Kenntnis des privaten Schlüssels 46' nach, der dem öffentlichen Schlüssel 82 des strukturierten kurzfristigen Einmalzertifikats 80 zugeordnet ist. Schritt 610 wird auf eine Weise durchgeführt, die von dem Kryptosystem abhängt, für das das Privater/Öffentlicher-Schlüssel-Paar durch das Subjekt/den Client 34' erzeugt wurde. Beispielsweise weist das Subjekt/der Client 34' in einem digitalen Signaturkryptosystem Kenntnis des privaten Schlüssels 46' nach, durch Verwenden des privaten Schlüssels 46' zum digitalen Unterzeichnen einer Menge, die von einer Zufallsmenge abgeleitet wird, die durch den Verifizierer/die Anwendung 36' erzeugt wird. Der Verifizierer/die Anwendung 36' verifiziert dann diese digitale Signatur unter Verwendung des öffentlichen Schlüssels 82 des strukturierten kurzfristigen Einmalzertifikats 80'.
  • Bei Schritt 612 extrahiert der Verifizierer/die Anwendung 36' die Identifikations-/Autorisierungs-Informationen 83/89, die in dem offenen Ordner 88 des strukturierten kurzfristigen Einmalzertifikats 80 enthalten sind. Bei Schritt 612 verwendet der Verifizierer/die Anwendung 36' dann die Identifizierungs-/Autorisierungs-Informationen 83/89 zum Treffen von Autorisierungsentscheidungen bezüglich des Subjekts/Clients 34'.
  • Das On-Line-Protokoll 600 zum Autorisieren des Subjekts/Client 34' verwendet das strukturierte kurzfristige Einmalzertifikat 80 mit einem Ordner für jede Anwendung, auf die durch das Subjekt/den Client 34' zugegriffen werden kann, wie es durch ein Benutzerprofil bestimmt ist. Dies stellt sicher, dass jede Anwendung nur Zugriff zu Autorisierungs-Informationen hat, die dieselbe erfordert. Trotzdem kann die Autorisierung, die durch die PKI 30' durchgeführt wird, mit nicht strukturierten kurzfristigen Einmalzertifikaten implementiert werden, wo statt einem strukturierten kurzfristigen Einmalzertifikat 80 mehrere nicht strukturierte kurzfristige Einmalzertifikate verwendet werden.
  • Die PKI 30/30' gemäß der vorliegenden Erfindung ist stark vereinfacht und wesentlich effizienter als herkömmliche PKIs. Beispielsweise müssen Anwendungen das kurzfristige Einmalzertifikat nur für Authentifizierung und/oder Autorisierung verwenden. Das nicht-unterzeichnete Zertifikat 60, das das traditionelle langfristige Zertifikat ersetzt, kann für die Verwendung durch das Subjekt reserviert werden, wenn ein kurzfristiges Einmalzertifikat angefordert wird. Da das nicht-unterzeichnete Zertifikat 60 nicht durch Anwendungen verwendet wird, muss es nicht-unterzeichnet werden. Anstatt dem Unterzeichnen des nicht-unterzeichneten Zertifikats 60 hält der Berechtigungsnachweisserver die kryptographische Hash-Tabelle 44, die kryptographische Hash-Werte der nicht-unterzeichneten Zertifikate enthält, die aktuell gültig sind. Auf diese Weise wird die Zertifikatsaufhebung einfach durch Entfernen des kryptographischen Hash-Werts des nicht-unterzeichneten Zertifikats von der Hash-Tabelle 44 durchgeführt. Daher ist anders als bei herkömmlichen PKIs keine Signatur erforderlich, kein Ablaufdatum erforderlich und es besteht kein Bedarf an CRLs für das nicht-unterzeichnete Zertifikat 60 der PKI 30/30'.
  • Die PKI 30/30' erfordert eine Zertifikatstatusprüfung, ähnlich wie die On-Line-Zertifikatstatusprüfung, die durch das OCSP erforderlich ist. Die Zertifikatstatusprüfung der PKI 30/30' gemäß der vorliegenden Erfindung tritt jedoch auf, wenn das Subjekt das kurzfristige Einmalzertifikat anfordert, und nicht wenn das Subjekt auf die Anwendung zugreift, wie es z. B. durch das OCSP erforderlich ist.
  • Eine verteilte Zertifikatautorität 132 für die Verwendung bei der PKI 30/30' gemäß der vorliegenden Erfindung ist in 12 dargestellt. Die verteilte Zertifikatautorität 132 umfasst eine Registrierungsautorität 138 mit einer Zertifikatdatenbank 140, die mit einem verteilten Berechtigungsnachweisserver 142 kommuniziert.
  • Der verteilte Berechtigungsnachweisserver 142 umfasst Berechtigungsnachweisserver 142a–142n. Jeder Berechtigungsnachweisserver 142 umfasst eine entsprechende Hash-Tabellen-Unterteilung 144. Bei einem Ausführungsbeispiel ist die kryptographische Hash-Tabelle 144 in Hash-Tabellen-Unterteilungen 144a–144n unterteilt, gemäß einem Wert von einigen der Bits des kryptographischen Hash-Werts. Bei einer PKI 30/30', die eine verteilte Zertifikatautorität 132 verwendet, die verteilte Berechtigungsnachweisserver 142a–142n aufweist, sendet das Subjekt eine Anforderung für ein kurzfristiges Einmalzertifikat direkt an die korrekte Hash-Tabellen-Unterteilung 144.
  • Die Zertifikatautorität 132 wird ferner optimiert durch direktes Koppeln jedes Berechtigungsnachweisservers 142 mit seiner eigenen Kopie des Verzeichnisses 190.
  • Die PKI 30/30' gemäß der vorliegenden Erfindung ist hoch skalierbar, weil viele Engpässe der herkömmlichen PKIs entfernt sind. Die nicht-unterzeichneten Zertifikate 60, die durch die PKI 30/30' verwendet werden, laufen nicht ab und müssen nicht regelmäßig erneuert werden. Außerdem werden CRLs nicht verwendet. Mit der PKI 30/30' wurden keine wesentlichen Engpässe eingeführt.
  • Ein potentieller Engpass der PKI 30/30' ist, dass der Berechtigungsnachweisserver 42/42'/142 kurzfristige Einmalzertifikate sehr häufig ausgibt, wie z. B. einmal am Tag, alle paar Stunden oder sogar alle paar Minuten. Diese Frequenz des Ausgebens kurzfristiger Einmalzertifikate von dem Berechtigungsnachweisserver gemäß der vorliegenden Erfindung ist jedoch kein wesentlicher Engpass, -weil die Hash-Tabelle unterteilt werden kann, wie z. B. in Hash-Tabellen-Abschnitte 144a–144n der verteilten Zertifikatautorität 132, die in 12 dargestellt ist, und der Berechtigungsnachweisserver kann wie erforderlich reproduziert werden, wie z. B. die Berechtigungsnachweisserver 142a–142n der verteilten Zertifikatautorität 132.
  • Ein weiterer potentieller Engpass mit der PKI 30/30' ist die Zertifikatdatenbank 40/40' der Registrierungsautorität 38/38'. Die Zertifikatdatenbank 40/40' ist jedoch kein wesentlicher Engpass, weil auf die Zertifikatdatenbank nur zugegriffen wird, wenn nicht-unterzeichnete Zertifikate 60 ausgegeben oder aufgehoben werden. Die Zertifikatdatenbank 40/40' kann unter Verwendung eines Relationale-Datenbank-Verwaltungssystems (DBMS) implementiert werden, das Millionen nicht-unterzeichneter Zertifikate handhaben kann.
  • Ein weiterer potentieller Engpass mit dem PKI 30/30' ist das Verzeichnis 90. Das Verzeichnis 90 ist kein wesentlicher Engpass, weil das Verzeichnis 90 reproduziert werden kann, um es möglich zu machen, Millionen von Benutzer zu handhaben. Außerdem ist der LDAP-Verkehr zu dem Verzeichnis 90 wesentlich reduziert, da Anwendungen nicht auf das Verzeichnis 90 zugreifen, um Autorisierungsentscheidungen zu treffen, da bei dem Ausführungsbeispiel, wo die PKI 30' verwendet wird, um das Subjekt zu autorisieren, alle notwendigen Autorisierungs-Informationen in dem kurzfristigen Einmalzertifikat 80 enthalten sind. Daher kann die PKI gemäß der vorliegenden Erfindung Millionen von Benutzern skalieren.
  • Öffentlicher-Schlüssel-Validierungsdienst
  • Die vorliegende Erfindung bezieht sich auf einen Benutzer eines Öffentlicher-Schlüssel-Kryptosystems, der als Subjekt bezeichnet wird (z. B. eine Person oder ein Computersystem), der ein Öffentlicher-Privater-Schlüssel-Paar hat, und der das Schlüssel-Paar verwendet, um seine Identität einem anderen Benutzer des gleichen Kryptosystems nachzuweisen, der als Verifizierer bezeichnet wird. Das Subjekt verwendet einen Öffentlicher-Schlüssel-Validierungsdienst (PKVS), um den öffentlichen Schlüssel des Subjekts zu validieren, bevor das Schlüssel-Paar für Authentifizierungszwecke verwendet wird, auf eine solche Weise, dass der öffentliche Schlüssel nicht mehr für Authentifizierungszwecke verwendbar ist, falls das Subjekt den PKVS benachrichtigt, dass der private Schlüssel beeinträchtigt wurde.
  • Der PKVS hat einen oder mehrere Öffentlicher-Schlüssel-Validierungsagenten (PKVAs). Jeder PKVA hat ein Privater/Öffentlicher-Schlüssel-Paar für ein digitales Signatur-Kryptosystem. Der PKVA verwendet seinen privaten Schlüssel, um Öffentlicher-Schlüssel-Validierungszertifikate (PKVCs) zu unterzeichnen, wie es nachfolgend beschrieben ist. Der Grund, weshalb ein PKVS mehr als einen PKVA haben kann, ist das Erhöhen der Rate, mit der der PKVS PKVCs ausgeben kann. Unterschiedliche PKVAs des gleichen PKVS sind funktional unabhängig. Insbesondere haben dieselben unterschiedliche Signatur-Schlüsselpaare.
  • Das Subjekt registriert den öffentlichen Schlüssel des Subjekts bei einem PKVA. Der PKVA wirkt als eine Zertifikatautorität, die Einmalzertifikate ausstellt, ähnlich wie die oben beschriebene leichte PKI 30/30', die Einmalzertifikate verwendet, außer dass der PKVA nicht an der Identität des Subjekts interessiert ist. Anstatt den öffentlichen Schlüssel des Subjekts an die Subjektidentität zu binden, bindet der PKVA den öffentlichen Schlüssel des Subjekts an eine Seriennummer, die durch den PKVA erzeugt wird und anders ist als alle vorhergehenden solchen Nummern, die durch den gleichen PKVA erzeugt werden. Diese Seriennummer wird hierin als eine Öffentlicher-Schlüssel-Validierungsnummer (PKVN) bezeichnet.
  • Der PKVA gibt ein nicht-unterzeichnetes Zertifikat aus, das den öffentlichen Schlüssel an die PKVN bindet und sendet dasselbe an das Subjekt. Dieses Zertifikat wird hierin als ein nicht-unterzeichnetes Öffentlicher-Schlüssel-Validierungszertifikat (nicht-unterzeichnetes PKVC) bezeichnet. Der PKVA sendet dem Subjekt auch einen Öffentlicher-Schlüssel-Aufhebungscode (PKRC). Der PKRC sollte über einen sicheren Kanal gesendet werden, der Datenvertraulichkeit liefert, wie z. B. eine SSL-Verbindung, und sollte durch das Subjekt geheimgehalten werden. Der PKVA gibt später Einmalzertifikate an das Subjekt aus, für das nicht-unterzeichnete PKVC. Ein Einmalzertifikat, das für die PKVC ausgegeben ist, wird hierin als einmaliges Öffentlicher-Schlüssel-Validierungszertifikat (Einmal-PKVC) bezeichnet. Falls der private Schlüssel des Subjekts beeinträchtigt ist, fragt das Subjekt den PKVA, das Ausgeben von Einmal-PKVCs zu stoppen, unter Verwendung des PKRC, um die Anforderung zu authentifizieren.
  • Das Subjekt kann sein Privater/Öffentlicher-Schlüssel-Paar für mehrere Authentifizierungszwecke verwenden, und kann für jeden Zweck ein anderes Authentifizierungsverfahren verwenden. Vier unterschiedliche beispielhafte Authentifizierungsverfahren sind nachfolgend beschrieben und umfassen: 1) Authentifizierung unter Verwendung herkömmlicher Öffentlicher-Schlüssel-Zertifikate; 2) Authentifizierung unter Verwendung von Einmalzertifikaten, wie sie oben und in der mitanhängigen Patentanmeldung mit dem Titel „LIGHTWEIGHT PUBLIC KEY INFRASTRUCTURE EMPLOYING DISPOSABLE CERTIFICATES" beschrieben sind 3) Authentifizierung unter Verwendung nicht-unterzeichneter Zertifikate, die den Verifizierern direkt präsentiert werden, wie es in der mitanhängigen Patentanmeldung mit dem Titel „LIGHTWEIGHT PUBLIC KEY INFRASTRUCTURE EMPLOYING UNSIGNED CERTIFICATES" beschrieben ist; und 4) Authentifizierung ohne Zertifikate.
  • Die Authentifizierung, die das Verfahren der nicht-unterzeichneten Zertifikate verwendet, ist geeignet, wenn es nur wenige Verifizierer gibt (z. B. bis zu einige hundert Verifizierer). Das Verfahren der Authentifizierung ohne Zertifikate umfasst nur einen Verifizierer. Jedes dieser vier Verfahren kann modifiziert werden, um ein PKVA gemäß der vorliegenden Erfindung zu nutzen.
  • Die Authentifizierungsverfahren, die herkömmliche Öffentlicher-Schlüssel-Zertifikate, Einmalzertifikate oder nicht-unterzeichnete Zertifikate verwenden, umfassen Zertifikate, die durch eine Zertifikatautorität ausgegeben werden. Zwei Zertifikatautoritäten werden verwendet, wenn eines dieser Authentifizierungsverfahren in Verbindung mit einem PKVA verwendet wird. Die beiden Zertifikatautoritäten geben Zertifikate für den gleichen öffentlichen Schlüssel aus. Die erste Zertifikatautorität ist der PKVA, der Zertifikate ausgibt, die den öffentlichen Schlüssel an eine PKVN binden. Die zweite Zertifikatautorität gibt Zertifikate aus, die den öffentlichen Schlüssel an die Identität des Subjekts binden. Die zweite Zertifikatautorität wird hierin als die reguläre Zertifikatautorität bezeichnet. Wenn es Verwirrung gibt, werden Zertifikate jeder Art, die durch die reguläre Zertifikatautorität ausgestellt werden, hierin als reguläre Zertifikate bezeichnet.
  • Bei einer herkömmlichen PKI muss ein Zertifikat eventuell aufgehoben werden, weil die Attribute, die in dem Zertifikat enthalten sind, nicht mehr für das Subjekt gelten oder weil der private Schlüssel beeinträchtigt wurde. In jedem Fall muss die gleiche Zertifikatautorität benachrichtigt werden und gefragt werden, das Zertifikat aufzuheben. Wenn ein PKVA verwendet wird, wird der PKVA durch das Subjekt benachrichtigt, wenn der private Schlüssel des Subjekts beeinträchtigt ist, während die reguläre Zertifikatautorität durch einen Administrator benachrichtigt wird, wenn die Attribute nicht mehr für das Subjekt gelten.
  • Authentifizierung mit herkömmlichen Öffentlicher-Schlüssel-Zertifikaten
  • Bei der Authentifizierung mit herkömmlichen Öffentlicher-Schlüssel-Zertifikaten registriert ein Subjekt seinen öffentlichen Schlüssel und Identitätsattribute bei einer herkömmlichen Zertifikatautorität. Die Zertifikatautorität verifiziert, dass die Attribute für das Subjekt gelten und unterzeichnet dann ein Zertifikat, das den öffentlichen Schlüssel an die Attribute bindet. Das Subjekt beweist seine Identität einem Verifizierer durch Vorlegen des Zertifikats und Nachweisen der Kenntnis des privaten Schlüssels, der dem öffentlichen Schlüssel zugeordnet ist, der in dem Zertifikat enthalten ist.
  • Um einen PKVA vorteilhaft zu nutzen, wird das obige Authentifizierungsverfahren, das herkömmliche Öffentlicher-Schlüssel-Zertifikate nutzt, wie folgt modifiziert. Wenn es sich bei der regulären Zertifikatautorität registriert, legt das Subjekt das nicht-unterzeichnete PKVC und den öffentlichen Schlüssel des PKVA vor, anstatt einfach nur seinen öffentlichen Schlüssel vorzulegen. Das Subjekt legt auch wie vorher die Identitätsattribute vor. Die reguläre Zertifikatautorität berechnet einen Öffentlicher-Schlüssel-Validierungs-Hash-Wert (PKVH) durch Anlegen einer kollisionsresistenten kryptographischen Hash-Funktion, wie z. B. MD5 oder SHA-1, an den öffentlichen Schlüssel des Subjekts und die PKVN, die in dem nicht-unterzeichneten PKVC enthalten ist, verkettet mit dem öffentlichen Schlüssel des PKVA.
  • Die reguläre Zertifikatautorität gibt ein herkömmliches Zertifikat an das Subjekt aus, das den PKVH als ein kritisches Feld enthält, zusätzlich zu dem öffentlichen Schlüs sel und Attributen des Subjekts. Später legt das Subjekt das herkömmliche Zertifikat dem Verifizierer vor und weist Kenntnis des privaten Schlüssels nach, der dem öffentlichen Schlüssel zugeordnet ist, der in dem Zertifikat enthalten ist. Das Subjekt legt auch ein Einmal-PKVC, das von dem PKVA erhalten wird, und den öffentlichen Schlüssel des PKVA dem Verifizierer vor.
  • Der Verifizierer verifiziert das herkömmliche Zertifikat, das durch die reguläre Zertifikatautorität ausgegeben wird, auf die übliche Weise. Der Verifizierer verifiziert, dass das Einmal-PKVC nicht abgelaufen ist und verifiziert die Signatur des PKVA auf dem Einmal-PKVC unter Verwendung des öffentlichen Schlüssels des PKVA. Der Verifizierer berechnet den PKVH von dem öffentlichen Schlüssel des Subjekts, der PKVN, die in dem Einmal-PKVC enthalten ist, und dem öffentlichen Schlüssel des PKVA und prüft, dass derselbe mit dem PKVH zusammenfällt, der in dem herkömmlichen Zertifikat enthalten ist.
  • Falls der private Schlüssel beeinträchtigt ist, benachrichtigt das Subjekt den PKVA, der das nicht-unterzeichnete PKVC aufhebt. Nachdem der PKVA das nicht-unterzeichnete PKVC aufhebt, gibt der PKVA keine Einmal-PKVCs mehr aus, die den öffentlichen Schlüssel des Subjekts an die gleiche PKVN binden. Daher wird ein Angreifer mit Kenntnis des öffentlichen Schlüssels des Subjekts nicht in der Lage sein, sich unter Verwendung des herkömmlichen Zertifikats als das Subjekt auszugeben, das durch die Zertifikatautorität ausgegeben wird. Der Angreifer kann den öffentlichen Schlüssel des Subjekts bei dem gleichen PKVA oder bei einem anderen PKVA registrieren und ein Einmal-PKVC für den öffentlichen Schlüssel erhalten. Der Angreifer kann dann das herkömmliche Zertifikat, das Einmal-PKVC und den öffentlichen Schlüssel des PKVA vorlegen, die der Angreifer verwendet hat. Der PKVH, der durch den Verifizierer berechnet wird, wird jedoch nicht mit dem PKVH übereinstimmen, der durch die reguläre Zertifikatautorität berechnet wird und in dem herkömmlichen Zertifikat enthalten ist. Falls der Angreifer einen anderen PKVA verwendet hat, ist in der Tat der öffentliche Schlüssel des PKVA, der in der Hash-Berechnung verwendet wird, unterschiedlich. Falls der Angreifer den gleichen PKVA verwendet hat, hat der PKVA eine andere PKVN erzeugt, und somit ist die PKVN, die in der Hash-Berechnung verwendete wird, anders. Da die Hash-Berechnung eine kollisionsresistente Hash-Funktion verwendet, falls sich entweder der öffentliche Schlüssel des PKVA oder die PKVN ändert, ist es sehr wahrscheinlich, dass das Ergebnis der Hash-Rechnung anders ist.
  • Eine PKI gemäß der vorliegenden Erfindung, die die Verwendung von PKVS mit der Verwendung herkömmlicher Zertifikate kombiniert, ist allgemein bei 700 in 13 dargestellt. Die PKI 700 umfasst mehrere Hauptkomponenten, die jeweils ein Softwareprogramm sind. Die Hauptsoftwareprogrammkomponenten der PKI 700 laufen auf einem oder mehreren Computersystemen. Bei einem Ausführungsbeispiel läuft jede der Hauptsoftwareprogrammkomponenten auf ihrem eigenen Computersystem.
  • Der PKVS der PKI 700 umfasst eine oder mehrere PKVAs 701 mit der Funktionalität einer Zertifikatautorität, die Einmalzertifikate ausgeben kann, ähnlich wie die Zertifikatautorität 32/32' der oben beschriebenen leichten PKI 30/30', die Einmalzertifikate verwendet. Als solcher umfasst der PKVA 701 eine Registrierungsautorität (RA) 702, die eine Zertifikatdatenbank beibehält, die nicht-unterzeichnete Zertifikate enthält. Der PKVA 701 umfasst auch einen Berechtigungsnachweisserver (CS) 703, der eine Hash-Tabelle (HAT) 704 beibehält, die kryptographische Hash-Werte von nicht-unterzeichneten Zertifikaten enthält.
  • Die Registrierungsautorität 702 ist eine Off-Line-Komponente des PKVA 701 und ist verantwortlich für Subjektregistrierung, Beibehalten der Zertifikatdatenbank und Ausgeben von nicht-unterzeichneten Zertifikaten.
  • Der Berechtigungsnachweisserver 703 ist eine On-Line-Komponente des PKVA 701 und ist verantwortlich für das Ausgeben der Einmalzertifikate und für das Beibehalten der Liste von kryptographischen Hash-Werten von derzeit gültigen nicht-unterzeichneten Zertifikaten in der Hash-Tabelle 704. Jeder kryptographische Hash-Wert in der Hash-Tabelle 704 wird unter Verwendung einer vereinbarten kollisionsresistenten Hash-Funktion, wie z. B. SHA-1 oder MD5, von einem nicht-unterzeichneten Zertifikat berechnet. Die Hash-Tabelle 704 ist im Wesentlichen eine Liste der aktuell gültigen nicht-unterzeichneten Zertifikate, die durch den kryptographischen Hash-Wert verschlüsselt wird. Kryptographische-Hash-Werte funktionieren gut als Schlüssel für die Hash-Tabelle 704, weil sich kryptographische Hash-Werte statistisch als Zufallsgrößen verhalten.
  • Der PKVA 701 hat ein Privater/Öffentlicher-Schlüssel-Paar für ein Digitale-Signatur-Kryptosystem.
  • Die PKI 700 umfasst auch eine herkömmliche Zertifikatautorität (CA) 705 mit der Fähigkeit, aufhebbare Öffentlicher-Schlüssel-Zertifikate und Zertifikataufhebungslisten und auch ein oder mehrere Subjekte 706 und einen oder mehrere Verifizierer 707 auszugeben. Jedes Subjekt 706 ist mit einem Privater/Öffentlicher-Schlüssel-Paar ausgestattet, für ein Kryptosystem jeder Art. Die Zertifikatautorität 705 ist mit einem Privater/Öffentlicher-Schlüssel-Paar für ein Digital-Signatur-Kryptosystem ausgestattet. Der öffentliche Schlüssel der Zertifikatautorität 705 ist den Verifizierern gut bekannt oder durch eine höhere Autorität zertifiziert.
  • Das Subjekt 706 verwendet das folgende Protokoll P1, um seinen öffentlichen Schlüssel bei dem PKVA 701 zu registrieren.
  • Protokoll P1
    • 1. Das Subjekt 706 sendet seinen öffentlichen Schlüssel an die Registrierungsautorität 702.
    • 2. Die Registrierungsautorität 702 erzeugt eine Öffentlicher-Schlüssel-Validierungsnummer (PKVN), die sich von allen PKVNs unterscheidet, die vorher durch den PKVA 701 erzeugt wurden.
    • 3. Registrierungsautorität 702 erzeugt ein nicht-unterzeichnetes Öffentlicher-Schlüssel-Validierungszertifikat (nicht-unterzeichnetes PKVC) 800. Das nicht-unterzeichnete PKVC 800 ist in 14 dargestellt und umfasst ein Feld 801, das den öffentlichen Schlüssel des Subjekts 706 enthält, und ein Feld 802, das die PKVN enthält, die in Schritt 2 des Protokolls 1 erzeugt wurde. Die Registrierungsautorität 702 sendet das nicht-unterzeichnete PKVC 800 an das Subjekt 706.
    • 4. Die Registrierungsautorität 702 erzeugt eine geheime Größe, die durch das Subjekt 706 als ein Öffentlicher-Schlüssel-Aufhebungscode (PKRC) zu verwenden ist und sendet dieselbe an das Subjekt 706 über einen sicheren Kanal, der Datenvertraulichkeit liefert.
    • 5. Die Registrierungsautorität 702 berechnet einen kryptographischen Hash-Wert des nicht-unterzeichneten Zertifikats 800 unter Verwendung einer kollisionsresistenten Hash-Funktion, wie z. B. MD5 oder SHA-1.
    • 6. Die Registrierungsautorität 702 sendet den kryptographischen Hash-Wert, der bei Schritt 5 des Protokolls P1 erzeugt wurde, und den PKRC, der bei Schritt 4 des Protokolls P1 erzeugt wurde, an den Berechtigungsnachweisserver 703.
    • 7. Der Berechtigungsnachweisserver 703 erzeugt eine Aufzeichnung in seiner Hash-Tabelle 704, die den kryptographischen Hash-Wert und den PKRC enthält, der durch die Registrierungsautorität 702 bei Schritt 6 des Protokolls P1 gesendet wurde. Die Aufzeichnung wird durch den kryptographischen Hash-Wert verschlüsselt.
  • Das Subjekt 706 verwendet das folgende Protokoll P2, um ein einmaliges Öffentlicher-Schlüssel-Validierungszertifikat (Einmal-PKVC) zu erhalten.
  • Protokoll P2
    • 1. Das Subjekt 706 sendet eine Mitteilung an den Berechtigungsnachweisserver 703, die die nicht-unterzeichnete PKVC 800 enthält, und anfordert, dass ein Einmal-PKVC gegen das nicht-unterzeichnete PKVC 800 ausgegeben wird.
    • 2. Der Berechtigungsnachweisserver 703 berechnet den kryptographischen Hash-Wert des nicht-unterzeichneten PKVC 800 durch die gleiche kollisionsresistente Hash-Funktion, die bei Schritt 5 des Protokolls P1 verwendet wurde und verifiziert, dass es für diesen kryptographischen Hash-Wert eine Aufzeichnung in der Hash-Tabelle 704 gibt.
    • 3. Der Berechtigungsnachweisserver 103 erzeugt eine Einmal-PKVC 900. Das Einmal-PKVC 900 ist in 15 dargestellt und umfasst: ein Feld 901 mit den gleichen Inhalten wie das Feld 801 des nicht-unterzeichneten PKVC 800; ein Feld 902 mit den gleichen Inhalten wie das Feld 802 des nicht-unterzeichneten PKVC 800; ein Feld 903, das ein Ablaufdatum und -zeit enthält, die eine kurze Gültigkeitsperiode für das Einmal-PKVC 900 spezifizieren; und ein Signaturfeld 904. Die Dauer der Gültigkeitsperiode kann durch das Subjekt 706 spezifiziert werden. Die Signatur, die in dem Feld 904 enthalten ist, wird durch den Berechtigungsnachweisserver 703 berechnet, unter Verwendung des privaten Schlüssels des PKVA 701, auf einer Sequenz 905 von Nicht-Signaturfeldern, wie z. B. Felder 901, 902 und 903. Der Berechtigungsnachweisserver 703 sendet das PKVC 900 an das Subjekt 706.
  • Falls sein privater Schlüssel beeinträchtigt ist, verwendet das Subjekt 706 das folgende Protokoll P3, um eine Nachahmung durch einen Angreifer zu verhindern.
  • Protokoll P3
    • 1. Das Subjekt 706 sendet eine Öffentlicher-Schlüssel-Aufhebungsanforderung an den Berechtigungsnachweisserver 703, die das nicht-unterzeichnete PKVC 800, das durch die Registrierungsautorität 702 bei Schritt 3 von Protokoll P1 gesendet wurde und den PKRC enthält, der durch die Registrierungsautorität 702 bei Schritt 4 des Protokolls P1 gesendet wurde.
    • 2. Der Berechtigungs-Server 703 berechnet den kryptographischen Hash-Wert des nicht-unterzeichneten PKVC 800, unter Verwendung der gleichen kollisionsresistenten Hash-Funktion, die durch die Registrierungsautorität 702 bei Schritt 5 des Protokolls P1 verwendet wurde.
    • 3. Der Berechtigungsnachweisserver 703 schlägt in seiner Hash-Tabelle 704 nach, findet die Aufzeichnung, die durch den kryptographischen Hash-Wert, der bei Schritt 2 von Protokoll 3 berechnet wurde, verschlüsselt wurde, und prüft, dass das PKRC-Feld dieser Aufzeichnung mit dem PKRC zusammenfällt, das durch das Subjekt 706 bei Schritt 1 des Protokolls 3 gesendet wurde. Falls dies der Fall ist, entfernt der Berechtigungsnachweisserver 703 die Aufzeichnung von seiner Hash-Tabelle 704.
  • Das Subjekt 706 verwendet das folgende Protokoll P4, um sich bei der herkömmlichen Zertifikatautorität 705 zu registrieren.
  • Protokoll P4
    • 1. Das Subjekt 706 sendet die folgenden Daten an die herkömmliche Zertifikatautorität 705: das nicht-unterzeichnete PKVC 800; den öffentlichen Schlüssel des PKVA 701; und ein oder mehrere Identitätsattribute.
    • 2. Die Zertifikatautorität 705 verifiziert durch eine Außerband-Administrationseinrichtung, dass das eine oder die mehreren Identitätsattribute, die durch das Subjekt 706 bei Schritt 1 des Protokolls P4 gesendet werden, für das Subjekt gelten.
    • 3. Die Zertifikatautorität 705 berechnet einen Öffentlicher-Schlüssel-Validierungs-Hash-Wert (PKVH) durch Anlegen einer kollisionsresistenten Hash-Funktion, wie z. B. MD5 oder SHA-1, an die Verkettung des öffentlichen Schlüssels des Subjekts 706, der PKVN, die in dem Feld 802 des nicht-unterzeichneten PKVC 800 enthalten ist, und des öffentlichen Schlüssels des PKVA 701.
    • 4. Die Zertifikatautorität 705 erzeugt und unterzeichnet ein aufhebbares Zertifikat 1000 und sendet das aufhebbare Zertifikat an das Subjekt 706. Das aufhebbare Zertifikat 1000 ist in 16 dargestellt und umfasst: ein Feld 1001, das eine Seriennummer enthält; ein optionales Feld 1002, das den öffentlichen Schlüssel des Subjekts enthält (der von dem Feld 801 des nicht-unterzeichneten PKVC 800 erhalten wird); ein Feld 1003, das das eine oder die mehreren Identitätsattribute enthält, die bei Schritt 1 des Protokolls 4 gesendet werden; ein Feld 1004, das den PKVH enthält, der bei Schritt 3 des Protokolls P4 berechnet wird; und ein Feld 1005, das ein Ablaufdatum/-zeit enthält. Falls das X.509v3-Format verwendet wird, wird bei einem Ausführungsbeispiel das Feld 1004 als kritisch markiert, um sicherzustellen, dass es durch einen älteren Verifizierer nicht ignoriert wird, der den Zweck dieses Feldes nicht versteht. Das aufhebbare Zertifikat 1000 umfasst auch ein Signaturfeld 1006, das eine digitale Signatur enthält, die über eine Sequenz von Nicht-Signatur-Feldern 1007 berechnet wird, wie z. B. Felder 1001, 1002, 1003, 1004 und 1005, unter Verwendung des privaten Schlüssels der Zertifikatautorität 705. Das Feld 1002 ist optional, weil das aufhebbare Zertifikat 1000 in Verbindung mit einem Einmal-PKVC 900 verwendet wird, das den öffentlichen Schlüssel des Subjekts enthält und der PKVH 1004 von dem öffentlichen Schlüssel des Subjekts abgeleitet ist.
  • Das folgende Protokoll P5 wird durch das Subjekt 706 verwendet, um seine Identität dem Verifizierer 707 zu beweisen.
  • Protokoll P5
    • 1. Das Subjekt 706 sendet die folgenden Daten an den Verifizierer 707: das aufhebbare Zertifikat 1000, ein kürzlich ausgegebenes Einmal-PKVC 900; und den öffentlichen Schlüssel des PKVA 701.
    • 2. Der Verifizierer 707 validiert das aufhebbare Zertifikat 1000. Der Verifizierer 707 verwendet das Feld 1005, um zu verifizieren, dass das Zertifikat 1000 nicht abgelaufen ist. Der Verifizierer 707 verifiziert die Signatur 1006 unter Verwendung des öffentlichen Schlüssels der Zertifikatautorität 705. Der Verifizierer 707 verifiziert, dass die Seriennummer 1001 nicht in der aktuellsten Zertifikataufhebungsliste erscheint, die durch die Zertifikatautorität 705 ausgegeben wird.
    • 3. Der Verifizierer 707 validiert das Einmal-PKVC 900. Der Verifizierer 707 verwendet das Feld 903, um zu verifizieren, dass das Einmal-PKVC 900 nicht abgelaufen ist. Der Verifizierer 707 verifiziert die Signatur 904 unter Verwendung des öffentlichen Schlüssels des PKVA 701, der durch das Subjekt 706 bei Schritt 1 des Protokolls P5 gesendet wurde.
    • 4. Der Verifizierer 707 berechnet einen PKVH durch Anlegen der gleichen kollisionsresistenten Hash-Funktion, die durch die Zertifikatautorität 705 bei Schritt 3 des Protokolls P4 verwendet wurde, an die Verkettung des öffentlichen Schlüssels des Subjekts 706, der PKVN in Feld 902, die in der Einmal-PKVC 900 enthalten ist, die durch das Subjekt 706 bei Schritt 1 des Protokolls P5 gesendet wurde, und des öffentlichen Schlüssels des PKVA 701, der ebenfalls durch das Subjekt 706 bei Schritt 1 des Protokolls P5 gesendet wurde. Der Verifizierer 707 prüft, dass der berechnete PKVH mit dem Feld 1004 des aufhebbaren Zertifikats 1000 zusammenfällt, der durch das Subjekt 706 bei Schritt 1 des Protokolls P5 gesendet wird.
    • 5. Das Subjekt 706 weist die Kenntnis des privaten Schlüssels nach, der dem öffentlichen Schlüssel zugeordnet ist, der in Feld 901 des Einmal-PKVC 900 enthalten ist, das bei Schritt 1 des Protokolls P5 gesendet wird. Das Verfahren, bei dem das Subjekt 706 Kenntnis des privaten Schlüssels nachweist, hängt von dem Kryptosystem ab, für den das Privater/Öffentlicher-Schlüssel-Paar des Subjekts erzeugt wurde. Falls dieses Kryptosystem beispielsweise ein Digital-Signatur-Kryptosystem ist, kann das Subjekt 706 Kenntnis des privaten Schlüssels nachweisen durch Verwenden des privaten Schlüssels, um eine Größe zu unterzeichnen, die von einer Zufallsgröße abgeleitet ist, die durch den Verifizierer 707 erzeugt wird. Der Verifizierer 707 kann dann die Signatur unter Verwendung des öffentlichen Schlüssels 901 verifizieren.
  • Authentifizierung mit Einmalzertifikaten
  • Bei der Authentifizierung mit Einmalzertifikaten, wie es oben für die leichte PKI 30/30' beschrieben ist, die Einmalzertifikate verwendet, hat die Zertifikatautorität eine Off-Line-Komponente, die Registrierungsautorität, und eine On-Line-Komponente, den Berechtigungsnachweisserver. Das Subjekt registriert seinen öffentlichen Schlüssel und Identitätsattribute bei der Registrierungsautorität. Die Registrierungsautorität gibt ein nicht-unterzeichnetes Zertifikat an das Subjekt aus, das den öffentlichen Schlüssel an die Attribute bindet und sendet den kryptographischen Hash-Wert des nicht-unterzeichneten Zertifikats an den Berechtigungsnachweisserver, der den kryptographischen Hash-Wert in einer Hash-Tabelle speichert. Später legt das Subjekt das nicht-unterzeichnete Zertifikat dem Berechtigungsnachweisserver vor und erhält ein Einmalzertifikat, so lange der Hash-Wert des nicht-unterzeichneten Zertifikats noch in der Hash-Tabelle ist. Schließlich verwendet das Subjekt das Einmalzertifikat und auch die Kenntnis seines privaten Schlüssels, um seine Identität einem Verifizierer nachzuweisen.
  • Um einen PKVA zu nutzen, wird das obige Authentifizierungsverfahren, das Einmalzertifikate verwendet, wie folgt modifiziert. Wenn sich das Subjekt bei der Registrierungsautorität der regulären Zertifikatautorität registriert, legt das Subjekt das nicht-unterzeichnete PKVC und den öffentlichen Schlüssel des PKVA vor, anstatt einfach nur seinen öffentlichen Schlüssel vorzulegen. Das Subjekt legt auch wie vorher seine Identitätsattribute vor. Die Registrierungsautorität gibt ein reguläres nicht-unterzeichnetes Zertifikat an das Subjekt aus, das den öffentlichen Schlüssel an die Attribute bindet. Die Registrierungsautorität sendet einen kryptographischen Hash-Wert an den Berechtigungsnachweisserver, der berechnet wird durch Anlegen einer kollisionsresistenten Hash-Funktion, wie z. B. MD5 und SHA-1, an die Verkettung des regulären nicht-unterzeichneten Zertifikats mit der PKVN und dem öffentlichen Schlüssel des PKVA. Der Berechtigungsnachweisserver fügt den kryptographischen Hash-Wert wie vorher seiner Hash-Tabelle hinzu.
  • Später legt das Subjekt das reguläre nicht-unterzeichnete Zertifikat dem Berechtigungsnachweisserver der regulären Zertifikatautorität vor, zusammen mit einem Einmal-PKVC und dem öffentlichen Schlüssel des PKVA. Der Berechtigungsnachweisserver verwendet den öffentlichen Schlüssel des PKVA, um die Signatur auf dem Einmal-PKVC zu verifizieren. Der Berechtigungsnachweisserver prüft, dass der öffentliche Schlüssel, der in dem regulären nicht-unterzeichneten Zertifikat erscheint, der gleiche öffentliche Schlüssel ist, der in dem Einmal-PKVC erscheint. Der Berechtigungsnachweisserver berechnet einen kryptographischen Hash-Wert durch Anlegen der gleichen kollisionsresistenten Hash-Funktion an die Verkettung des regulären nicht-unterzeichneten Zertifikats, der PKVN, die in dem PKVC enthalten ist, und des öffentlichen Schlüssels des PKVA und prüft, dass der kryptographische Hash-Wert in seiner Hash-Tabelle erscheint. Falls der berechnete kryptographische Hash-Wert in der Hash-Tabelle des Berechtigungsnachweisservers erscheint, gibt der Berechtigungsnachweisserver ein reguläres Einmalzertifikat an das Subjekt aus, das den öffentlichen Schlüssel des Subjekts an die Identitätsattribute bindet. Das Einmal-PKVC muss nach wie vor gültig sein und das Ablaufdatum/-zeit des regulären Einmalzertifikats ist so eingestellt, dass dasselbe nicht später abläuft als das Einmal-PKVC. Wie bei den obigen unmodifizierten Authentifizierungsverfahren, das Einmalzertifikate verwendet, verwendet das Subjekt das reguläre Einmalzertifikat und auch die Kenntnis seines privaten Schlüssels, um seine Identität einem Verifizierer nachzuweisen.
  • Es ist anzumerken, dass der Verifizierer nicht modifiziert werden muss, um den PKVA zu nutzen. Das Subjekt legt dem Verifizierer nur das reguläre Einmalzertifikat vor, das durch den Berechtigungsnachweisserver ausgegeben wird, nicht das Einmal-PKVC. Das Einmal-PKVC wird nur dem Berechtigungsnachweisserver vorgelegt.
  • Falls der private Schlüssel beeinträchtigt ist, benachrichtigt das Subjekt den PKVA, der das nicht-unterzeichnete PKVC aufruft. Nachdem der PKVA das nicht-unterzeichnete PKVC aufruft, gibt der PKVA keine weiteren Einmal-PKVCs mehr aus, die den öffentlichen Schlüssel des Subjekts an die gleiche PKVN binden. Daher kann ein Angreifer keine regulären Einmalzertifikate von dem Berechtigungsnachweisserver erhalten. Der Angreifer kann den öffentlichen Schlüssel des Subjekts bei dem gleichen PKVA oder bei einem anderen PKVA registrieren und ein Einmal-PKVC für den öffentlichen Schlüssel erhalten. Der Angreifer kann dann das reguläre nicht-unterzeichnete Zertifikat des Subjekts, das Einmal-PKVC, und den öffentlichen Schlüssel des PKVA dem Berechtigungsnachweisserver vorlegen. Der Hash-Wert, der durch den Berechtigungs-Server berechnet wird, wird jedoch nicht mit dem Hash-Wert übereinstimmen, der durch die Registrierungsautorität an den Berechtigungsnachweisserver gesendet wurde, wenn sich das Subjekt bei der Registrierungsautorität registriert hat. Falls der Angreifer in der Tat einen andren PKVA verwendet hat, ist der öffentliche Schlüssel des PKVA, der bei der Hash-Berechnung verwendet wird, anders. Falls der Angreifer den gleichen PKVA verwendet hat, hat der PKVA eine andere PKVN erzeugt und somit ist die PKVN, die bei der Hash-Berechnung verwen det wird, anders. Da die Hash-Berechnung eine kollisionsresistente Hash-Funktion verwendet, ist das Ergebnis der Berechnung höchstwahrscheinlich unterschiedlich, wenn entweder der öffentliche Schlüssel des PKVA oder die PKVN sich ändern.
  • Eine PKI gemäß der vorliegenden Erfindung, die die Verwendung eines PKVS mit der Verwendung von regulären Einmalzertifikaten kombiniert, ist allgemein bei 1100 in 17 dargestellt. Die PKI 1100 umfasst mehrere Hauptkomponenten, die jeweils ein Softwareprogramm sind. Die Hauptsoftwareprogrammkomponenten der PKI 1100 laufen auf einem oder mehreren Computersystemen. Bei einem Ausführungsbeispiel läuft jede der Hauptsoftwareprogrammkomponenten auf ihrem eigenen Computersystem.
  • Die PKI 1100 von 17 unterscheidet sich von der in 13 dargestellten PKI 700 dadurch, dass anstatt dieselbe die reguläre Zertifikatautorität 705 des PKI 700 aufweist, die aufhebbare Zertifikate und Zertifikataufhebungslisten ausgibt, die PKI 1100 eine reguläre Zertifikatautorität 1101 umfasst, die Einmalzertifikate ausgibt. Die Zertifikatautorität 1101 umfasst eine Off-Line-Komponente 1102, die als Registrierungsautorität (RA) wirkt, und eine On-Line-Komponente 1103, die als ein Berechtigungsnachweisserver (CS) wirkt. Die Registrierungsautorität 1102 behält eine Datenbank 1104 bei, während der Berechtigungsnachweisserver 1103 eine Hash-Tabelle 1105 beibehält.
  • Das Subjekt 706 verwendet das obige Protokoll P1, um seinen öffentlichen Schlüssel bei dem PKVA 701 zu registrieren und ein nicht-unterzeichnetes PKVC 800 zu erhalten.
  • Das Subjekt 706 verwendet das obige Protokoll P2, um ein Einmal-PKVC 900 zu erhalten.
  • Falls der private Schlüssel des Subjekts beeinträchtigt ist, verwendet das Subjekt 706 das obige Protokoll P3, um eine Nachahmung durch einen Angreifer zu verhindern.
  • Das Subjekt 706 verwendet das folgende Protokoll P6, um sich bei der regulären Zertifikatautorität 1101 zu registrieren und ein reguläres nicht-unterzeichnetes Zertifikat zu erhalten.
  • Protokoll P6
    • 1. Das Subjekt 706 sendet die folgenden Daten an die Registrierungsautorität 1102: das nicht-unterzeichnete PKVC 800; den öffentlichen Schlüssel des PKVA; und ein oder mehrere Identitätsattribute.
    • 2. Die Registrierungsautorität 1102 verifiziert durch eine Außerband-Administrationseinrichtung, dass das eine oder die mehreren Identitätsattribute, die durch das Subjekt 706 bei Schritt 1 des Protokolls P6 gesendet werden, für das Subjekt 706 gelten.
    • 3. Die Registrierungsautorität 1102 erzeugt ein reguläres nicht-unterzeichnetes Zertifikat 1200, speichert nicht-unterzeichnete Zertifikate 1200 in seiner Datenbank 1104 und sendet das nicht-unterzeichnete Zertifikat 1200 an das Subjekt 706. Das reguläre nicht-unterzeichnete Zertifikat 1200 ist in 18 dargestellt und umfasst die folgenden Felder: ein oder mehrere Felder 1201, die Metadaten enthalten, wie z. B. Seriennummer und Ausgebername; ein optionales Feld 1202, das den öffentlichen Schlüssel des Subjekts 706 enthält; ein oder mehrere Felder 1203, die das eine oder die mehreren Identitätsattribute enthalten, die durch das Subjekt 706 bei Schritt 1 des Protokolls P6 gesendet wurden; ein optionales Feld 1204, das ein Ablaufdatum/-zeit spezifiziert; und ein optionales Feld 1205, das eine Dauer für die Gültigkeitsperiode jedes Einmalzertifikats spezifiziert, das gegen das nicht-unterzeichnete Zertifikat 1200 ausgegeben wird.
    • 4. Die Registrierungsautorität 1102 erzeugt einen kryptographischen Hash-Wert durch Anlegen einer kollisionsresistenten Hash-Funktion, wie z. B. MD5 oder SHA-1, an die Verkettung des regulären nicht-unterzeichneten Zertifikats 1002, des PKVN-Felds 802, das in der PKVC 800 enthalten ist, die bei Schritt 1 des Protokolls P6 gesendet wird, und des öffentlichen Schlüssels des PKVA, der ebenfalls bei Schritt 1 des Protokolls P6 gesendet wurde. Die Registrierungsautorität 1102 sendet diesen kryptographischen Hash-Wert an den Berechtigungsnachweisserver 1103.
    • 5. Der Berechtigungsnachweisserver 1103 speichert den kryptographischen Hash-Wert, der durch die Registrierungsautorität 1102 bei Schritt 4 des Protokolls 6 gesendet wurde, in seiner Hash-Tabelle 1105.
  • Das Subjekt 706 verwendet das folgende Protokoll P7, um ein reguläres Einmalzertifikat von dem Berechtigungsnachweisserver 1103 zu erhalten.
  • Protokoll P7
    • 1. Das Subjekt 706 sendet die folgenden Daten an den Berechtigungsnachweisserver 1103: das reguläre nicht-unterzeichnete Zertifikat 1200, das von der Registrierungsautorität 1102 unter Verwendung des Protokolls P6 erhalten wurde; ein Einmal-PKVC 900, das vor kurzem von dem PKVA 701 unter Verwendung des Protokolls P2 erhalten wurde; und den öffentlichen Schlüssel des PKVA 701.
    • 2. Der Verifizierer 707 validiert das Einmal-PKVC 900, das bei Schritt 1 des Protokolls P7 gesendet wurde. Der Verifizierer 707 verwendet das Feld 903, um zu verifizieren, dass das Zertifikat 900 nicht abgelaufen ist. Der Verifizierer 707 verifiziert die Signatur 904 unter Verwendung des öffentlichen Schlüssels des PKVA 701, der ebenfalls bei Schritt 1 des Protokolls P7 gesendet wurde.
    • 3. Der Berechtigungsnachweisserver 1103 berechnet einen kryptographischen Hash-Wert durch Anlegen der gleichen kollisionsresistenten Hash-Funktion, die durch die Registrierungsautorität 1102 bei Schritt 4 des Protokolls P6 verwendet wurde, an eine Verkettung des regulären nicht-unterzeichneten Zertifikats 1200, das durch das Subjekt 706 bei Schritt 1 des Protokolls P7 gesendet wurde, der PKVN 902, die in dem PKVC 900 enthalten ist, das durch das Subjekt 706 bei Schritt 1 des Protokolls P7 gesendet wurde, und des öffentlichen Schlüssels des PKVA 701, der ebenfalls durch das Subjekt 706 bei Schritt 1 des Protokolls P7 gesendet wurde.
    • 4. Der Berechtigungsnachweisserver 1103 verifiziert, dass der bei Schritt 3 des Protokolls P7 berechnete kryptographische Hash-Wert in seiner Hash-Tabelle 1105 vorliegt.
    • 5. Der Berechtigungsnachweisserver 1103 erzeugt, unterzeichnet und sendet ein reguläres Einmalzertifikat 1300 an das Subjekt 706. Das reguläre Einmalzertifikat 1300 ist in 19 dargestellt und umfasst die folgenden Felder: ein oder mehrere Felder 1301, die Metadaten enthalten, wie z. B. Seriennummer und Ausgebername; ein Feld 1302, das den öffentlichen Schlüssel des Subjekts 706 enthält, das identisch ist mit dem Feld 901 des Einmal-PKVC 900, das durch das Subjekt 706 bei Schritt 1 des Protokolls P7 gesendet wurde; ein oder mehrere Felder 1303, die identisch sind mit dem einen oder den mehreren Subjekt-Identitätsattributen 1203 des regulären nicht-unterzeichneten Zertifikats 1200; ein Feld 1304, das ein Ablaufdatum/-zeit für das reguläre Einmalzertifikat 1300 spezifiziert; und ein oder mehrere Felder 1305, die die Signatur des Berechtigungsnachweisservers 1103 auf einer Sequenz von Nicht-Signaturfeldern 1306 enthalten. Das Ablaufdatum/-zeit, das durch das Feld 1304 spezifiziert wird, darf nicht später sein als das Ablaufdatum/-zeit, das durch das Feld 903 des Einmal-PKVC 900 spezifiziert wird, das durch das Subjekt 706 bei Schritt 1 des Protokolls P7 gesendet wird. Falls das reguläre nicht-unterzeichnete Zertifikat 1200, das durch das Subjekt 706 bei Schritt 1 des Protokolls P7 gesendet wird, das optionale Feld 1205 enthält, das eine Dauer für das Gültigkeitsintervall der Einmalzertifikate spezifiziert, darf das Ablaufdatum/-zeit, das durch das Feld 1304 spezifiziert wird, ebenfalls nicht später sein als das Ende eines Intervalls von einer solchen Dauer, die beginnt, wenn das Einmalzertifikat 1300 erzeugt wird.
  • Das Subjekt 706 verwendet das reguläre Einmalzertifikat 1300 in Verbindung mit seinem privaten Schlüssel, um seine Identität einem Verifizierer 707 zu beweisen. Dies wird erreicht wie bei dem unmodifizierten Protokoll für Authentifizierung durch Einmalzertifikate, wie es oben für die leichte PKI 30/30' beschrieben ist, die Einmalzertifikate verwendet.
  • Authentifizierung mit nicht-unterzeichneten Zertifikaten
  • Bei der Authentifizierung mit nicht-unterzeichneten Zertifikaten, wie sie in der mitanhängigen Patentanmeldung mit dem Titel „LIGHTWEIGHT PUBLIC KEY INFRASTRUCTURE EMPLOYING UNSIGNED CERTIFICATES" beschrieben ist, registriert das Subjekt seinen öffentlichen Schlüssel und Identitätsattribute mit der Zertifikatautorität. Die Zertifikatautorität gibt ein nicht-unterzeichnetes Zertifikat an das Subjekt aus, das den öffentlichen Schlüssel an die Attribute bindet und sendet den kryptographischen Hash-Wert des nicht-unterzeichneten Zertifikats an jeden Verifizierer, der den kryptographischen Hash-Wert in seiner Hash-Tabelle speichert. Später legt das Subjekt das nicht-unterzeichnete Zertifikat einem Verifizierer vor und weist die Kenntnis des privaten Schlüssels nach, der dem öffentlichen Schlüssel zugeordnet ist, der in dem Zertifikat enthalten ist. Der Verifizierer berechnet den kryptographischen Hash-Wert des nicht-unterzeichneten Zertifikats und prüft, dass der berechnete kryptographische Hash-Wert in seiner Hash-Tabelle erscheint.
  • Um einen PKVA zu nutzen, wird das obige Authentifizierungsverfahren, das nicht-unterzeichnete Zertifikate verwendet, wie folgt modifiziert. Wenn es sich bei der regulären Zertifikatautorität registriert, legt das Subjekt das nicht-unterzeichnete PKVC unter den öffentlichen Schlüssel des PKVA vor, anstatt einfach seinen öffentlichen Schlüssel vorzulegen. Das Subjekt legt auch seine Identitätsattribute vor, wie bei dem nicht-modifizierten Verfahren. Die reguläre Zertifikatautorität gibt dem Subjekt ein reguläres nicht-unterzeichnetes Zertifikat aus, das den öffentlichen Schlüssel an die Attribute bindet. Die Zertifikatautorität sendet jedem Verifizierer einen kryptographischen Hash-Wert, der berechnet wird durch Anlegen einer kollisionsresistenten Hash-Funktion, wie z. B. MD5 und SHA-1, an die Verkettung des regulären nicht-unterzeichneten Zertifikats mit der PKVN und dem öffentlichen Schlüssel des PKVA. Jeder Verifizierer addiert den kryptographischen Hash-Wert zu seiner Hash-Tabelle, wie bei dem unmodifizierten Verfahren.
  • Später legt das Subjekt das reguläre nicht-unterzeichnete Zertifikat einem Verifizierer vor, zusammen mit einer Einmal-PKVC und dem öffentlichen Schlüssel des PKVA. Der Verifizierer prüft, dass das Einmal-PKVC nicht abgelaufen ist und verwendet den öffentlichen Schlüssel des PKVA, um die Signatur auf dem Einmal-PKVC zu verifizieren. Der Verifizierer prüft, dass der öffentliche Schlüssel, der in dem regulären nicht-unterzeichneten Zertifikat erscheint, der gleiche öffentliche Schlüssel ist, der in dem Einmal-PKVC erscheint, und das Subjekt weist die Kenntnis des privaten Schlüssels nach, der diesem öffentlichen Schlüssel zugeordnet ist. Der Verifizierer berechnet einen kryptographischen Hash-Wert durch Anlegen der gleichen kollisionsresistenten Hash-Funktion an die Verkettung des nicht-unterzeichneten Zertifikats, der PKVN, die in dem PKVC enthalten ist und des öffentlichen Schlüssels des PKVA und prüft, dass der kryptographische Hash-Wert in seiner Hash-Tabelle erscheint.
  • Falls der private Schlüssel beeinträchtigt ist, benachrichtigt das Subjekt den PKVA, der das nicht-unterzeichnete PKVC aufhebt. Nachdem der PKVA das nicht-unterzeichnete PKVC aufhebt, gibt der PKVA keine Einmal-PKVCs mehr aus, die den öffentlichen Schlüssel des Subjekts an die gleiche PKVN binden. Daher kann sich ein Angreifer nicht als das Subjekt ausgeben, wenn er mit einem Verifizierer interagiert. Der Angreifer kann den öffentlichen Schlüssel des Subjekts bei dem gleichen oder einem anderen PKVA registrieren und eine Einmal-PKVC für den öffentlichen Schlüssel erhalten. Der Angreifer kann dann das reguläre nicht-unterzeichnete Zertifikat des Subjekts, das Einmal-PKVC und den öffentlichen Schlüssel des PKVA einem Verifizierer vorlegen. Der Hash-Wert, der durch den Verifizierer berechnet wird, wird jedoch nicht mit dem Hash-Wert übereinstimmen, der durch die Zertifikatautorität an den Verifizierer gesendet wurde, als sich das Subjekt bei der Zertifikatautorität registriert hat. Falls der Angreifer einen anderen PKVA verwendet hat, ist in der Tat der öffentliche Schlüssel des PKVA, der bei der Hash-Berechnung verwendet wird, anders. Falls der Angreifer den gleichen PKVA verwendet hat, hat der PKVA eine andere PKVN erzeugt, und somit ist die PKVN, die bei der Hash-Berechnung verwendet wird, anders. Da die Hash-Berechnung eine kollisionsresistente Hash-Funktion verwendet, ist das Ergebnis höchstwahrscheinlich anders, wenn sich entweder der öffentliche Schlüssel des PKVA oder die PKVN ändern.
  • Eine PKI gemäß der vorliegenden Erfindung, die die Verwendung eines PKVS mit der Verwendung von regulären nicht-unterzeichneten Zertifikaten kombiniert, die direkt den Verifizierern vorgelegt werden, ist allgemein bei 1400 in 20 dargestellt. Die PKI 1400 umfasst mehrere Hauptkomponenten, die jeweils ein Softwareprogramm sind. Die Hauptsoftwareprogrammkomponenten der PKI 1400 laufen auf einem oder mehreren Computersystemen. Bei einem Ausführungsbeispiel läuft jede der Hauptsoftwareprogramm-Komponenten auf ihrem eigenen Computersystem.
  • Die PKI 1400 unterscheidet sich von der PKI 700 und der PKI 1100 dadurch, dass die reguläre Zertifikatautorität, die die Identität des Subjekts zertifiziert, in PKI 1400 als eine reguläre Zertifikatautorität 1401 implementiert ist, die nicht-unterzeichnete Zertifikate für die direkte Verwendung durch Verifizierer ausgibt. Die reguläre Zertifikatautorität 1401 behält eine Datenbank 1402 bei. Außerdem ist jeder Verifizierer 707 in der PKI 1400 mit der Zertifikatautorität 1401 verbunden, von der jeder Verifizierer 707 kryptographische Hash-Werte empfängt, die jeder Verifizierer 707 in einer Hash-Tabelle 1403 speichert.
  • Das Subjekt 706 verwendet das obige Protokoll P1, um seinen öffentlichen Schlüssel bei dem PKVA 701 zu registrieren und ein nicht-unterzeichnetes PKVC 800 zu erhalten.
  • Das Subjekt 106 verwendet das obige Protokoll P2, um ein Einmal-PKVC 900 zu erhalten.
  • Falls der private Schlüssel des Subjekts beeinträchtigt ist, verwendet das Subjekt 706 das obige Protokoll P3, um eine Nachahmung durch einen Angreifer zu verhindern.
  • Das Subjekt 706 verwendet das folgende Protokoll P8, um sich bei der Zertifikatautorität 1401 zu registrieren und ein nicht-unterzeichnetes Zertifikat zu erhalten.
  • Protokoll P8
    • 1. Das Subjekt 706 sendet die folgenden Daten an die Zertifikatautorität 1401: das nicht-unterzeichnete PKVC 800; den öffentlichen Schlüssel des PKVA 701; und ein oder mehrere Identitätsattribute.
    • 2. Die Zertifikatautorität 1401 verifiziert durch eine Außerband-Administrationseinrichtung, dass das eine oder die mehreren Identitätsattribute, die durch das Subjekt 706 bei Schritt 1 des Protokolls P8 gesendet werden, für das Subjekt 706 gelten.
    • 3. Die Zertifikatautorität 1401 erzeugt ein reguläres nicht-unterzeichnetes Zertifikat 1500, speichert das reguläre nicht-unterzeichnete Zertifikat 1500 in ihrer Datenbank 1402 und sendet das reguläre nicht-unterzeichnete Zertifikat 1500 an das Subjekt 706. Das reguläre nicht-unterzeichnete Zertifikat 1500 ist in 21 dargestellt und umfasst die folgenden Felder: ein oder mehrere Felder 1501, die Metadaten enthalten, wie z. B. Seriennummer und Ausgebername; ein optionales Feld 1502, das den öffentlichen Schlüssel des Subjekts 706 enthält; ein oder mehrere Felder 1503, die das eine oder die mehreren Identitätsattribute enthalten, die durch das Subjekt 706 bei Schritt 1 des Protokolls P8 gesendet wurden; und ein optionales Feld 1504, das ein Ablaufdatum/-zeit spezifiziert.
    • 4. Die Zertifikatautorität 1401 erzeugt einen kryptographischen Hash-Wert durch Anlegen einer kollisionsresistenten Hash-Funktion, wie z. B. MD5 oder SHA-1, an die Verkettung des regulären nicht-unterzeichneten Zertifikats 1501, der PKVN 802, die in dem PKVC 800 enthalten ist, das bei Schritt 1 des Protokolls P8 enthalten ist, und des öffentlichen Schlüssels des PKVA 701, der ebenfalls bei Schritt 1 des Protokolls P8 gesendet wurde. Die Zertifikatautorität 1401 sendet diesen kryptographischen Hash-Wert an jeden Verifizierer 707.
    • 5. Jeder Verifizierer 707 addiert den kryptographischen Hash-Wert, der durch die Zertifikatautorität 1401 bei Schritt 4 des Protokolls P8 gesendet wurde, zu seiner Hash-Tabelle 1403.
  • Das Subjekt 706 verwendet das folgende Protokoll P9, um seine Identität einem Verifizierer 707 zu beweisen.
  • Protokoll P9
    • 1. Das Subjekt 706 sendet die folgenden Daten an den Verifizierer 707: das reguläre nicht-unterzeichnete Zertifikat 1500, das von der Zertifikatautorität 1401 unter Verwendung des Protokolls P8 erhalten wurde; ein Einmal-PKVC 900, das vor kurzem von dem PKVA 701 unter Verwendung des Protokolls P2 erhalten wurde; und den öffentlichen Schlüssel des PKVA 701.
    • 2. Der Verifizierer 707 validiert das Einmal-PKVC 900, das bei Schritt 1 des Protokolls P9 gesendet wurde. Der Verifizierer 707 verwendet das Feld 903, um zu verifizieren, dass das Zertifikat 900 nicht abgelaufen ist. Der Verifizierer 707 verifiziert die Signatur 904 unter Verwendung des öffentlichen Schlüssels des PKVA 701, der ebenfalls bei Schritt 1 des Protokolls P9 gesendet wurde.
    • 3. Der Verifizierer 707 berechnet einen kryptographischen Hash-Wert durch Anlegen der gleichen kollisionsresistenten Hash-Funktion, die durch die Zertifikatautorität 1401 bei Schritt 4 des Protokolls P8 verwendet wurde, an die Verkettung des regulären nicht-unterzeichneten Zertifikats 1500, das durch das Subjekt bei Schritt 1 des Protokolls P9 gesendet wurde, der PKVN 902, die in dem PKVC 900 enthalten ist, das durch das Subjekt bei Schritt 1 des Protokolls P9 gesendet wurde, und des öffentlichen Schlüssels des PKVA 701, der ebenfalls durch das Subjekt bei Schritt 1 des Protokolls P9 gesendet wurde.
    • 4. Der Verifizierer 707 verifiziert, dass der kryptographische Hash-Wert, der bei Schritt 3 des Protokolls P9 gesendet wurde, in seiner Hash-Tabelle 1403 vorliegt.
    • 5. Das Subjekt 706 weist Kenntnis des privaten Schlüssels nach, der dem öffentlichen Schlüssel zugeordnet ist, der in dem Feld 901 der Einmal-PKVC 900 zugeordnet ist, die bei Schritt 1 des Protokolls P9 gesendet wurde. Das Verfahren, bei dem das Subjekt 706 Kenntnis des privaten Schlüssels nachweist, hängt von dem Kryptosystem ab, für das das Privater/Öffentlicher-Schlüssel-Paar des Subjekts erzeugt wurde. Falls dieses Kryptosystem beispielsweise ein Digital-Signatur-Kryptosystem ist, kann das Subjekt 706 Kenntnis des privaten Schlüssels nachweisen durch Verwenden des privaten Schlüssels, um eine Größe zu unterzeichnen, die von einer Zufallsgröße abgeleitet ist, die durch den Verifizierer 707 erzeugt wird. Der Verifizierer 707 verifiziert dann die Signatur unter Verwendung des öffentlichen Schlüssels 901, der in dem PKVC 900 enthalten ist.
  • Authentifizierung ohne Zertifikate
  • Wenn es nur einen Verifizierer gibt, gibt es keinen Bedarf, reguläre Zertifikate für Authentifizierung zu verwenden. Das Subjekt kann seinen öffentlichen Schlüssel und Identitätsattribute direkt bei dem Verifizierer registrieren. Der Verifizierer verifiziert durch ein Außerband-Administrationsverfahren, dass die Attribute nur für das Subjekt gelten, und zeichnet die Bindung des öffentlichen Schlüssels an die Identitätsattribute auf. Später bei einem wiederholten Besuch beweist das Subjekt seine Identität einfach durch Nachweisen der Kenntnis des privaten Schlüssels, der dem öffentlichen Schlüssel zugeordnet ist, der durch den Verifizierer aufgezeichnet wird.
  • Um einen PKVA zu nutzen, wird das obige Authentifizierungsverfahren ohne Zertifikate wie folgt modifiziert. Wenn es sich bei dem Verifizierer registriert, legt das Subjekt das nicht-unterzeichnete PKVC und den öffentlichen Schlüssel dem PKVA vor, anstatt nur seinen öffentlichen Schlüssel vorzulegen. Das Subjekt legt auch seine Identitätsattribute vor, wie bei dem unmodifizierten Verfahren. Der Verifizierer berechnet einen kryptographischen Hash-Wert durch Anlegen einer kollisionsresistenten Hash-Funktion, wie z. B. MD5 und SHA-1, an den öffentlichen Schlüssel des Subjekts, die PKVN und den öffentlichen Schlüssel des PKVA. Der Verifizierer zeichnet die Identitätsattribute und den kryptographischen Hash-Wert auf. Eine Hash-Tabelle, die durch den kryptographischen Hash-Wert verschlüsselt ist, kann verwendet werden, um die Aufzeichnung zu finden, die dem kryptographischen Hash-Wert effizient gegeben ist.
  • Bei einem wiederholten Besuch legt das Subjekt ein Einmal-PKVC zusammen mit dem öffentlichen Schlüssel des PKVA vor und weist Kenntnis des privaten Schlüssels nach, der dem öffentlichen Schlüssel zugeordnet ist, der in dem Einmal- PKVC enthalten ist. Der Verifizierer prüft, dass das Einmal-PKVC nicht abgelaufen ist und verifiziert die Signatur auf dem Einmal-PKVC unter Verwendung des öffentlichen Schlüssels des PKVA. Der Verifizierer extrahiert die PKVN von dem Einmal-PKVC und berechnet einen kryptographischen Hash-Wert durch Anlegen der gleichen kollisionsresistenten Hash-Funktion an den öffentlichen Schlüssel des Subjekts, die PKVN und den öffentlichen Schlüssel des PKVA. Der Verifizierer verwendet diesen Hash-Wert, um die Aufzeichnung wiederzugewinnen, die die Identitätsattribute des Subjekts enthält.
  • Authentifizierung ohne Zertifikate in einem E-Commerce-Szenario
  • Eine Authentifizierung ohne reguläre Zertifikate ist sinnvoll in dem Szenario, wo ein E-Commerce-Kunde, der einen Web-Browser verwendet, auf eine E-Commerce-Web-Site zugreift. In dem E-Commerce-Szenario ist es wünschenswert, in der Lage zu sein, das SSL-Protokoll, das Kommunikation zwischen Web-Browsern und Web-Servern schützt, ohne Modifikation zu verwenden. Dies kann erreicht werden durch eine kleine Variation des obigen modifizierten Protokolls für Authentifizierung ohne reguläre Zertifikate.
  • Bei diesem Szenario ist das Subjekt der Kunde, der den Web-Browser verwendet und der Verifizierer ist der Web-Server der E-Commerce-Site.
  • Bevor es sich bei dem Verifizierer registriert, erhält das Subjekt ein Einmal-PKVC von dem PKVA. Um sich bei dem Verifizierer zu registrieren, legt das Subjekt eine Kette von Zertifikaten vor, die folgendes umfassen: das gerade erhaltene Einmal-PKVC, unterzeichnet durch den PKVA; und ein selbst-unterzeichnetes Zertifikat, das den öffentlichen Schlüssel des PKVA enthält. Die Signaturen auf diesen beiden Zertifikaten sind nicht funktional notwendig, aber sie sind praktisch notwendig, so dass die Implementierung des SSL-Protokolls bei der E-Commerce-Site die Zertifikatkette annimmt. Die SSL-Implementierung prüft auch, dass das Einmal-PKVC nicht abgelaufen ist.
  • Gleichartig dazu legt das Subjekt erneut bei einem wiederholten Besuch eine Zertifikatkette vor, die ein aktuell gültiges Einmal-PKVC und ein selbst-unterzeichnetes Zertifikat umfasst, das den öffentlichen Schlüssel des PKVA enthält.
  • Eine PKI gemäß der vorliegenden Erfindung, die einen PKVS aufweist, der bei einem E-Commerce-Szenario verwendet wird, wo es nur einen Verifizierer gibt, ist allgemein bei 1600 in 22 dargestellt. Die PKI 1600 umfasst mehrere Hauptkomponenten, die jeweils ein Softwareprogramm sind. Die Hauptsoftwareprogrammkomponenten der PKI 1600 laufen auf ein oder mehreren Computersystemen. Bei einem Ausführungsbeispiel läuft jede der Hauptsoftwareprogrammkomponenten auf ihrem eigenen Computersystem.
  • Der PKVS des PKI 1600 verwendet einen oder mehrere PKVAs 701, die ähnlich sind wie die PKVAs 701, die durch die PKVSs der PKIs 700, 1100 und 1400 verwendet werden. Die PKI 1600 verwendet jedoch keine reguläre Zertifikatautorität.
  • Bei der PKI 1600 ist das Subjekt 706 ein E-Commerce-Kunde, der einen Web-Browser verwendet, während der Verifizierer 707 eine E-Commerce-Site ist, die einen Web-Server verwendet. Das Subjekt 706 und der Verifizierer 707 verwenden das SSL-Protokoll für gegenseitige Authentifizierung und für den Schutz empfindlicher Kommunikation. Die Protokolle, die bei diesem Ausführungsbeispiel verwendet werden, sind auf solche Weise entworfen, dass das SSL-Protokoll ohne Modifikation zwischen dem Subjekt 706 und dem Verifizierer 707 verwendet werden kann.
  • Bei der PKI 1600 hat der Verifizierer 707 eine Datenbank 1601 aus Kundenaufzeichnungen, auf die effizient durch eine Hash-Tabelle 1602 zugegriffen werden kann. Jeder Eintrag in der Hash-Tabelle 1602 wird durch einen kryptographischen Hash-Wert wie oben beschrieben verschlüsselt und enthält einen Zeiger zu einer Kundenaufzeichnung in der Datenbank 1601.
  • Bei der PKI 1600 verwendet das Subjekt 706 das obige Protokoll P1, um seinen öffentlichen Schlüssel bei dem PKVA 701 zu registrieren und ein nicht-unterzeichnetes PKVC 800 zu erhalten.
  • Das Subjekt 706 verwendet das obige Protokoll P2, um ein Einmal-PKVC 900 zu erhalten.
  • Falls der private Schlüssel des Subjekts beeinträchtigt ist, verwendet das Subjekt 706 das obige Protokoll P3, um eine Nachahmung durch einen Angreifer zu verhindern.
  • Das Subjekt 706 verwendet das folgende Protokoll P10, um sich direkt bei dem Verifizierer 707 zu registrieren.
  • Protokoll P10
    • 1. Das Subjekt 706 und der Verifizierer 707 richten eine SSL-Verbindung ein. Als Teil des SSL-Handshake, der die SSL-Verbindung einrichtet, sendet das Subjekt 706 dem Verifizierer 707 eine Clientzertifikatkette, die ein aktuell gültiges Einmal-PKVC 900 und ein selbstunterzeichnetes Zertifikat umfasst, das den öffentlichen Schlüssel des PKVA 701 enthält. Außerdem weist das Subjekt 706 als Teil des SSL-Handshake die Kenntnis des privaten Schlüssels nach, der dem öffentlichen Schlüssel 901 zugeordnet ist, der in dem PKVC 900 enthalten ist. Der Verifizierer 707 authentifiziert sich selbst auf übliche Weise als Teil des SSL-Handshake.
    • 2. Das Subjekt 706 sendet Kundeninformationen, wie z. B. Name, Adresse, Kreditkartennummer usw. an den Verifizierer 707 unter dem Schutz der SSL-Verbindung, die bei Schritt 1 des Protokolls P10 eingerichtet wird.
    • 3. Der Verifizierer 707 führt jegliche Außerbandverifizierung der Daten, die durch das Subjekt 706 bei Schritt 2 des Protokolls P10 gesendet werden, durch, die durch die Sicherheitsrichtlinie erforderlich sein könnte. Dann erzeugt der Verifizierer 707 eine Kundenaufzeichnung in seiner Datenbank 1601, die die Informationen enthält, die durch das Subjekt 706 bei Schritt 2 des Protokolls P10 gesendet werden.
    • 4. Der Verifizierer 707 berechnet einen kryptographischen Hash-Wert durch Anlegen einer kollisionsresistenten Hash-Funktion, wie z. B. MD5 oder SHA-1, an den öffentlichen Schlüssel des Subjekts 706, die PKVN 902, die in dem Einmal-PKVC 900 enthalten ist, das durch das Subjekt 706 bei Schritt 1 des Protokolls P10 gesendet wurde, und den öffentlichen Schlüssel des PKVA 701, der ebenfalls bei Schritt 1 des Protokolls P10 gesendet wurde.
  • Bei einem wiederholten Besuch auf die E-Commerce-Web-Site wird das folgende Protokoll P11 durch das Subjekt 706 verwendet, um seine Identität zu beweisen, und durch den Verifizierer 707, um die Kundenaufzeichnung wiederzugewinnen, die bei Schritt 3 des Protokolls P10 für das Subjekt 706 eingerichtet wurde.
  • Protokoll P11
    • 1. Das Subjekt 706 und der Verifizierer 707 richten eine SSL-Verbindung ein. Als Teil des SSL-Handshake sendet das Subjekt 106 eine Clientzertifikatkette, die ein aktuell gültiges Einmal-PKVC 900 und ein selbstunterzeichnetes Zertifikat umfasst, das den öffentlichen Schlüssel des PKVA 701 enthält. Außerdem weist das Subjekt 706 als Teil des SSL-Handshake Kenntnis des privaten Schlüssels nach, der dem öffentlichen Schlüssel 901 zugeordnet ist, der in dem PKVC 900 enthalten ist. Außerdem verwendet der Verifizierer 707 als Teil des SSL-Handshake das Ablaufdatum/-zeit-Feld 903 in dem Einmal-PKVC 900, um zu verifizieren, dass das Einmal-PKVC nicht abgelaufen ist. Außerdem verifiziert der Verifizierer 707 als Teil des SSL-Handshake die Signatur 904 in dem Einmal-PKVC 900 unter Verwendung des öffentlichen Schlüssels des PKVA 701, der in dem selbst-unterzeichneten Zertifikat enthalten ist. Der Verifizierer 707 authentifiziert sich auch selbst auf die übliche Weise als Teil des SSL-Handshake.
    • 2. Der Verifizierer 707 berechnet einen kryptographischen Hash-Wert durch Anlegen der gleichen kollisionsresistenten Hash-Funktion, die bei Schritt 4 des Protokolls P10 verwendet wird, an den öffentlichen Schlüssel des Subjekts 706, die PKVN 902, die in dem Einmal-PKVC 900 enthalten ist, das durch das Subjekt 706 bei Schritt 1 des Protokolls P11 gesendet wird, und den öffentlichen Schlüssel des PKVA 701, der auch bei Schritt 1 des Protokolls P11 gesendet wurde.
    • 3. Der Verifizierer 707 verwendet den kryptographischen Hash-Wert, der bei Schritt 2 des Protokolls P11 berechnet wird, um seine Hash-Tabelle 1602 nachzuschlagen. Das Nachschlagen gewinnt einen Hash-Tabelleneintrag wieder, der einen Zeiger zu einer Aufzeichnung in der Datenbank 1601 enthält. Der Verifizierer 707 verwendet diesen Zeiger, um die Aufzeichnung wiederzugewinnen, die für das Subjekt 706 bei Schritt 3 des Protokolls P10 eingerichtet wurde.
  • Zusammenfassung
  • Bei einem wahrscheinlichen Szenario für zukünftigen E-Commerce erzeugt ein Benutzer ein Öffentlicher/Privater-Schlüssel-Paar und registriert die Öffentlicher-Schlüssel-Komponente des Schlüssel-Paars bei einer beliebigen Anzahl von E-Commerce-Sites. Bei wiederholten Besuchen dieser Sites authentifiziert der Benutzer den Benutzer durch Nachweisen der Kenntnis des entsprechenden privaten Schlüssels. Dieses Szenario liefert eine höhere Sicherheit als die aktuelle Verwendung eines Passworts, das über eine SSL-Verbindung gesendet wird, das verletzlich ist, weil Benutzer typischerweise das gleiche Passwort für alle Sites verwenden. Dieses Szenario vermeidet auch die Übertragung der Verantwortlichkeit für Kundenregistrierung von der E-Commerce-Site an eine Zertifikats-Autorität, was für die meisten E-Commerce-Sites unannehmbar ist. Eine Schwierigkeit bei diesem Szenario ist, dass der Benutzer jede einzelne E-Commerce-Site benachrichtigen muss, bei der der Benutzer den privaten Schlüssel registriert hat, falls der private Schlüssel des Benutzers beeinträchtigt ist.
  • Die vorliegende Erfindung löst diese Schwierigkeit durch die Verwendung eines Öffentlicher-Schlüssel-Validierungsdienstes (PKVS). Der Benutzer registriert den öffentlichen Schlüssel des Benutzers bei dem PKVS und erhält ein nicht-unterzeichnetes Zertifikat ähnlich wie die oben beschriebene leichte PKI, die Einmalzertifikate verwendet, außer dass der öffentliche Schlüssel anstatt an die Identität des Benutzers an eine Seriennummer gebunden ist. Somit übernimmt der PKVS keine Verantwortung für das Identifizieren des Benutzers durch den Registrierungsprozess. Der PKVS garantiert nur, dass die Seriennummer einmalig ist. Sobald der Benutzer den öffentlichen Schlüssel bei dem PKVS registriert hat, und das nicht-unterzeichnete Zertifikat erhalten hat, kann der Benutzer Einmalzertifikate gegen das nicht-unterzeichnete Zertifikat erhalten, ähnlich wie die oben beschriebene leichte PKI, die Einmalzertifikate verwendet.
  • Wenn sich der Benutzer als ein Kunde bei einer E-Commerce-Site registriert, legt der Benutzer den öffentlichen Schlüssel des Benutzers, die Seriennummer, die durch den PKVS ausgegeben wird, und den öffentlichen Schlüssel des PKVS vor. Die E-Commerce-Site berechnet einen kryptographischen Hash-Wert des öffentlichen Schlüssels des Benutzers, der Seriennummer, die durch den PKVS ausgegeben wurde, und den öffentlichen Schlüssel des PKVS und speichert den Hash-Wert als Teil der Kundenaufzeichnung. Bei einem nachfolgenden Besuch der Site präsentiert der Benutzer ein Einmalzertifikat, das durch den PKVS ausgegeben wurde, zusammen mit dem öffentlichen Schlüssel des PKVS. Die Site verifiziert die Signatur auf dem Einmalzertifikat, verifiziert, dass das Einmalzertifikat nicht abgelaufen ist, berechnet den kryptographischen Hash-Wert des öffentlichen Schlüssels des Benutzers und der Seriennummer, die in dem Zertifikat enthalten ist, das mit dem öffentlichen Schlüssel des PKVS verkettet ist, und verifiziert, dass der Hash-Wert mit dem einen zusammenfällt, der als Teil der Kundenaufzeichnung gespeichert ist.
  • Falls der private Schlüssel beeinträchtigt ist, fragt der Benutzer den PKVS, das nicht-unterzeichnete Zertifikat aufzuheben. Der PKVS hebt das nicht-unterzeichnete Zertifikat auf, ähnlich wie die oben beschriebene leichte PKI, die Einmalzertifikate verwendet. Nachdem der PKVS das nicht-unterzeichnete Zertifikat aufhebt, gibt der PKVS nie mehr Einmalzertifikate für die gleiche Seriennummer aus, die mit dem gleichen privaten Schlüssel unterzeichnet ist. Dies macht es für einen Angreifer, der den privaten Schlüssel des Benutzers kennt, unmöglich, eine E-Commerce-Site zu besuchen und vorzugeben, bei einem wiederholten Besuch der Benutzer zu sein.
  • Die vorliegende Erfindung kann auch verwendet werden, um andere Verwendungen eines öffentlichen Schlüssels neben der beispielhaften Registrierung des öffentlichen Schlüssels mit einer E-Commerce-Site zu validieren. Darüber hinaus kann das Subjekt sein Privater/Öffentlicher-Schlüssel-Paar für mehrere Authentifizierungszwecke verwenden, und kann ein anderes Authentifizierungsverfahren für jeden Zweck verwenden, wie z. B. die unterschiedlichen beispielhaften Authentifizierungsverfahren, die oben beschrieben sind, einschließlich: 1) Authentifizierung unter Verwendung herkömmlicher öffentlicher Schlüssel-Zertifikate; 2) Authentifizierung unter Verwendung von Einmalzertifikaten; 3) Authentifizierung unter Verwendung nicht-unterzeichneter Zertifikate, die den Verifizierern direkt präsentiert werden; und 4) Authentifizierung ohne Zertifikate. Die Authentifizierung, die das Verfahren der nicht-unterzeichneten Zertifikate verwendet, ist geeignet, wenn es nur einige wenige Verifizierer gibt (z. B. bis zu einige hundert Verifizierer). Das Verfahren der Authentifizierung ohne Zertifikate umfasst nur einen Verifizierer. Jedes dieser vier Verfahren kann modifiziert werden, um einen PKVA gemäß der vorliegenden Erfindung zu nutzen.
  • 23 stellt ein Ausführungsbeispiel eines Computersystems 250 und ein externes computerlesbares Medium 252 dar, das gemäß der vorliegenden Erfindung verwendet werden kann, um eine oder mehrere der Hauptsoftware-Programmkomponenten einer leichten PKI gemäß der vorliegenden Erfindung zu implementieren, wie z. B. PKI 30, PKI 30', PKI 730, PKI 830 und PKI 930. Ausführungsbeispiele des externen computerlesbaren Mediums 252 umfassen, sind aber nicht beschränkt auf: eine CD-ROM, eine Diskette und eine Plattenkassette. Jede der Hauptsoftware-Programmkomponenten einer leichten PKI gemäß der vorliegenden Erfindung kann in einer Vielzahl von kompilierten und interpretierten Computersprache implementiert sein. Das externe computerlesbare Medium 252 speichert Quellcode, Objektcode, ausführbaren Code, Shell-Skripte und/oder Dynamische-Verbindung-Bibliotheken für eine der Hauptsoftware-Programmkomponenten einer leichten PKI gemäß der vorliegenden Erfindung. Ein Eingabegerät 254 liest das externe computerlesbare Medium 252 und liefert diese Daten an das Computersystem 250. Ausführungsbeispiele des Eingabegeräts 254 umfassen, sind aber nicht beschränkt auf: einen CD-ROM-Leser, ein Disketten-Laufwerk und eine Datenkassettenlesevorrichtung.
  • Das Computersystem 250 umfasst eine zentrale Verarbeitungseinheit 256 zum Ausführen einer der Hauptsoftware-Programmkomponenten einer leichten PKI gemäß der vorliegenden Erfindung. Das Computersystem 250 umfasst auch einen lokalen Plattenspeicher 262 zum lokalen Speichern einer der Hauptsoftware-Programmkomponenten einer leichten PKI gemäß der vorliegenden Erfindung vor, während und nach der Ausführung. Jede der Hauptsoftware-Programmkomponenten einer leichten PKI gemäß der vorliegenden Erfindung verwendet auch den Speicher 260 in dem Computersystem während der Ausführung. Auf die Ausführung einer der Hauptsoftware-Programmkomponenten einer leichten PKI gemäß der vorliegenden Erfindung hin werden Ausgangsdaten erzeugt und zu dem Ausgabegerät 258 gerichtet. Ausführungsbeispiele des Ausgabegeräts 258 umfassen, sind aber nicht beschränkt auf: eine Computeranzeigevorrichtung, einen Drucker und/oder eine Plattenspeichervorrichtung.
  • Obwohl hierin zu Darstellungszwecken des bevorzugten Ausführungsbeispiels spezifische Ausführungsbeispiele dargestellt und beschrieben wurden, ist für Durchschnittsfachleute auf diesem Gebiet klar, dass eine große Vielzahl von Implementierungen für die spezifischen gezeigten und beschriebenen Ausführungsbeispiele eingesetzt werden kann, ohne von dem Schutzbereich der vorliegenden Erfindung abzuweichen. Fachleute auf dem Gebiet der Chemie, Mechanik, Elektromechanik, Elektrizität und Computer werden ohne weiteres erkennen, dass die vorliegende Erfindung in einer großen Vielzahl von Ausführungsbeispielen implementiert werden kann. Diese Anwendung soll alle Adaptionen oder Variationen der hierin erörterten bevorzugten Ausführungsbeispiele abdecken. Daher ist klar, dass diese Erfindung nur durch die Ansprüche begrenzt ist.

Claims (28)

  1. Ein Öffentlicher-Schlüssel-Validierungssystem PKVA (701), das folgende Merkmale umfasst: eine Off-Line-Registrierungsautorität (702) zum Ausgeben eines ersten nicht-unterzeichneten Öffentlicher-Schlüssel-Validierungszertifikats, nicht-unterzeichnetes PKVC, (800) off-line zu einem Subjekt (706), das einen öffentlichen Schlüssel (801) des Subjekts an eine erste Öffentlicher-Schlüssel-Seriennummer PKVN (802) bindet, wobei die Registrierungsautorität eine Zertifikatdatenbank von nicht-unterzeichneten PKVCs beibehält, in der dieselbe das erste nicht-unterzeichnete PKVC speichert; und einen On-Line-Berechtigungsnachweisserver (703) zum Ausgeben eines einmaligen Öffentlicher-Schlüssel-Validierungszertifikats, Einmal-PKVC, (900) on-line an das Subjekt, wobei das Einmal-PKVC den öffentlichen Schlüssel des Objekts von der ersten nicht-unterzeichneten PKVC an die erste PKVN von dem ersten nicht-unterzeichneten PKVC bindet, wobei der Berechtigungsnachweisserver eine Tabelle (704) beibehält, die Einträge enthält, die gültigen nicht-unterzeichneten PKVCs entsprechen, die in der Zertifikatdatenbank gespeichert sind.
  2. Das PKVA gemäß Anspruch 1, bei dem die erste PKVN anders ist als alle vorhergehenden PKVNs, die durch die Registrierungsautorität erzeugt werden.
  3. Das PKVA gemäß Anspruch 1, bei dem der Berechtigungsnachweisserver auf eine Aufhebungsanforderung von dem Subjekt anspricht, um den ersten nicht-unterzeichneten PKVC-Eintrag in der Tabelle des Berechtigungsnachweisservers ungültig zu machen.
  4. Das PKVA gemäß Anspruch 3, bei dem die Registrierungsautorität einen Öffentlicher-Schlüssel-Aufhebungscode PKRC erzeugt, der durch das Subjekt in seiner Aufhebungsanforderung verwendet wird.
  5. Das PKVA gemäß Anspruch 4, bei dem die Registrierungsautorität den PKRC über einen sicheren Kanal, der Datenvertrauenswürdigkeit liefert, an das Subjekt sendet.
  6. Das PKVA gemäß Anspruch 1, bei dem das Einmal-PKVC ein Ablaufdatum/Zeit umfasst.
  7. Das PKVA gemäß Anspruch 6, bei dem eine Gültigkeitsperiode, von dem Zeitpunkt, wann der Berechtigungsnachweisserver das Einmal-PKVC ausgibt, zu dem Ablaufdatum/Zeit ausreichend kurz ist, sodass das Einmal-PKVC keiner Aufhebung unterzogen werden muss.
  8. Das PKVA gemäß Anspruch 6, bei dem das Einmal-PKVC keiner Aufhebung unterzogen wird.
  9. Das PKVA gemäß Anspruch 1, bei dem die Tabelle, die durch den Berechtigungsnachweisserver beibehalten wird, eine Hash-Tabelle ist, die kryptografische Hash-Werte von gültigen nicht-unterzeichneten PKVCs enthält, die in der Zertifikatdatenbank gespeichert sind, und einen kryptografischen Hash-Wert des ersten nicht-unterzeichneten PKVC umfasst.
  10. Das PKVA gemäß Anspruch 1, bei dem der Berechtigungsnachweisserver das Einmal-PKVC ansprechend auf eine Mitteilung von dem Subjekt ausgibt, die das ausgegebene erste nicht-unterzeichnete Zertifikat enthält.
  11. Das PKVA gemäß Anspruch 9, bei dem der Berechtigungsnachweisserver den kryptografischen Hash-Wert des ersten nicht-unterzeichneten PKVC mit einer kollisionsresistenten Hash-Funktion berechnet.
  12. Das PKVC gemäß Anspruch 11, bei dem die kollisionsresistente Hash-Funktion eine SHA-1 Hash-Funktion ist.
  13. Das PKVC gemäß Anspruch 11, bei dem die kollisionsresistente Hash-Funktion eine MD5-Hash-Funktion ist.
  14. Das PKVC gemäß Anspruch 1, bei dem es das Einmal-PKVC dem Subjekt ermöglicht, das Einmal-PKVC einem Verifizierer für eine Authentifizierung zu präsentieren und zu zeigen, dass das Subjekt Kenntnis eines privaten Schlüssels hat, der dem öffentlichen Schlüssel in dem Einmal-PKVC entspricht.
  15. Ein Verfahren zum Validieren eines öffentlichen Schlüssels (801) eines Subjekts (706), wobei das Verfahren folgende Merkmale umfasst: Ausgeben eines ersten nicht-unterzeichneten Öffentlicher-Schlüssel-Validierungszertifikats, nicht-unterzeichnetes PKVC, (800) off-line an das Subjekt, das den öffentlichen Schlüssel des Subjekts an eine erste Öffentlicher-Schlüssel-Seriennummer PKVN (802) bindet; Beibehalten einer Zertifikatdatenbank von nicht-unterzeichneten PKVCs off-line, die das erste nicht-unterzeichnete PKVC umfassen; Ausgeben eines Einmal-Öffentlicher-Schlüssel-Validierungszertifikats, Einmal-PKVC, (900) on-line an das Subjekt, wobei das Einmal-PKVC den öffentlichen Schlüssel des Subjekts von dem ersten nicht-unterzeichneten PKVC an die erste PKVN von dem ersten nicht-unterzeichneten PKVC bindet; Beibehalten einer Tabelle (704) on-line, die Einträge enthält, die gültigen nicht-unterzeichneten PKVCs entsprechen, die in der Zertifikatdatenbank gespeichert sind.
  16. Das Verfahren gemäß Anspruch 15, bei dem eine Registrierungsautorität den Schritt des Ausgebens des ersten nicht-unterzeichneten Zertifikats durchführt, und bei dem die erste PKVN anders ist als alle vorhergehenden PKVNs, die durch die Registrierungsautorität erzeugt werden.
  17. Das Verfahren gemäß Anspruch 15, das ferner folgenden Schritt umfasst: Ungültigmachen des ersten nicht-unterzeichneten PKVC-Eintrags in der Tabelle ansprechend auf eine Aufhebungsanforderung von dem Subjekt.
  18. Das Verfahren gemäß Anspruch 17, das ferner folgenden Schritt umfasst: Erzeugen eines Öffentlicher-Schlüssel-Aufhebungscodes PKRC, der durch das Subjekt in seiner Aufhebungsanforderung verwendet werden soll.
  19. Das Verfahren gemäß Anspruch 18, das ferner folgenden Schritt umfasst: Senden des PKRC an das Subjekt über einen sicheren Kanal, der eine Datenvertraulichkeit liefert.
  20. Das Verfahren gemäß Anspruch 15, bei dem das Einmal-PKVC ein Ablaufdatum/Zeit umfasst.
  21. Das Verfahren gemäß Anspruch 20, bei dem eine Gültigkeitsperiode von dem Zeitpunkt, wenn die Einmal-PKVC ausgegeben wird, zu dem Ablaufdatum/Zeit ausreichend kurz ist, sodass das Einmal-PKVC keiner Aufhebung unterzogen werden muss.
  22. Das Verfahren gemäß Anspruch 20, bei dem das Einmal-PKVC keiner Aufhebung unterzogen wird.
  23. Das Verfahren gemäß Anspruch 15, bei dem der Schritt des Beibehaltens der Tabelle das Beibehalten einer Hash-Tabelle umfasst, die kryptografische Hash-Werte von gültigen nicht-unterzeichneten PKVCs enthält, die in der Zertifikatdatenbank gespeichert sind, und einen kryptografischen Hash-Wert des ersten nicht-unterzeichneten PKVC umfasst.
  24. Das Verfahren gemäß Anspruch 15, bei dem der Schritt des Ausgebens des Einmal-PKVC ansprechend auf eine Mitteilung von dem Subjekt durchgeführt wird, die das ausgegebene erste nicht-unterzeichnete Zertifikat enthält.
  25. Das Verfahren gemäß Anspruch 23, das ferner folgenden Schritt umfasst: Berechnen des kryptografischen Hash-Werts des ersten nicht-unterzeichneten PKVC mit einer kollisionsresistenten Hash-Funktion.
  26. Das Verfahren gemäß Anspruch 25, bei dem der Berechnungsschritt das Berechnen des kryptografischen Hash-Werts des ersten nicht-unterzeichneten PKVC mit einer SHA-1 Hash-Funktion umfasst.
  27. Das Verfahren gemäß Anspruch 25, bei dem der Berechnungsschritt das Berechnen des kryptografischen Hash- Werts des ersten nicht-unterzeichneten PKVC mit einer MD5 Hash-Funktion umfasst.
  28. Das Verfahren gemäß Anspruch 15, bei dem es das Einmal-PKVC dem Subjekt ermöglicht, das Einmal-PKVC einem Verifizierer für eine Authentifizierung zu präsentieren, und zu zeigen, dass das Subjekt Kenntnis eines privaten Schlüssels hat, der dem öffentlichen Schlüssel in dem Einmal-PKVC entspricht.
DE60112546T 2000-01-14 2001-01-16 Bestätigungsdienst mit öffentlichem schlüssel Expired - Lifetime DE60112546T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US759443 1991-09-13
US17615700P 2000-01-14 2000-01-14
US176157P 2000-01-14
US09/759,443 US7010683B2 (en) 2000-01-14 2001-01-13 Public key validation service
PCT/US2001/001520 WO2001052470A2 (en) 2000-01-14 2001-01-16 Public key validation service

Publications (2)

Publication Number Publication Date
DE60112546D1 DE60112546D1 (de) 2005-09-15
DE60112546T2 true DE60112546T2 (de) 2006-06-01

Family

ID=26871941

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60112546T Expired - Lifetime DE60112546T2 (de) 2000-01-14 2001-01-16 Bestätigungsdienst mit öffentlichem schlüssel

Country Status (7)

Country Link
US (1) US7010683B2 (de)
EP (1) EP1250774B1 (de)
JP (1) JP2003534677A (de)
AT (1) ATE301894T1 (de)
AU (1) AU2001227928A1 (de)
DE (1) DE60112546T2 (de)
WO (1) WO2001052470A2 (de)

Families Citing this family (111)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004104750A (ja) * 2002-07-17 2004-04-02 Hitachi Ltd ディジタル署名の検証方法
US7873589B2 (en) * 2001-04-02 2011-01-18 Invivodata, Inc. Operation and method for prediction and management of the validity of subject reported data
US6854057B2 (en) * 2001-09-06 2005-02-08 America Online, Inc. Digital certificate proxy
US20030084298A1 (en) * 2001-10-25 2003-05-01 Messerges Thomas S. Method for efficient hashing of digital content
KR100843494B1 (ko) * 2001-11-06 2008-07-04 인터내셔널 비지네스 머신즈 코포레이션 데이터 공급 방법 및 시스템, 디지털 서명 제공 방법 및 시스템, 전자 재산의 소유권 이전 방법 및 시스템, 전자 투표 방법 및 시스템, 및 컴퓨터 프로그램을 기록한 컴퓨터로 판독 가능한 기록 매체
FR2840748B1 (fr) * 2002-06-05 2004-08-27 France Telecom Procede et systeme de verification de signatures electroniques et carte a microcircuit pour la mise en oeuvre du procede
JP4304362B2 (ja) * 2002-06-25 2009-07-29 日本電気株式会社 Ｐｋｉ対応の証明書確認処理方法及びその装置、並びにｐｋｉ対応の証明書確認処理プログラム
US7484089B1 (en) * 2002-09-06 2009-01-27 Citicorp Developmemt Center, Inc. Method and system for certificate delivery and management
ATE366010T1 (de) 2002-09-17 2007-07-15 Errikos Pitsos Verfahren und vorrichtung zur bereitstellung einer liste von öffentlichen schlüsseln in einem public-key-system
US7318155B2 (en) * 2002-12-06 2008-01-08 International Business Machines Corporation Method and system for configuring highly available online certificate status protocol responders
US7703128B2 (en) * 2003-02-13 2010-04-20 Microsoft Corporation Digital identity management
CA2422334C (en) * 2003-03-17 2009-06-09 British Telecommunications Public Limited Company Authentication of network users
GB2400461B (en) * 2003-04-07 2006-05-31 Hewlett Packard Development Co Control of access to of commands to computing apparatus
WO2005043807A1 (en) * 2003-10-28 2005-05-12 Certicom Corp. Method and apparatus for verifiable generation of public keys
US7546373B2 (en) * 2003-11-14 2009-06-09 Microsoft Corporation Secure dynamic credential distribution over a network
US7814327B2 (en) 2003-12-10 2010-10-12 Mcafee, Inc. Document registration
US7899828B2 (en) 2003-12-10 2011-03-01 Mcafee, Inc. Tag data structure for maintaining relational data over captured objects
US7774604B2 (en) 2003-12-10 2010-08-10 Mcafee, Inc. Verifying captured objects before presentation
US8656039B2 (en) 2003-12-10 2014-02-18 Mcafee, Inc. Rule parser
US8548170B2 (en) * 2003-12-10 2013-10-01 Mcafee, Inc. Document de-registration
US7984175B2 (en) 2003-12-10 2011-07-19 Mcafee, Inc. Method and apparatus for data capture and analysis system
CA2551819C (en) * 2004-01-09 2015-02-24 Corestreet, Ltd. Signature-efficient real time credentials for ocsp and distributed ocsp
US7930540B2 (en) 2004-01-22 2011-04-19 Mcafee, Inc. Cryptographic policy enforcement
US7984488B2 (en) * 2004-04-09 2011-07-19 Microsoft Corporation Credential roaming in electronic computing systems
CA2564681C (en) * 2004-04-26 2015-09-22 Bruce H. Johnson Methods and systems for dynamically composing distributed interactive applications from high-level programming languages
JP4314152B2 (ja) * 2004-05-21 2009-08-12 株式会社東芝 電子情報保証システム、業務端末
US7461012B2 (en) * 2004-06-08 2008-12-02 Elbex Video Ltd. Method and apparatus for simplified e-commerce shopping via home shopping terminals
US7962591B2 (en) 2004-06-23 2011-06-14 Mcafee, Inc. Object classification in a capture system
US8607334B2 (en) * 2004-07-08 2013-12-10 Research In Motion Limited System and method for secure message processing
US8560534B2 (en) 2004-08-23 2013-10-15 Mcafee, Inc. Database for a capture system
US7949849B2 (en) 2004-08-24 2011-05-24 Mcafee, Inc. File system for a capture system
US8049594B1 (en) * 2004-11-30 2011-11-01 Xatra Fund Mx, Llc Enhanced RFID instrument security
JP4305854B2 (ja) * 2005-01-19 2009-07-29 富士フイルム株式会社 画像管理装置及び方法
US7653696B2 (en) 2005-07-29 2010-01-26 Research In Motion Limited Method and apparatus for processing digitally signed messages to determine address mismatches
US7907608B2 (en) 2005-08-12 2011-03-15 Mcafee, Inc. High speed packet capture
US7818326B2 (en) 2005-08-31 2010-10-19 Mcafee, Inc. System and method for word indexing in a capture system and querying thereof
US20070071243A1 (en) * 2005-09-23 2007-03-29 Microsoft Corporation Key validation service
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US7730011B1 (en) 2005-10-19 2010-06-01 Mcafee, Inc. Attributes of captured objects in a capture system
JP4736722B2 (ja) * 2005-11-04 2011-07-27 コニカミノルタホールディングス株式会社 認証方法、情報処理装置、およびコンピュータプログラム
US7657104B2 (en) 2005-11-21 2010-02-02 Mcafee, Inc. Identifying image type in a capture system
US7600123B2 (en) * 2005-12-22 2009-10-06 Microsoft Corporation Certificate registration after issuance for secure communication
KR100714124B1 (ko) * 2006-02-21 2007-05-02 한국전자통신연구원 사용자 동의 정보를 이용한 증명서 발급 장치 및 방법
EP1833222A1 (de) * 2006-03-10 2007-09-12 Abb Research Ltd. Zugangskontrollprotokoll für eingebettete Geräte
US8504537B2 (en) 2006-03-24 2013-08-06 Mcafee, Inc. Signature distribution in a document registration system
CN101461209A (zh) * 2006-04-10 2009-06-17 信托综合服务公司 安全的数据传输的装置与方法
US8010689B2 (en) 2006-05-22 2011-08-30 Mcafee, Inc. Locational tagging in a capture system
US7958227B2 (en) 2006-05-22 2011-06-07 Mcafee, Inc. Attributes of captured objects in a capture system
US7689614B2 (en) 2006-05-22 2010-03-30 Mcafee, Inc. Query generation for a capture system
US8942433B2 (en) * 2006-12-01 2015-01-27 Luke Small System for scheduling, recordation and biometric validation of interpersonal interactions
US8612773B2 (en) * 2007-05-03 2013-12-17 International Business Machines Corporation Method and system for software installation
US8296559B2 (en) * 2007-05-31 2012-10-23 Red Hat, Inc. Peer-to-peer SMIME mechanism
US8199746B2 (en) 2007-07-20 2012-06-12 Cisco Technology, Inc. Using PSTN reachability to verify VoIP call routing information
US8228903B2 (en) * 2007-07-20 2012-07-24 Cisco Technology, Inc. Integration of VoIP address discovery with PBXs
US8223755B2 (en) * 2007-07-20 2012-07-17 Cisco Technology, Inc. Node reputation based on knowledge of PSTN calls
US8121114B2 (en) * 2009-02-12 2012-02-21 Cisco Technology, Inc. Prevention of voice over IP spam
US8228904B2 (en) * 2007-07-20 2012-07-24 Cisco Technology, Inc. Using PSTN reachability in anonymous verification of VoIP call routing information
US8072967B2 (en) * 2007-07-20 2011-12-06 Cisco Technology, Inc. VoIP call routing information registry including hash access mechanism
US8228902B2 (en) * 2007-07-20 2012-07-24 Cisco Technology, Inc. Separation of validation services in VoIP address discovery system
JP5303881B2 (ja) * 2007-08-15 2013-10-02 富士通セミコンダクター株式会社 電界効果トランジスタ及び電界効果トランジスタの製造方法
US8484752B2 (en) 2007-11-14 2013-07-09 Caterpillar Inc. Verifying authenticity of electronic control unit code
US8321933B2 (en) * 2007-11-14 2012-11-27 Caterpillar Inc. Securing electronic control unit code
US8301877B2 (en) * 2008-03-10 2012-10-30 Secureauth Corporation System and method for configuring a valid duration period for a digital certificate
US9553726B2 (en) * 2008-04-14 2017-01-24 Koninklijke Philips N.V. Method for distributed identification of a station in a network
US8539544B2 (en) * 2008-05-30 2013-09-17 Motorola Mobility Llc Method of optimizing policy conformance check for a device with a large set of posture attribute combinations
US8205242B2 (en) 2008-07-10 2012-06-19 Mcafee, Inc. System and method for data mining and security policy management
US8380531B2 (en) 2008-07-25 2013-02-19 Invivodata, Inc. Clinical trial endpoint development process
TWI426762B (zh) * 2008-08-04 2014-02-11 Ind Tech Res Inst 網路身分管理方法與系統
US9253154B2 (en) 2008-08-12 2016-02-02 Mcafee, Inc. Configuration management for a capture/registration system
US8751791B2 (en) * 2008-09-17 2014-06-10 Motorola Solutions, Inc. Method and device for confirming authenticity of a public key infrastructure (PKI) transaction event
US8850591B2 (en) 2009-01-13 2014-09-30 Mcafee, Inc. System and method for concept building
US8706709B2 (en) 2009-01-15 2014-04-22 Mcafee, Inc. System and method for intelligent term grouping
US8473442B1 (en) 2009-02-25 2013-06-25 Mcafee, Inc. System and method for intelligent state management
US8667121B2 (en) 2009-03-25 2014-03-04 Mcafee, Inc. System and method for managing data and policies
US8447722B1 (en) 2009-03-25 2013-05-21 Mcafee, Inc. System and method for data mining and security policy management
DE102009027681A1 (de) * 2009-07-14 2011-01-20 Bundesdruckerei Gmbh Verfahren und Lesen von Attributen aus einem ID-Token
US8683196B2 (en) * 2009-11-24 2014-03-25 Red Hat, Inc. Token renewal
US8806615B2 (en) 2010-11-04 2014-08-12 Mcafee, Inc. System and method for protecting specified data combinations
WO2013033612A1 (en) * 2011-08-31 2013-03-07 Activldentity Mobile credential revocation
US8667569B2 (en) 2011-09-29 2014-03-04 Target Brands, Inc. Credentials management
US9280653B2 (en) * 2011-10-28 2016-03-08 GM Global Technology Operations LLC Security access method for automotive electronic control units
US10276054B2 (en) 2011-11-29 2019-04-30 Eresearchtechnology, Inc. Methods and systems for data analysis
US20130246336A1 (en) 2011-12-27 2013-09-19 Mcafee, Inc. System and method for providing data protection workflows in a network environment
US9887989B2 (en) * 2012-06-23 2018-02-06 Pomian & Corella, Llc Protecting passwords and biometrics against back-end security breaches
US8489469B1 (en) * 2012-08-30 2013-07-16 Elbex Video Ltd. Method and structure for simplified coding of display pages for operating a closed circuit E-commerce
DE102014204044A1 (de) * 2014-03-05 2015-09-10 Robert Bosch Gmbh Verfahren zum Widerrufen einer Gruppe von Zertifikaten
US9584492B2 (en) * 2014-06-23 2017-02-28 Vmware, Inc. Cryptographic proxy service
GB2527603B (en) * 2014-06-27 2016-08-10 Ibm Backup and invalidation of authentication credentials
US9460567B2 (en) * 2014-07-29 2016-10-04 GM Global Technology Operations LLC Establishing secure communication for vehicle diagnostic data
US20160164884A1 (en) * 2014-12-05 2016-06-09 Skuchain, Inc. Cryptographic verification of provenance in a supply chain
US9843452B2 (en) 2014-12-15 2017-12-12 Amazon Technologies, Inc. Short-duration digital certificate issuance based on long-duration digital certificate validation
US9436923B1 (en) 2015-02-26 2016-09-06 Skuchain, Inc. Tracking unitization occurring in a supply chain
US9641338B2 (en) 2015-03-12 2017-05-02 Skuchain, Inc. Method and apparatus for providing a universal deterministically reproducible cryptographic key-pair representation for all SKUs, shipping cartons, and items
US9699202B2 (en) * 2015-05-20 2017-07-04 Cisco Technology, Inc. Intrusion detection to prevent impersonation attacks in computer networks
US9882727B1 (en) 2015-10-02 2018-01-30 Digicert, Inc. Partitioning certificate revocation lists
US10063536B2 (en) * 2016-03-25 2018-08-28 Ca, Inc. Short term or one-time-use X.509 digital certificates
US10848320B2 (en) * 2016-03-25 2020-11-24 Apple Inc. Device-assisted verification
KR101766303B1 (ko) * 2016-04-19 2017-08-08 주식회사 코인플러그 인증 정보의 생성, 등록, 파기 방법 및 인증 지원 서버
US10104119B2 (en) * 2016-05-11 2018-10-16 Cisco Technology, Inc. Short term certificate management during distributed denial of service attacks
US10764067B2 (en) * 2016-05-23 2020-09-01 Pomian & Corella, Llc Operation of a certificate authority on a distributed ledger
KR101849918B1 (ko) * 2016-10-26 2018-04-19 주식회사 코인플러그 Utxo 기반 프로토콜을 사용하여 통화를 발행 및 지급 결제하는 방법과 이를 이용한 서버
WO2018165248A1 (en) 2017-03-07 2018-09-13 Mastercard International Incorporated Method and system for recording point to point transaction processing
US10275223B2 (en) * 2017-06-22 2019-04-30 International Business Machines Corporation Distributed key-value consistency and mapping
US10938572B2 (en) 2018-01-10 2021-03-02 International Business Machines Corporation Revocable biometric-based keys for digital signing
US11184179B2 (en) * 2018-02-05 2021-11-23 Arris Enterprises Llc Security using self-signed certificate that includes an out-of-band shared secret
JP6952661B2 (ja) * 2018-08-30 2021-10-20 株式会社東芝 情報処理装置、通信機器、情報処理システム、情報処理方法、および情報処理プログラム
CA3112585A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
BR112021011165A2 (pt) * 2018-12-10 2021-08-31 Algorand Inc. Uso de protocolos de blockchain virtuais para implantar uma troca eletrônica justa
RU2706873C1 (ru) * 2018-12-28 2019-11-21 Акционерное общество "Лаборатория Касперского" Система и способ проверки ЭЦП файла
US11334881B2 (en) * 2019-01-28 2022-05-17 Bank Of America Corporation Security tool
CN114125844B (zh) * 2021-11-24 2024-04-19 中国银行股份有限公司 数字证书的生成下载方法及装置

Family Cites Families (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4324645A (en) * 1980-05-06 1982-04-13 Mobil Oil Corporation Upgrading residual oil
US4881264A (en) * 1987-07-30 1989-11-14 Merkle Ralph C Digital signature system and method based on a conventional encryption function
US5224163A (en) * 1990-09-28 1993-06-29 Digital Equipment Corporation Method for delegating authorization from one entity to another through the use of session encryption keys
US5276901A (en) * 1991-12-16 1994-01-04 International Business Machines Corporation System for controlling group access to objects using group access control folder and group identification as individual user
US5210795A (en) * 1992-01-10 1993-05-11 Digital Equipment Corporation Secure user authentication from personal computer
US5475826A (en) * 1993-11-19 1995-12-12 Fischer; Addison M. Method for protecting a volatile file using a single hash
MX9602773A (es) * 1994-01-13 1997-05-31 Bankers Trust Co Sistema criptografico y metodo con aspecto de deposito de plica de clave.
US5825880A (en) * 1994-01-13 1998-10-20 Sudia; Frank W. Multi-step digital signature method and system
US6367013B1 (en) * 1995-01-17 2002-04-02 Eoriginal Inc. System and method for electronic transmission, storage, and retrieval of authenticated electronic original documents
US5796841A (en) * 1995-08-21 1998-08-18 Pitney Bowes Inc. Secure user certification for electronic commerce employing value metering system
US5793868A (en) * 1996-08-29 1998-08-11 Micali; Silvio Certificate revocation system
US6023506A (en) * 1995-10-26 2000-02-08 Hitachi, Ltd. Data encryption control apparatus and method
US5850442A (en) * 1996-03-26 1998-12-15 Entegrity Solutions Corporation Secure world wide electronic commerce over an open network
US5850444A (en) * 1996-09-09 1998-12-15 Telefonaktienbolaget L/M Ericsson (Publ) Method and apparatus for encrypting radio traffic in a telecommunications network
US6029150A (en) * 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system
US5903882A (en) * 1996-12-13 1999-05-11 Certco, Llc Reliance server for electronic transaction system
US5996076A (en) * 1997-02-19 1999-11-30 Verifone, Inc. System, method and article of manufacture for secure digital certification of electronic commerce
US5999919A (en) * 1997-02-26 1999-12-07 At&T Efficient micropayment system
US5982898A (en) * 1997-03-07 1999-11-09 At&T Corp. Certification process
US6044462A (en) * 1997-04-02 2000-03-28 Arcanvs Method and apparatus for managing key revocation
US6212636B1 (en) * 1997-05-01 2001-04-03 Itt Manufacturing Enterprises Method for establishing trust in a computer network via association
US6202151B1 (en) * 1997-05-09 2001-03-13 Gte Service Corporation System and method for authenticating electronic transactions using biometric certificates
JPH10327147A (ja) * 1997-05-21 1998-12-08 Hitachi Ltd 電子認証公証方法およびシステム
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
US6389136B1 (en) * 1997-05-28 2002-05-14 Adam Lucas Young Auto-Recoverable and Auto-certifiable cryptosystems with RSA or factoring based keys
US6125349A (en) 1997-10-01 2000-09-26 At&T Corp. Method and apparatus using digital credentials and other electronic certificates for electronic transactions
US6058484A (en) * 1997-10-09 2000-05-02 International Business Machines Corporation Systems, methods and computer program products for selection of date limited information
US6092201A (en) * 1997-10-24 2000-07-18 Entrust Technologies Method and apparatus for extending secure communication operations via a shared list
JP3905961B2 (ja) * 1997-11-11 2007-04-18 インターナショナル・ビジネス・マシーンズ・コーポレーション 臨時署名認証の方法及びそのシステム
US6263446B1 (en) * 1997-12-23 2001-07-17 Arcot Systems, Inc. Method and apparatus for secure distribution of authentication credentials to roaming users
WO1999035783A1 (en) 1998-01-09 1999-07-15 Cybersafe Corporation Client side public key authentication method and apparatus with short-lived certificates
US6233577B1 (en) * 1998-02-17 2001-05-15 Phone.Com, Inc. Centralized certificate management system for two-way interactive communication devices in data networks
US6233341B1 (en) * 1998-05-19 2001-05-15 Visto Corporation System and method for installing and using a temporary certificate at a remote site
US6324645B1 (en) * 1998-08-11 2001-11-27 Verisign, Inc. Risk management for public key management infrastructure using digital certificates
US6607136B1 (en) * 1998-09-16 2003-08-19 Beepcard Inc. Physical presence digital authentication system
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
US6230266B1 (en) * 1999-02-03 2001-05-08 Sun Microsystems, Inc. Authentication system and process
US6484259B1 (en) * 1999-07-23 2002-11-19 Microsoft Corporation Methods and arrangements for mapping widely disparate portable tokens to a static machine concentric cryptographic environment
AU2087901A (en) 1999-12-13 2001-06-18 Rsa Security Inc. System and method for generating and managing attribute certificates
US7003571B1 (en) * 2000-01-31 2006-02-21 Telecommunication Systems Corporation Of Maryland System and method for re-directing requests from browsers for communication over non-IP based networks
US7353204B2 (en) * 2001-04-03 2008-04-01 Zix Corporation Certified transmission system

Also Published As

Publication number Publication date
DE60112546D1 (de) 2005-09-15
WO2001052470A3 (en) 2002-01-17
US20010032310A1 (en) 2001-10-18
ATE301894T1 (de) 2005-08-15
JP2003534677A (ja) 2003-11-18
EP1250774B1 (de) 2005-08-10
EP1250774A2 (de) 2002-10-23
WO2001052470A2 (en) 2001-07-19
US7010683B2 (en) 2006-03-07
AU2001227928A1 (en) 2001-07-24

Similar Documents

Publication Publication Date Title
DE60112546T2 (de) Bestätigungsdienst mit öffentlichem schlüssel
DE60105326T2 (de) Infrastruktur für öffentliche Schlüssel
DE60102490T2 (de) Infrastruktur für öffentliche Schlüssel
DE602005001613T2 (de) Einrichten eines sicheren kontexts zur übermittlung von nachrichten zwischen computersystemen
US7340600B1 (en) Authorization infrastructure based on public key cryptography
DE60120369T2 (de) Verfahren und Datenträger zur Eintragung von Benutzern einer Public-Key-Infrastruktur und Eintragungssystem
DE60123048T2 (de) Verfahren und vorrichtung für selbstauthentifizierende digitale aufzeichnungen
DE60212577T2 (de) Verfahren und vorrichtung zur beglaubigung von daten
EP2585963B1 (de) Verfahren zur erzeugung eines zertifikats
DE60026468T2 (de) Digitales Zertifikat mit Berechtigungsdaten
DE60124011T2 (de) Verfahren und system zur autorisierung der erzeugung asymmetrischer kryptoschlüssel
DE60119857T2 (de) Verfahren und Vorrichtung zur Ausführung von gesicherten Transaktionen
WO2018167252A1 (de) Ausstellen virtueller dokumente in einer blockchain
EP3114600B1 (de) Sicherheitssystem mit zugriffskontrolle
EP2454700A1 (de) Verfahren zur erzeugung eines soft-tokens
EP2454704A1 (de) Verfahren zum lesen von attributen aus einem id-token
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
DE102012201209A1 (de) Verfahren zur Erzeugung eines Pseudonyms mit Hilfe eines ID-Tokens
Chadwick Authorisation using attributes from multiple authorities
EP2631837B1 (de) Verfahren zur Erzeugung eines Pseudonyms mit Hilfe eines ID-Tokens
DE60109537T2 (de) Vorrichtung, Verfahren und Programm zur Verwaltung eines Benutzerschlüssels, welcher bei der Unterschrift einer Nachricht in einem Datenverarbeitungsgerät benutzt wird
EP4092958B1 (de) Ausstellen eines digitalen verifizierbaren credentials
DE102022130483A1 (de) Verfahren zum beglaubigen eines hardware-wallets einer blockchain
DE102015001817A1 (de) Verfahren, Vorrichtungen und System zur Online-Datensicherung
DE102008013082A1 (de) Verfahren und Anordnung zur Annahme einer digitalen Nutzer-Identität auf Grund transitiven Vertrauens zwischen Beteiligten

Legal Events

Date Code Title Description
8327 Change in the person/name/address of the patent owner

Owner name: HEWLETT-PACKARD DEVELOPMENT CO., L.P., HOUSTON, TE

8364 No opposition during term of opposition