DE602004012506T2 - Kommunikationsgerät, Kommunikationssystem, Verfahren und Programm zur Zertifikatsübertragung - Google Patents

Kommunikationsgerät, Kommunikationssystem, Verfahren und Programm zur Zertifikatsübertragung Download PDF

Info

Publication number
DE602004012506T2
DE602004012506T2 DE602004012506T DE602004012506T DE602004012506T2 DE 602004012506 T2 DE602004012506 T2 DE 602004012506T2 DE 602004012506 T DE602004012506 T DE 602004012506T DE 602004012506 T DE602004012506 T DE 602004012506T DE 602004012506 T2 DE602004012506 T2 DE 602004012506T2
Authority
DE
Germany
Prior art keywords
communication
certificate
digital certificate
data transmission
public key
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.)
Active
Application number
DE602004012506T
Other languages
English (en)
Other versions
DE602004012506D1 (de
Inventor
Tatsuya Imai
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.)
Ricoh Co Ltd
Original Assignee
Ricoh Co Ltd
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
Priority claimed from JP2004217713A external-priority patent/JP4611678B2/ja
Application filed by Ricoh Co Ltd filed Critical Ricoh Co Ltd
Publication of DE602004012506D1 publication Critical patent/DE602004012506D1/de
Application granted granted Critical
Publication of DE602004012506T2 publication Critical patent/DE602004012506T2/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer

Description

  • HINTERGRUND DER ERFINDUNG
  • 1. Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich auf einen Kommunikations- bzw. Datenübertragungsapparat zum Authentifizieren eines anderen Kommunikations- bzw. Datenübertragungsapparates, in dem ein digitales Protokoll bzw. Zertifikat verwendet wird, ein Kommunikations- bzw. Datenübertragungssystem, das den Kommunikations- bzw. Datenübertragungsapparat aufweist, der als ein Hoch-Niveau-Apparat dient und der andere Kommunikations- bzw. Datenübertragungsapparat, der als ein Niedrig-Niveau-Apparat dient, ein Protokoll- bzw. Zertifikat-Übertragungsverfahren zum Übertragen eines digitalen Protokolls bzw. Zertifikats, das bei der Authentifizierung mit den Kommunikations- bzw. Datenübertragungsapparaten und den Kommunikations- bzw. Datenübertragungssystemen verwendet wird, und ein Programm, um es einem Computer zu ermöglichen, als der Kommunikations- bzw. Datenübertragungsapparat zu arbeiten.
  • 2. Beschreibung des Stands der Technik
  • In den vergangenen letzten Jahren und fortschreitend sind verschiedene Systeme konstruiert worden, die viele Kommunikations- bzw. Datenübertragungsapparate aufweisen, die über ein Netzwerk kommunizieren. Ein Beispiel ist das so genannte E-Commerce-System, welches einen Kommunikations-Server-Apparat zum Empfangen von Befehlen über das Internet einsetzt. Bei einem anderen beispielhaften System werden verschiedene elektronische Apparate, die als ein Client-Apparat oder ein Server-Apparat dienen, über ein Netzwerk verbunden, um eine entfernte Handhabung der elektronischen Apparate durch Kommunikation miteinander zu ermöglichen.
  • Ein Bestätigen, ob das Kommunikations-Gegenüber authentifiziert ist und/oder ob an den übertragenen Informationen unerlaubte Änderungen vorgenommen worden sind, ist beim Konstruieren derartiger Systeme notwendig. Insbesondere bei einem Fall von Übertragung vertraulicher Informationen durch das Internet, wo Informationen dafür anfällig sind, an unautorisierte Gegenüber übertragen zu werden, ist es jedenfalls notwendig, zu verhindern, dass Andere den Inhalt der vertraulichen Informationen sehen (stehlen). Als ein Beispiel ist SSL (Secure Socket Layer) ein bekanntes Kommunikations-Protokoll bzw. -Zertifikat, das entwickelt wurde, um die oben beschriebenen Notwendigkeiten zu erfüllen. Dieses Protokoll bzw. Zertifikat authentifiziert das Kommunikations-Gegenüber, indem eine Kombination eines Public Key-Verschlüsselungsverfahrens und eines eigenen VerKeyungsverfahrens verwendet wird, und eine unerlaubte Änderung oder Unterbrechen durch Verschlüsseln vertraulicher Informationen verhindert. Außerdem ermöglicht dieses Protokoll bzw. Zertifikat nicht nur einer Authentifizierung des Kommunikations-Gegenüber, sondern ebenfalls des Kommunikations-Ursprungs.
  • Verfahren (Technologien), die das SSL-Protokoll bzw. -Zertifikat und eine Public Key-VerKeyung verwenden, sind zum Beispiel in den japanischen Offenlegungsveröffentlichungen Nrn. 2002-353959 und 2002-251492 gezeigt. Andere Beispiele für den Einsatz einer Public Key-VerKeyung werden in US 2002/0099663 , EP 1271875 und GB 2359969 beschrieben.
  • US 2002/0099663 beschreibt die Authentifizierung einer Vorrichtung A durch eine Vorrichtung B, indem ein Public Key-Protokoll bzw. -Zertifikat der Vorrichtung A verwendet wird, und die Übertragung des Public Key-Protokolls bzw. -Zertifikats der Vorrichtung B von der Vorrichtung B zur Vorrichtung A der Authentifizierung von Vorrichtung A durch Vorrichtung B folgt.
  • EP 1271875 beschreibt die Authentifizierung von einem Datenaustausch zwischen Vorrichtungen, die entweder als schwach oder als stark geschützt klassifiziert werden. Eine Authentifizierung wird ausgeführt, indem entweder ein Public Key einer bestätigenden Berechtigung oder eines lokal verfügbaren Public Keys ausgeführt wird. GB 2359969 beschreibt die Verwendung von Public Key-Protokollen bzw. -Zertifikaten beim Zuweisen von Adressen.
  • EP-A-1117204 offenbart einen Apparat zum Ausgeben von Public Key-Protokollen bzw. -Zertifikaten für einen Anwender, der einen Speicher umfasst, der mit einem Computer verbunden ist, um eine Vielzahl von Public Keys zu speichern, einschließlich einem, der dem Anwender zugeordnet ist. Der Computer wird so programmiert, um eine Datenvielfalt von willkürlichen Zeitnachrichten zu empfangen, die eine Identifikation des Anwenders umfassen und um, als Antwort zu jeder wenigstens einer ersten Vielzahl von diesen Nachrichten, ein Public Key-Protokoll bzw. -Zertifikat für den Anwender auszugeben, das eine Bezeichnung für den Public Key umfasst, der dem Anwender zugeordnet ist und einer Bezeichnung für einen Verfallszeitpunkt für das Protokoll bzw. Zertifikat, wobei eine Sequenz von Public Key-Protokollen bzw. -Zertifikaten ausgegeben wird, die eine identische Bezeichnung eines Public Keys aufweisen, aber unterschiedliche und sequenzielle Verfallzeitpunkte.
  • Als Nächstes wird ein Kommunikationsverfahren zum Ausführen einer Zwei-Wege-Authentifizierung beschrieben, die SSL verwendet und zwar durch Fokussieren insbesondere auf ein Authentifizierungsverarbeitungsteil. 22 ist ein Flussdiagramm, das Verfahren zeigt, die durch entsprechende Apparate in einer Zwei-Wege-Authentifizierung ausgeführt wurden, wobei SSL verwendet wurde und Informationen, die in den Prozessen verwendet wurden.
  • Wie in 22 gezeigt, sollen beide Kommunikations- bzw. Datenübertragungsapparate A und B, die bei der Zwei-Wege-Authentifizierung eingesetzt werden, und SSL verwenden, mit einem Root-Key-Zertifikat bereitgestellt werden, einem eigenen Key (A, B) und jeweils einem Public Key-Zertifikat. Die privaten Keys A, B sind private Keys, die an jedem der Kommunikations- bzw. Datenübertragungsapparate A, B durch eine Bestätigungs-Behörde (CA) ausgegeben werden. Die Public Key-Zertifikate A, B sind digitale Protokolle bzw. Zertifikate, die durch die CA bereitgestellt werden, in welchen die CA digitale Unterschriften an die Public Keys A, B anhängt, die jeweils den eigenen Keys A, B entsprechen. Die Root Key-Protokolle bzw. Zertifikate, sind digitale Protokolle bzw. Zertifikate, die durch die CA bereitgestellt werden, in welchen die CA digitale Unterschriften an die Root Keys entsprechend den jeweiligen eigenen Root Keys anhängt. Diese Beziehung wird in Bezug auf 23A und 23B beschrieben.
  • In 23A wird der Public Key A aus einem Public Key-Hauptkörper zum Decodieren verschlüsselter Dokumente ausgebildet, der den eigenen Key A verwendet, und bibliografischen Informationen, einschließlich zum Beispiel Informationen für den Ausgeber des Public Key A (CA), oder den/die Gültigkeitsdauer bzw. Validierungsbenennung des Public Key A. Um zu zeigen, dass weder an dem Public Key-Hauptkörper noch an den bibliografischen Informationen des Public Key A unerlaubte Änderungen vorgenommen wurden, führt die CA einen Hash-Prozess mit dem Public Key A aus, und verKeyt den erhalten Hash-Wert, indem der eigene Root Key verwendet wird, um dadurch ein Public Key-Zertifikat A zu erhalten, das den Public Key A aufweist, der mit einer digitalen Unterschrift angehängt wird. Durch Anhängen der digitalen Unterschrift an den Public Key A, werden Identifikations-Informationen des eigenen Root Keys, die für die digitale Unterschrift verwendet werden, als eine Unterschrifts-Key-Information an die bibliografischen Informationen des Public Key A hinzugefügt.
  • Durch Verifizieren einer Authentizität des Public Key-Zertifikates A, wird die digitale Unterschrift, die in dem Public Key-Zertifikat A enthalten ist, mit einem Key-Hauptkörper des Root Keys entschlüsselt, welcher einen Public Key entsprechend des eigenen Root Keys ist. Wenn das Decodieren erfolgreich ist, wird bestimmt, dass die digitale Unterschrift in der Tat durch die CA angehängt wurde. Wenn der Hash-Wert, der durch ein Decodieren mit dem Root Key-Hauptkörper zu dem oben beschriebenen Hash-Wert, der durch die Hash-Verarbeitung des Public Key A erhalten wird, passt, wird bestimmt, das der Public Key weder beschädigt worden ist, noch dass unerlaubte Änderungen vorgenommen wurden. Wenn es möglich ist, erfolgreich empfangene Daten mit dem Public Key A zu entKeyn, wird bestimmt, dass die Daten von dem Halter des eigenen Keys A übertragen wurden.
  • Beim Ausführen der Verifikation ist es notwendig, den Root-Key vorher zu speichern. Wie in 23B gezeigt, enthält das Root-Key-Zertifikat den Root-Key, der mit einer digitalen Unterschrift von dem CA angehängt ist. Das Root-Key-Zertifikat ist eine Unterschrift vom Eigen-Typ, welches es erlaubt, dass die digitale Unterschrift mit dem Public Key, der darin enthalten ist, entschlüsselt wird. Bei der Verwendung des Root-Keys wird die digitale Unterschrift mit dem Root-Key-Hauptkörper, der in dem Root-Key-Zertifikat enthalten ist, entschlüsselt, um dadurch den Hash-Wert, der durch das EntKeyn mit dem Root-Key erhalten wird, zu vergleichen, und den Hash-Wert, der durch eine Hash-Verarbeitung mit dem Root-Key erhalten wird. Wenn die Hash-Werte passen, wird bestimmt, dass der Root Key weder beschädigt ist, noch eine unerlaubte Änderung an ihm vorgenommen wurde.
  • Als Nächstes wird 22 beschrieben. In 22 sind die Pfeile veranschaulicht, um eine Datenübertragung zu bezeichnen, in welcher ein Sender Daten während eines Schrittes überträgt, der nahe mit dem Pfeilstil bezeichnet ist, und ein Empfänger führt einen Schritt aus, der nahe mit dem Pfeilkopf bis zum Empfangen der Daten bezeichnet ist. Zu dem Zeitpunkt, zu dem irgendeiner der Schritte mit einem Fehler endet, wird eine Antwort, die den Fehler berichtet, übertragen und die Authentifizierungsverarbeitung wird unterbrochen. Dasselbe gilt für einen Pfeil, wenn ein Antwort-Berichtsfehler empfangen wird, oder wenn eine Unterbrechung eines Prozesses auftritt.
  • Bei dem Beispiel, das in 22 gezeigt ist, fordert ein Kommunikations- bzw. Datenübertragungsapparat A eine Kommunikation (Verbindung) mit einem Kommunikations- bzw. Datenübertragungsapparat B an. Beim Durchführen der Anforderung führt eine CPU des Kommunikations- bzw. Datenübertragungsapparates A ein vorgeschriebenes Steuerungsprogramm aus und startet den Prozess, der auf der linken Seite des Flussdiagramms gezeigt ist, das in 22 gezeigt ist. Dann überträgt in Schritt S11 der Kommunikations- bzw. Datenübertragungsapparat A eine Verbindungsanforderung zu dem Kommunikations- bzw. Datenübertragungsapparat B.
  • In der Zwischenzeit führt, wenn der Kommunikations- bzw. Datenübertragungsapparat B die Verbindungsanforderung empfängt, eine CPU des Kommunikations- bzw. Datenübertragungsapparates B ein vorgeschriebenes Steuerungsprogramm aus und startet den Prozess, der auf der rechten Seite des Flussdiagrammes gezeigt ist, das in 22 gezeigt ist. Dann erzeugt in Schritt S21 der Kommunikations- bzw. Datenübertragungsapparat B eine erste Zufallszahl(en) und entschlüsselt die erste Zufallszahl mit einem eigenen Key B. In Schritt S22 werden die entschlüsselte erste Zufallszahl und das oben beschriebene Public-Key-Zertifikat B zu dem Kommunikations- bzw. Datenübertragungsapparat A übertragen.
  • In Schritt S12 wird bestimmt, wenn der Kommunikations- bzw. Datenübertragungsapparat A die verKeyte erste Zufallszahl und das Public Key-Zertifikat B empfängt, der Kommunikations- bzw. Datenübertragungsapparat A die Authentizität des Public Key-Zertifikates B, indem das Root-Key-Zertifikat verwendet wird.
  • In Schritt S13 entschlüsselt, wenn der Kommunikations- bzw. Datenübertragungsapparat A bestimmt, dass das Public Key-Zertifikat B authentisch ist, der Kommunikations- bzw. Datenübertragungsapparat die erste verKeyte Zufallszahl, indem der Public Key B verwendet wird, der in dem Public Key-Zertifikat B enthalten ist. Wenn das EntKeyn erfolgreich ist, wird bestimmt, dass die erste Zufallszahl in der Tat von dem Ausgabeziel des Public Key-Zertifikates B stammt.
  • In Schritt S14 erzeugt neben dem Obigen, der Kommunikations- bzw. Datenübertragungsapparat A eine zweite Zufallszahl(en) und einen gemeinsamen Key-Startparameter. Der gemeinsame Key-Startparameter kann zum Beispiel erzeugt werden, indem Daten, verwendet werden, die in vorherigen Kommunikationen gehandhabt wurden. In Schritt S15 wird die zweite Zufallszahl verKeyt, indem der eigene Key A verwendet wird und der gemeinsame Key-Parameter verschlüsselt wird, indem der Public Key B verwendet wird.
  • In Schritt S16 werden die zweite verKeyte Zufallszahl und der verKeyte gemeinsame Stabparameter zu dem Kommunikations- bzw. Datenübertragungsapparat B übertragen. Das Verschlüsseln des gemeinsamen Keyparameters schützt einen Apparat einer anderen Person als den Kommunikations-Gegenüber davor, auf den gemeinsamen Key-Stabparameter zuzugreifen.
  • In Schritt S17 wird ein gemeinsamer Key aus dem gemeinsamen Key-Stabparameter erzeugt, der in S14 erzeugt wird, nach welchem der gemeinsame Key beim Verschlüsseln einer Kommunikation davon verwendet werden soll.
  • In Schritt S23 bestimmt, wenn der Kommunikations- bzw. Datenübertragungsapparat B die Daten empfängt, die in Schritt S16 übertragen werden, der Kommunikations- bzw. Datenübertragungsapparat die Authentizität des Public Key-Zertifikats A, indem das Root-Key-Zertifikat verwendet wird. In Schritt S24 entschlüsselt, wenn es bestimmt wird, dass das Public Key-Zertifikat A authentisch ist, der Kommunikations- bzw. Datenübertragungsapparat B die zweite Zufallszahl, indem der Public Key A verwendet wird, der in dem Public Key-Zertifikat A enthalten ist. Wenn das EntKeyn erfolgreich ist, wird bestimmt, dass die zweite Zufallszahl in der Tat von dem Ausgabeziel des Public Key-Zertifikats B stammt.
  • Dann entschlüsselt in Schritt S25 der Kommunikations- bzw. Datenübertragungsapparat B den gemeinsamen Key-Startparameter, wobei der eigene Key-Startparameter B verwendet wird. Entsprechend teilen sich der Kommunikations- bzw. Datenübertragungsapparat A und der Kommunikations- bzw. Datenübertragungsapparat B denselben Key-Startparameter. Somit hat kein anderer Apparat als die Kommunikations- bzw. Datenübertragungsapparate A und B Zugriff (Kenntnis) auf (von) dem gemeinsamen Key-Startparameter. In Schritt S26 erzeugt, wenn die vorangegangenen Schritte erfolgreich abgeschlossen wurden, der Kommunikations- bzw. Datenübertragungsapparat B einen gemeinsamen Key, welcher zum VerKeyn einer Kommunikation von dorther verwendet werden soll, aus dem gemeinsamen Key-Startparameter.
  • Anschließend an Schritt S17 des Kommunikations- bzw. Datenübertragungsapparates A und Schritt S26 des Kommunikations- bzw. Datenübertragungsapparates B bestätigen die Kommunikations- bzw. Datenübertragungsapparate A und B mit jedem der Erfolge der Authentifizierungsverarbeitung und des VerKeyungsverfahrens, das in der Kommunikation anschließend verwendet werden soll. Dann ist die Authentifizierungsverarbeitung beendet.
  • Der Bestätigungsschritt beinhaltet einen Antwort-Informationserfolg der Authentifizierung von dem Kommunikations- bzw. Datenübertragungsapparat B. Hiernach wird eine Kommunikation zwischen dem Kommunikations- bzw. Datenübertragungsapparat A und dem Kommunikations- bzw. Datenübertragungsapparat B eingerichtet, wobei die Kommunikation durch Verschlüsseln von Daten mit einem gemeinsamen Key-Verschlüsselungsverfahren ausgeführt wird.
  • Mit dieser Authentifizierungsverarbeitung können die Kommunikations- bzw. Datenübertragungsapparate A, B sicher einen gemeinsamen Key teilen, nachdem sie die gegenseitige Authentizität verifiziert haben und dadurch eine sichere Kommunikationsverbindung einrichten.
  • Bei der oben beschriebenen Authentifizierungsverarbeitung jedoch sind der Schritt des Verschlüsselns der zweiten Zufallszahl durch Verwendung des Public Key A (Schritt S15 in 22) und des Schrittes des Übertragens des Public Key-Zertifikats A (Schritt S16 in 22) nicht erforderlich. In diesem Fall, führt der Kommunikations- bzw. Datenübertragungsapparat B die Schritte S22 und S24, gezeigt in 22, nicht aus, sondern führt alternativ einen Prozess aus, der in 24 gezeigt ist. Hier ist, obwohl der Kommunikations- bzw. Datenübertragungsapparat B nicht in der Lage ist, eine Authentizität des Kommunikations- bzw. Datenübertragungsapparates A zu verifizieren, dies in einem Fall ausreichend, indem nur der Kommunikations- bzw. Datenübertragungsapparat A den Kommunikations- bzw. Datenübertragungsapparat B zu verifizieren braucht. In diesem Fall, ist nur das Root-Key-Zertifikat erforderlich, um in den Kommunikations- bzw. Datenübertragungsapparat A gespeichert zu werden und weder der eigene Key A noch das Public Key-Zertifikat A sind erforderlich, um hierin gespeichert zu werden. Es ist nicht erforderlich, das Root-Key-Zertifikat in dem Kommunikations- bzw. Datenübertragungsapparat B zu speichern.
  • Bei der oben beschriebenen Authentifizierungsverarbeitung können Daten, die mit einem Public Key verKeyt wurden, nur mit einem eigenen Key entsprechend dem Public Key entKeyt werden und Daten, die mit einem eigenen Key verKeyt wurden, können nur mit einem Public Key entsprechend dem eigenen Key entschlüsselt werden. Entsprechend kann man bestimmen, dass sein Kommunikations-Gegenüber der Apparat ist, der als das Ausgabeziel in dem Public Key-Zertifikat bezeichnet ist (oder der Anwender des Apparates als das Ausgabeziel in dem Public Key-Zertifikat bezeichnet ist).
  • Unter der Voraussetzung, dass die Geheimhaltung des eigenen Root-Keys des CAs sichergestellt ist, kann man bestimmen, dass das Public Key-Zertifikat durch das CA authentifiziert worden ist, und dass das CA die Korrektheit des Inhalts des Public Key-Zertifikats sichergestellt hat. Jedoch gibt es keinen anderen Weg, als der Authentifizierung des CAs zu vertrauen in Bezug darauf, ob das Kommunikations-Gegenüber in der Tat derjenige ist, der in dem Public Key-Zertifikat beschrieben wurde. Daher ist eine Glaubwürdigkeit des CA ein wichtiger Faktor zum Sicherstellen einer Sicherheit in einer Kommunikation, indem eine Public Key Authentifizierung verwendet wird.
  • Zwischenzeitlich dienen Unternehmen, wie zum Beispiel VeriSign Inc. oder Baltimore Technologies als Mittlerorganisationen, die einen kommerziellen Service zum Verifizieren von Eigentümern von eigenen Keys bereitstellen, digitale Unterschriften von Public Keys bereitstellen, entsprechend den eigenen Keys und Public Key-Zertifikate ausgeben. Public Key-Zertifikate, die weit verbreitet verwendet werden, sind solche, die durch extrem vertraute Mittlerorganisationen ausgegeben werden, die ein Public Key-Ausgabesystem haben, das eigene Keys und Ähnliches strikt kontrolliert. Weiter gibt es bei der Authentifizierung, die digitale Zertifikate verwendet, eine Nachfrage, Public Key-Zertifikate zu verwenden, die durch hochvertrauenswürdige Mittlerorganisationen ausgegeben werden.
  • Außerdem werden Leit-Keys bzw. Route-Keys, die beim Bestimmen des Inhalts von digitalen Unterschriften von hochvertrauenswürdigen Mittlerorganisationen verwendet werden, oft in einem allgemein verwendeten Webbrowser, z. B. Internetexplorer (eingetragene Marke), Netscape (eingetragene Marke), im Voraus installiert.
  • Daher erlangt der Anwender einer derartigen Webbrowsers einen Vorteil, keinen neuen Leit-Key oder Set des erhaltenen Leit-Keys zu erhalten.
  • Selbst wenn der Leit-Key in dem Anwenderterminalapparat nicht vorinstalliert ist, ist es wahrscheinlicher, dass der Anwender zustimmen würde, den Leit-Key einzustellen, wenn der Leit-Key der einer hochvertrauenswürdigen Mittlerorganisationen ist. Weiter können durch Erhalten des Leit-Keys Apparate, die ein eigenes Public Key-Zertifikat aufweisen, das durch dieselbe Mittlerorganisation ausgegeben wurde, eine Authentifizierung unabhängig von Hersteller oder Verkäufer des Apparates, ausführen. Daher ist die Verwendung eines eigenen Public Key-Zertifikates, das durch eine Mittlerorganisation ausgegeben wird, effektiv in der Verbindung zu einem Apparat eines anderen Herstellers und ist in der Nachfrage nicht nur der Herstellung der Kommunikations- bzw. Datenübertragungsapparate hoch, sondern ebenfalls von Anwendern der Kommunikations- bzw. Datenübertragungsapparate.
  • Um diese Vertrauenswürdigkeit von Public Key-Zertifikaten zu verbessern, stellen die Mittlerorganisationen einen Validitätsterm zu ihren ausgegebenen Public Key-Zertifikaten ein. Obwohl die Public Key-Zertifikate typischerweise mit einem Term von mehreren Jahren eingestellt werden, werden einige Public Key-Zertifikate mit einer Kurzzeitdauer von 1 bis 3 Jahren eingestellt. Bei einer Authentifizierungsverarbeitung wird ein Public Key-Zertifikat, das einen ausgelaufenen Validitätsterm aufweist, als ein ungültiges Public Key-Zertifikat angesehen.
  • Ein Auslaufen bzw. Verfall der Validität des Public Key-Zertifikates muss kein signifikantes Problem in einem Fall sein, wo ein Anwender leicht den Validitätsterm des Public Key-Zertifikates erneuern kann, indem ein anderer Apparat verwendet wird (z. B. Personalcomputer). Jedoch könnte ein Umgang mit dem Verfallen des Validitätsterms eines Public Key-Zertifikates zum Beispiel ein Hindernis werden, in einem Fall, wo eine Erneuerung aufgrund der Kenntnisse oder der Umgebung des Anwenders schwierig ist, oder einem Fall, wo es nicht angezeigt ist, dass der Anwender das Public Key-Zertifikat frei erneuert (einstellt).
  • Genauer gesagt kann zum Beispiel in einem Fall, indem die Gültigkeitsdauer bzw. die Validierungsbenennung aufgrund eines Apparates ausläuft bzw. verfällt, der während des Auslaufens bzw. Verfallens der Gültigkeitsdauer bzw. Validierungsbenennung ausgeschaltet wird, das Public Key-Zertifikat nicht länger bei einer Authentifizierung verwendet werden, dadurch tritt ein Problem auf, dass ein neues Public Key-Zertifikat weder zuverlässig noch leicht erhalten werden kann. Dieses Problem kann ebenfalls in einem Fall eines Apparates auftreten, der ein vorinstalliertes Public Key-Zertifikat aufweist, in welchem der Apparat unversandt in einem Lager bleibt, bis zum Verfall der Gültigkeitsdauer bzw. Validierungsbenennung.
  • Dieses Problem könnten sogar in einem Fall auftreten, in welchem ein Verkäufer oder Hersteller ein Public Key-Zertifikat an einen Apparat ausgibt, insbesondere wenn eine Gültigkeitsdauer bzw. Validierungsbenennung aus Sicherheitsgründen verkürzt wird, und könnte in einem Fall auftreten, wo ein digitales Zertifikat anders als das Public Key-Zertifikat verwendet wird.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Es ist eine allgemeine Aufgabe der vorliegenden Erfindung, zwei Kommunikations- bzw. Datenübertragungsapparate bereitzustellen, die die Merkmale von jeweils den Ansprüchen 1 und 7 aufweisen, ein Kommunikations- bzw. Datenübertragungssystem, das die Merkmale von Anspruch 8 aufweist, ein Zertifikat-Übertragungsverfahren, das die Merkmale von Anspruch 16 aufweist, ein Programm, das die Merkmale von Anspruch 30 aufweist und ein Trägermedium, das die Merkmale von Anspruch 31 aufweist. Vorteilhafte Ausführungsformen hiervon werden in den entsprechenden abhängigen Ansprüchen definiert. Die vorliegende Erfindung richtet sich im Wesentlichen auf eines oder mehrere Probleme, die durch Beschränkungen und/oder Nachteile des Stands der Technik verursacht werden. Andere Aufgaben und weitere Merkmale der vorliegenden Erfindung werden aus der Folgenden detaillierten Beschreibung deutlich, wenn sie in Verbindung mit den begleitenden Zeichnungen gelesen wird.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1 ist ein Funktions-Blockdiagramm, das ein Kommunikations- bzw. Datenübertragungssystem zeigt, das einen Hoch-Niveau-Apparat und einen Niedrig-Niveau-Apparat aufweist, entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 2 ist ein Funktions-Blockdiagramm, das einen Zertifikat-Management-Apparat zeigt, der mit dem Hoch-Niveau-Apparat kommunizierbar ist, gezeigt in 1, entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 3 ist ein Blockdiagramm, das eine Hardwareanordnung des Zertifikat-Management-Apparates zeigt, der in 1 und 2 gezeigt ist, entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 4 ist eine Tabelle zum Erklären eines Kriteriums, das es eine Anforderung für ein Anforderungs-Managementteil des Niedrig-Niveau-Apparates zulässt, gezeigt in 1 und 2, entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 5A und 5B sind Diagramme, die Authentifizierungs-Informationen zeigen, die in dem Hoch-Niveau-Apparat und dem Niedrig-Niveau-Apparat gespeichert sind, der in 1 und 2 entsprechend einer Ausführungsform der vorliegenden Erfindung gezeigt ist;
  • 6 ist ein Diagramm, das Authentifizierungs-Informationen zeigt, die in dem Zertifikat-Management-Apparat gespeichert sind, der in 1 und 2 entsprechend einer Ausführungsform der vorliegenden Erfindung gezeigt ist;
  • 7 ist ein Diagramm, das ein Beispiel eines Formats eines normalen Public Key-Zertifikats entsprechend einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 8 ist ein Diagramm, das ein Beispiel eines typischen Public Key-Zertifikates zeigt, das entsprechend des Formats erzeugt wird, das in 7 entsprechend einer Ausführungsform der vorliegenden Erfindung gezeigt ist;
  • 9 ist ein Diagramm, das ein Beispiel eines anderen Public Key-Zertifikats zum Vergleichen mit einem Rescue Public Key- bzw. Rettungs-Public Key entsprechend einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 10 ist ein Diagramm, das ein Beispiel eines Rescue Public Key bzw. Rettungs-Public Key- zum Vergleichen mit einem normalen Public Key-Zertifikat entsprechend einer Ausführungsform der vorliegenden Erfindung zeigt;
  • 11 ist ein Diagramm zum Erklären des Hoch-Niveau-Apparats, der in 1 und 2 gezeigt ist, wobei ein normales Public Key-Zertifikat und ein Rescue Public Key- bzw. Rettungs-Public Key-Zertifikat entsprechend einer Ausführungsform der vorliegenden Erfindung verwendet wird;
  • 12 ist ein Diagramm, das ein Beispiel eines Zertifikatsets zeigt, das von dem Hoch-Niveau-Apparat zu dem Niedrig-Niveau-Apparat übertragen wird, wobei die normalen Authentifizierungs-Informationen eines Niedrig-Niveau-Apparates in einem Kommunikations- bzw. Datenübertragungssystem aktualisiert werden, gezeigt in 1 und 2, entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 13 ist ein Flussdiagramm, das einen exemplarischen Prozess zeigt, der durch einen Hoch-Niveau-Apparat eines Kommunikations- bzw. Datenübertragungssystems in einem Fall der Aktualisierung eines Zertifikats ausgeführt wird, wobei ein normales Public Key-Zertifikat und ein Rescue Public Key- bzw. Rettungs-Public Key-Zertifikat entsprechend einer Ausführungsform der Erfindung verwendet wird;
  • 14 ist ein Flussdiagramm, das einen exemplarischen Prozess zeigt, der durch einen Niedrig-Niveau-Apparat eines Kommunikations- bzw. Datenübertragungssystems in einem Fall der Aktualisierung eines Zertifikats ausgeführt wird, wobei ein normales Public Key-Zertifikat und ein Rescue Public Key- bzw. Rettungs-Public Key-Zertifikat entsprechend einer Ausführungsform der vorliegenden Erfindung verwendet wird;
  • 15 ist ein Diagramm, das eine exemplarische Folgeoperation in einem Fall der Ausführung des Prozesses zeigt, der in 13 und 14 mit einem Kommunikations- bzw.
  • Datenübertragungssystem entsprechend einer Ausführungsform der vorliegenden Erfindung gezeigt ist;
  • 16 ist eine Fortsetzung des Diagramms, das in 15 gezeigt ist;
  • 17 ist ein Diagramm, das eine exemplarische Folgeoperation in einem Fall eines Hoch-Niveau-Apparates zeigt, der seine eigenen normalen Authentifizierungs-Informationen in einem Kommunikations- bzw. Datenübertragungssystem entsprechend einer Ausführungsform der vorliegenden Erfindung aktualisiert;
  • 18 ist ein Diagramm, das eine Variation der Folgeoperation zeigt, die in 15 gezeigt ist, entsprechend einer Ausführungsform der vorliegenden Erfindung;
  • 19 ist ein Diagramm, das eine andere Variation der Folgeoperation zeigt, die in 15 entsprechend einer Ausführungsform der vorliegenden Erfindung gezeigt ist;
  • 20 ist ein Diagramm, das eine noch andere Variation der Folgeoperation zeigt, die in 15 entsprechend einer Ausführungsform der vorliegenden Erfindung gezeigt ist;
  • 21 ist ein Diagramm, das vielfache Niedrig-Niveau-Apparate zeigt, die in einem Kommunikations- bzw. Datenübertragungssystem entsprechend einer Ausführungsform der vorliegenden Erfindung bereitgestellt werden;
  • 22 ist ein Flussdiagramm, das einen Prozess und Informationen zeigt, die übertragen werden, wenn eine Zwei-Wege-Authentifizierung zwischen zwei Kommunikations- bzw. Datenübertragungsapparaten in Übereinstimmung mit SSL entsprechend einer Ausführungsform der vorliegenden Erfindung ausgeführt wird;
  • 23A und 23B sind Diagramme zum Erklären einer Beziehung zwischen einem Root-Key, einem eigenen Root-Key und einem Public Key-Zertifikat, das in der Authentifizierungsverarbeitung verwendet wird, der in 22 entsprechend einer Ausführungsform der vorliegenden Erfindung gezeigt ist; und
  • 24 ist ein Flussdiagramm entsprechend zu 22, welches einen Prozess und Informationen zeigt, die übertragen werden, wenn eine Ein-Wege-Authentifizierung zwischen zwei Kommunikations- bzw. Datenübertragungsapparaten in Übereinstimmung mit SSL entsprechend einer Ausführungsform der vorliegenden Erfindung ausgeführt wird.
  • BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
  • Im Folgenden werden Ausführungsformen der vorliegenden Erfindung im Detail mit Bezug auf die begleitenden Zeichnungen beschrieben.
  • Zuerst werden ein Kommunikations- bzw. Datenübertragungsapparat und ein Kommunikations- bzw. Datenübertragungssystem, das den Kommunikations- bzw. Datenübertragungsapparat entsprechend einer ersten Ausführungsform der vorliegenden Erfindung verwendet, beschrieben. Ein Kommunikations- bzw. Datenübertragungssystem 100 entsprechend der ersten Ausführungsform der vorliegenden Erfindung weist einen Hoch-Niveau-Apparat (zweiter Kommunikations- bzw. Datenübertragungsapparat) 30 auf und einen Niedrig-Niveau-Apparat (erster Kommunikations- bzw. Datenübertragungsapparat) 40. Das Kommunikations- bzw. Datenübertragungssystem 100 ermöglicht eine Kommunikation zwischen dem Hoch-Niveau-Apparat 30 und einem Zertifikat-Management-Apparat 20 über ein Netzwerk zum Bereitstellen eines digitalen Zertifikat-Management-System zwischen einem Kommunikations- bzw. Datenübertragungssystem und einem Zertifikat-Management-System. 1 ist ein Blockdiagramm zum Beschreiben von Funktionen (Funktionsteile) des Hoch-Niveau-Apparates 30 und des Niedrig-Niveau-Apparates 40 und 2 ist ein Blockdiagramm zum Beschreiben von Funktionen (Funktionsteilen) des Zertifikat-Management-Apparates 20. In 1–3 werden Teile, die keine bestimmte Beziehung zu den Merkmalen dieser Ausführungsform haben, weggelassen. Man sollte beachten, dass in dieser Beschreibung der vorliegenden Anwendung der Term „digitales Zertifikat" sich auf digitale Daten bezieht, die eine Unterschrift aufweisen, die hieran angehängt ist, um eine Fälschung zu verhindern.
  • Entsprechend zu dem Kommunikations- bzw. Datenübertragungssystem 100 wird in einem Fall, in dem der Hoch-Niveau-Apparat 30 versucht, eine Verbindung mit dem Niedrig-Niveau-Apparat 40 einzurichten, die Verbindung zwischen dem Niedrig-Niveau-Apparat 40 eingerichtet, wenn der Niedrig-Niveau-Apparat 40 als ein authentisches Kommunikations-Gegenüber verifiziert wurde, indem ein Authentifizierungs-Verfahren verwendet wird, das einen Public Key-Code(s) und ein digitales Zertifikat(e) in Übereinstimmung mit einem SSL-Protokoll bzw. Zertifikat verwendet. Hier arbeitet das Kommunikations- bzw. Datenübertragungssystem 100 als ein Client-Server-System, wo der Niedrig-Niveau-Apparat 40 einen erforderlichen Prozess ausführt und als Antwort auf eine Anforderung, die von dem Hoch-Niveau-Apparat 30 übertragen wurde, antwortet.
  • Andererseits wird in einem Fall, wo der Niedrig-Niveau-Apparat 40 versucht, eine Verbindung mit dem Hoch-Niveau-Apparat 30 aufzubauen, die Verbindung mit dem Hoch-Niveau-Apparat 30 eingerichtet, wenn der Hoch-Niveau-Apparat 30 als ein authentisches Kommunikations-Gegenüber verifiziert wird, ebenfalls, indem ein Authentifizierungs- Verfahren verwendet wird, das einen Public Key-Code(s) und ein digitales Zertifikat(e) in Übereinstimmung mit einem SSL-Protokoll bzw. Zertifikat verwendet. Hier arbeitet das Kommunikations- bzw. Datenübertragungssystem 100 als ein Client-Server-System, wo der Hoch-Niveau-Apparat 30 einen erforderlichen Prozess ausführt und als Antwort auf eine Anforderung, die von dem Hoch-Niveau-Apparat 40 übertragen wird, antwortet.
  • In beiden der obigen Fälle entspricht der Apparat, der eine Verbindung (Kommunikation) anfordert, dem Client, und der andere Apparat, der die Anforderung empfängt, entspricht dem Server.
  • Der Zertifikat-Management-Apparat 20, welcher ein Apparat ist, der digitale Zertifikate ausgibt und anfragt, indem die oben beschriebene Zwei-Wege-Authentifizierung verwendet wird, entspricht einem CA (Certificate Authority).
  • Es sollte beachtet werden, dass obwohl ein einzelner Niedrig-Niveau-Apparat 40 in 1 und 2 veranschaulicht ist, mehrere Niedrig-Niveau-Apparate 40 alternativ eingesetzt werden können. Weiter kann, obwohl ein einzelnes Kommunikation- bzw. Datenübertragungssystem 100 einen einzelnen Hoch-Niveau-Apparat 30 umfasst, mehrere Hoch-Niveau-Apparate 30 alternativ innerhalb eines Zertifikat-Management-Systems bereitgestellt werden, als ein Ergebnis, um es einem einzelnen Zertifikat-Management-System 20 möglich zu machen, mit mehreren Kommunikations- bzw. Datenübertragungssystemen 100 zu kommunizieren.
  • Bei dem Kommunikations- bzw. Datenübertragungssystem 100 ist jedem Knoten des Zertifikat-Management-Apparates 20, dem Hoch-Niveau-Apparat 30 und dem Niedrig-Niveau-Apparat 40 (einschließlich einer Verbindung zwischen dem Hoch-Niveau-Apparat und dem Niedrig-Niveau-Apparat 40) in Übereinstimmung mit RPC (Remote Procedure Call) erlaubt, eine „Anforderung" zu übertragen, die eine Ausführung eines Prozesses entsprechend eines Verfahrens in einem Anwendungsprogramm ausführt, das in einem Gegenüber-Apparat installiert ist, und eine „Antwort" zu erhalten, die aus der Ausführung des angeforderten Prozesses resultiert.
  • Um das RPC zu erreichen, können bekannte Protokolle bzw. Zertifikate, Technologien und Spezifikationen eingesetzt werden, zum Beispiel SOAP (Simple Object Access Protocol), HTTP (Hyper Text Transfer Protocol), FTP (File Transfer Protocol), COM (Component Object Model) und/oder CORBA (Common Object Request Broker Architecture).
  • Als Nächstes werden entsprechende Apparate und Teile, die in dem Kommunikations- bzw. Datenübertragungssystem 100 enthalten sind, im weiteren Detail beschrieben.
  • 3 ist ein Blockdiagramm, das eine Hardwarekonfiguration des Zertifikat-Management-Apparates 20 zeigt, der in 2 gezeigt ist. Wie in 3 gezeigt, umfasst der Zertifikat-Management-Apparat 20 eine CPU 11, ein ROM 12, ein RAM 13, ein HDD 14 und eine Kommunikationsschnittstelle (I/F) 15, in welcher die Komponenten mit einem System-Bus 16 verbunden sind. Die CPU 11 führt verschiedene Steuerungsprogramme aus, die in dem ROM 12 und dem HDD 14 gespeichert sind, um Operation des Zertifikat-Management-Apparates 20 zu steuern, zum Beispiel Ausgeben und/oder Handhaben von digitalen Zertifikaten.
  • Es sollte beachtet werden, dass ein typischer Computer als die Hardware des Zertifikat-Management-Apparates 20 eingesetzt werden kann und zusätzliche Hardware hierzu hinzugefügt werden muss.
  • Weiter können verschiedene Konfigurationen auf dem Hoch-Niveau-Apparat 30 und dem Niedrig-Niveau-Apparat 40 entsprechend dem Zweck angewendet werden (z. B. entferntes Management, E-Commerce). Zum Beispiel kann in dem Fall eines entfernten Managements der Niedrig-Niveau-Apparat 40, der ein Ziel-Management-Apparat ist, zum Beispiel ein Bildverarbeitungsapparat sein (z. B. ein Drucker, ein Faxgerät, ein Kopierer, ein Scanner, ein digitaler Computer) und/oder elektronische Apparate, die ein Haushaltsgeräte-Netzwerk umfassen, ein automatischer Verkaufsapparat, ein medizinischer Apparat, ein Stromerzeugungsapparat, ein Klimaanlagensystem, ein Messsystem (z. B. Gas, Wasser, Strom), ein Auto, ein Flugzeug, in welchem der Hoch-Niveau-Apparat 30 Informationen von dem Zertifikat-Management-Apparat sammeln kann und Befehle übertragen kann, um verschiedene Operationen zu erreichen.
  • Sowohl der Hoch-Niveau-Apparat 30 als auch der Niedrig-Niveau-Apparat 40 weisen eine Kommunikationsschnittstelle (I/F) zum Kommunizieren mit einem externen Apparat über wenigstens eine CPU, ein ROM, ein RAM und/oder ein Netzwerk und eine Speichereinheit auf, um Informationen zu speichern, die für die Authentifizierung notwendig sind. Bei Verwenden der CPU, um ein vorgeschriebenes Steuerungsprogramm(e) auszuführen, das bzw. die in dem ROM oder Ähnlichem gespeichert sind, können die Merkmals-Funktionen entsprechend einer Ausführungsform der vorliegenden Erfindung mit einem Apparat entsprechend einer Ausführungsform der vorliegenden Erfindung erzielt werden.
  • Bei dieser Kommunikation bzw. Datenübertragung können verschiedene Kommunikations- bzw. Datenübertragungsleitungen (Kommunikationswege) zum Aufbau eines Netzwerks entsprechend einer Ausführungsform der vorliegenden Erfindung eingesetzt werden, bei der das Netzwerk drahtgebunden und/oder drahtlos sein kann.
  • 1 zeigt Merkmale von Teilen, die den oben beschriebenen Hoch-Niveau-Apparat 30 und den Niedrig-Niveau-Apparat 40 zusammensetzen.
  • Der Hoch-Niveau-Apparat 30 umfasst ein HTTPS(Hypertext Transfer Protocol Security)-Client-Funktionsteil 31, ein HTTPS-Server-Funktionsteil 32 und ein Authentifizierungsverarbeitungsteil 33, ein Zertifikat-Aktualisierungs-Anforderungsteil 34 und ein Zertifikat-Speicherteil 35.
  • Das HTTPS-Client-Funktionsteil 31 verwendet ein HTTPS-Protokoll bzw. Zertifikat (einschließlich einer Authentifizierungsverarbeitung und einer Verschlüsselungsverarbeitung entsprechend SSL), um eine Kommunikation bzw. Datenübertragung mit einem Apparat anzufordern, der eine HTTPS-Server-Funktion aufweist, wie zum Beispiel der Niedrig-Niveau-Apparat 40. Außerdem weist das HTTPS-Client-Funktionsteil 31 eine Funktion zum Übertragen einer Anforderung (Befehl) und/oder Daten an ein Kommunikations-Gegenüber auf und versetzt das Kommunikations-Gegenüber in die Lage, eine Operation in Übereinstimmung mit der übertragenen Anforderung und/oder den Daten auszuführen.
  • Das HTTPS-Server-Funktionsteil 32 empfängt (akzeptiert) eine Kommunikationsanforderung, wobei ein HTTP-Protokoll bzw. Zertifikat von einem Apparat verwendet wird, der eine HTTPS-Client-Funktion aufweist, um es dabei entsprechenden Teilen eines Apparates zu ermöglichen, eine Operation als Antwort auf die Anforderung und/oder die Daten auszuführen, die von dem Apparat empfangen werden, der die HTTPS-Client-Funktion aufweist, und das Ergebnis der Operation an die ursprüngliche Anforderung zurückzugeben.
  • Das Authentifizierungsverarbeitungsteil 33 führt eine Funktion einer Authentisierungseinheit aus, in welcher das Authentifizierungsverarbeitungsteil eine Authentifizierungsverarbeitung ausführt, wenn das HTTPS-Client-Funktionsteil 31 oder das HTTPS-Server-Funktionsteil 32 einen Kommunikations-Gegenüber authentifiziert, indem ein digitales Zertifikat, das von dem Kommunikations-Gegenüber empfangen wird, verwendet wird und/oder durch die Verwendung verschiedener Zertifikate, eigene Keys, etc., die in dem Zertifikat-Speicherteil 35 gespeichert sind. Das Authentifizierungsverarbeitungsteil 33 weist ebenfalls eine Funktion zum Übertragen eines digitalen Zertifikates auf, das in dem Zertifikat-Speicherteil 35 über das HTTPS-Client-Funktionsteil 31 und/oder das HTTPS-Server-Funktionsteil 32 zu übertragen, um eine Authentifizierung des Kommunikation-Gegenübers anzufordern.
  • Das Zertifikat-Aktualisierungs-Anforderungsteil 34 weist eine Zertifikat-Übertragungseinheit zum Übertragen eines normalen Public Key an ein Kommunikations-Gegenüber auf (z. B. Niedrig-Niveau-Apparat) in einem vorbestimmten Fall und eine Zertifikat-Aktualisierungseinheit, um eine Speicherung der Übertragung anzufordern.
  • Das Zertifikat-Speicherteil 35 weist Funktionen zum Speichern von Authentifizierungs-Informationen, wie zum Beispiel verschiedenen Zertifikaten und eigenen Keys auf und ein Unterstützen der Authentifizierungsverarbeitung des Authentifizierungsverarbeitungsteils 33. Die Typen, Verwendungen und Erzeugungsverfahren in Bezug auf die Zertifikate und eigene Key werden unten in größerem Detail beschrieben.
  • Die Funktionen von jedem der oben beschriebenen Teile werden ausgeführt, indem die CPU des Hoch-Niveau-Apparats 30 in die Lage versetzt wird, ein vorbestimmtes Steuerungsprogramm(e) auszuführen, um dadurch den Betrieb der entsprechenden Teile des Hoch-Niveau-Apparates 30 zu steuern.
  • In der Zwischenzeit umfasst der Niedrig-Niveau-Apparat 40 ein HTTPS-Client-Funktionsteil 41, ein HTTPS-Server-Funktionsteil 42, ein Authentifizierungs-Verarbeitungsteil 43, ein Anforderungs-Managementteil 44, ein Zertifikat-Speicherteil 45, ein Status-Benachrichtigungsteil 46, ein Protokoll-Benachrichtigungsteil 47, ein Zertifikat-Aktualisierungsteil 48 und ein Befehls-Empfangsteil 49.
  • Ähnlich zu dem HTTPS-Client-Funktionsteil 31 des Hoch-Niveau-Apparates 30 verwendet das HTTPS-Client-Funktionsteil 41 ein HTTPS-Protokoll bzw. Zertifikat (einschließlich einer Authentifizierungs-Verarbeitung und einer VerKeyungsverarbeitung entsprechend SSL), um eine Kommunikation mit einem Apparat anzufordern, der eine HTTPS-Server-Funktion aufweist, wie zum Beispiel den Hoch-Niveau-Apparat 30. Außerdem weist das HTTPS-Client-Funktionsteil 41 ebenfalls eine Funktion zum Übertragen einer Anforderung (Befehl) und/oder Daten an ein Kommunikations-Gegenüber auf und versetzt das Kommunikations-Gegenüber in die Lage, eine Operation in Übereinstimmung mit der übertragenen Anforderung und/oder den Daten auszuführen.
  • Ähnlich zu dem HTTPS-Server-Funktionsteil 32 des Hoch-Niveau-Apparates 30 empfangt (akzeptiert) das HTTPS-Server-Funktionsteil 42 eine Kommunikationsanforderung, die ein HTTP-Protokoll bzw. Zertifikat von einem Apparat empfängt, der eine HTTPS-Client-Funktion aufweist, um es dadurch jeweiligen Teilen eines Apparates zu ermöglichen, eine Operation als Antwort auf die Anforderung und/oder die Daten auszuführen, die von dem Apparat empfangen wurden, der die HTTPS-Client-Funktion aufweist, und das Ergebnis der Operation an den Ursprung der Anforderung zurückzugeben.
  • Ähnlich zu dem Authentifizierungs-Verarbeitungsteil 33 des Hoch-Niveau-Apparates 30 führt das Authentifizierungs-Verarbeitungsteil 43 eine Funktion einer Authentifizierungseinheit aus, in welcher das Authentifizierungs-Verarbeitungsteil eine Authentifizierungs-Verarbeitung ausführt, wenn das HTTPS-Client-Funktionsteil 41 oder das HTTPS-Server-Funktionsteil 42 ein Kommunikations-Gegenüber authentifiziert, indem ein digitales Zertifikat verwendet wird, das von dem Kommunikations-Gegenüber empfangen wird und/oder indem verschiedene Zertifikate (eigene Key, etc.) empfangen werden. Hier jedoch werden verschiedene Zertifikate und Ähnliches, die bei der Authentifizierungs-Verarbeitung verwendet werden, in dem Zertifikat-Speicherteil 45 gespeichert.
  • Das Anforderungs-Managementteil44 bestimmt, ob eine Operation(en), die einer Anforderung entspricht, die von dem Hoch-Niveau-Apparat 30 empfangen wird, ausgeführt werden kann. Wenn die Ausführung der Anforderung erlaubt ist, stellt das Anforderungs-Managementteil 44 die Anforderung den Funktionsteilen 46–49 bereit, die dazu dienen, die Operation in Übereinstimmung mit der Anforderung auszuführen.
  • 4 zeigt ein Kriterium zum Bestimmen einer Ausführung der Operation. Das Kriterium basiert auf dem Typ der Anforderung und dem Typ von digitalem Zertifikat, das bei der Authentifizierungs-Verarbeitung durch das Authentifizierungs-Verarbeitungsteil 43 verwendet wird. Sowohl der Hoch-Niveau-Apparat 30 als auch der Niedrig-Niveau-Apparat 40 umfassen ein normales Public Key-Zertifikat, welches ein Kurzzeit(Public Key)-Zertifikat ist, das mit einer Gültigkeitsdauer bzw. Validierungsbenennung eingestellt wird, die kürzer ist als ein Langzeit-Zertifikat, und einen Rescue Public Key- bzw. Rettungs-Public Key, welcher ein Langzeit(Public Key)-Zertifikat ist, das mit einer gewünschten Gültigkeitsdauer bzw. Validierungsbenennung eingestellt wird, die langer ist als das Kurzzeit-Zertifikat. Wie in 4 gezeigt, ermöglicht das Anforderungs-Managementteil44 alle Operationen, wenn eine Authentifizierung mit dem normalen Public Key-Zertifikat ausgeführt wird, und ermöglicht nur eine Zertifikat-Aktualisierungs-Operation, wenn eine Authentifizierung mit dem Rescue Public Key- bzw. Rettungs-Public Key ausgeführt wird. Es ist zu beachten, dass nur das normale Public Key-Zertifikat Gegenstand der Zertifikats-Aktualisierungsoperation ist und der Rescue Public Key- bzw. Rettungs-Public Key nicht Gegenstand der Zertifizierung-Aktualisierungs-Operation ist. Daher ist das Rescue Public Key-Zertifikat, welches nur in einem Fall des Speicherns eines neuen normalen Public Key-Zertifikates (und eines eigenen Keys und eines Root-Key-Zertifikat, das dem neuen normalen Public Key-Zertifikat untergeordnet ist) verwendet wird.
  • Ähnlich zu dem Zertifikat-Speicherteil 35 des Hoch-Niveau-Apparats 30 weist das Zertifikat-Speicherteil 45 ebenfalls eine Funktion des Speicherns von Authentifizierungs-Informationen, wie zum Beispiel verschiedenen Zertifikaten und eigenen Keys auf und eine Unterstützung der Authentifizierungs-Verarbeitung des Authentifizierungs-Verarbeitungsteils 43. Es ist jedoch zu beachten, dass die Zertifikate und Ähnliches, die im Zertifikat-Speicherteil 45 gespeichert sind, unterschiedlich von solchen sind, die in dem speichert 35 gespeichert sind. Das Status-Benachrichtigungsteil 46 weist eine Funktion der Bereitstellung (Benachrichtigung) des Status des Niedrig-Niveau-Apparates 40 an den Hoch-Niveau-Apparat 30 für einen Fall auf, wo zum Beispiel eine Abnormalität detektiert wird oder ein Befehl durch den Anwender ausgegeben wird. Diese Benachrichtigung kann als Antwort auf eine Suche von dem Hoch-Niveau-Apparat 30 übertragen werden oder nach einer Kommunikationsanforderung von dem HTTPS-Client-Funktionsteil 41 an den Hoch-Niveau-Apparat 30 übertragen werden.
  • Protokoll-Benachrichtigungsteil 47 weist eine Funktion des Berichtens (Benachrichtigen) eines Protokolls bzw. Zertifikats zwischen dem Niedrig-Niveau-Apparat 40 und dem Hoch-Niveau-Apparat 30 auf (z. B. ein Protokoll bzw. Zertifikat von dem Niedrig-Niveau-Apparat an den Hoch-Niveau-Apparat 30). Anders als ein Operations-Protokoll bzw. Zertifikat des Niedrig-Niveau-Apparates 40 können die Inhalte des benachrichtigten Protokolls bzw. Zertifikats zum Beispiel einen Zählwert enthalten, der von einem Bilderzeugungs-Anzahlzähler eines Bilderzeugungsapparates oder eines Messwertes eines Messsystems erhalten wird. Da es nicht erforderlich ist, dass diese Benachrichtigung sofort verwendet wird, kann die Benachrichtigung als Antwort auf eine Suche von dem Hoch-Niveau-Apparat 30 übertragen werden.
  • Das Zertifikat-Aktualisierungsteil 48 weist eine Funktion des Aktualisierens von Zertifikaten und Ähnlichem auf, die in dem Zertifikat-Speicherteil 45 in Übereinstimmung mit den Zertifikaten und Ähnlichem gespeichert sind, die von dem Hoch-Niveau-Apparat 30 empfangen werden.
  • Das Befehls-Empfangsteil 49 weist eine Funktion zum Ausführen einer Operation(en) entsprechend einer Anforderung(en) einer anderen Funktion(en) als den Funktionen der jeweiligen Funktionsteile 46–48 auf. Die Operation kann zum Beispiel das Übertragen von Daten enthalten, die in dem Niedrig-Niveau-Apparat 40 gespeichert sind und/oder eine Steuerungsoperation eines Maschinenteils (nicht gezeigt).
  • Die Funktionen von jedem der oben beschriebenen Teile werden ausgeführt, indem es der CPU des Niedrig-Niveau-Apparates 40 ermöglicht wird, ein vorgeschriebenes Steuerungsprogramm(e) auszuführen, um dadurch die Operation der entsprechende Teile des Niedrig-Niveau-Apparates 40 zu steuern. Es ist zu beachten, dass die Funktionen des Status-Benachrichtigungsteils 46 oder des Protokoll-Benachrichtigungsteils 47 als Beispiel für Funktionen gegeben werden, die durch das Befehls-Empfangsteil 49 bereitgestellt wird, und Funktionen sind, die ausgeschlossen werden können.
  • 2 ist ein Blockdiagramm zum Beschreiben von Funktionen (Funktionsteilen) des Zertifikat-Management-Apparats 20 entsprechend einer Ausführungsform der vorliegenden Erfindung.
  • Der Zertifikat-Management-Apparat 20 umfasst ein HTTPS-Server-Funktionsteil 21, ein Authentifizierungs-Verarbeitungsteil 22, ein Zertifikat-Aktualisierungsteil 23, ein Aktualisierungs-Key-Erzeugungsteil 24, ein Zertifikat-Ausgabeteil 25 und ein Zertifikat-Managementteil 26.
  • Ähnlich wie solche des Hoch-Niveau-Apparates 30 und des Niedrig-Niveau-Apparates 40 empfängt (akzeptiert) das HTTPS-Server-Funktionsteil 21 eine Kommunikationsanforderung von einem Apparat, der eine HTTPS-Client-Funktion aufweist, um es dadurch entsprechenden Teilen eines Apparates zu ermöglichen, eine Operation als Antwort auf die Anforderung und/oder den Daten auszuführen, die von dem Apparat empfangen wurden, der die HTTPS-Client-Funktion aufweist und das Ergebnis der Operation am Ursprung der Anforderung zurückzugeben.
  • Weiter weist das Authentifizierungs-Verarbeitungsteil22 eine Funktion ähnlich zu solcher des Hoch-Niveau-Apparates 30 und des Niedrig-Niveau-Apparates 40 auf. Hier jedoch werden verschiedene Zertifikate und Ähnliches, die bei der Authentifizierungs-Verarbeitung verwendet werden, in dem Zertifikat-Managementteil 26 gespeichert. Die Typen, Verwendungen und Erzeugungsverfahren in Bezug auf die verschiedenen Zertifikate und Ähnliches werden detaillierter unten beschrieben.
  • Das Zertifikat-Aktualisierungsteil 23 weist eine Funktion auf, die es dem Aktualisierungs-Key-Erzeugungsteil 24 oder dem Zertifikat-Ausgabeteil 25 ermöglicht, ein neues normales Public Key-Zertifikat eines Ziel eines Niedrig-Niveau-Apparates 40 auszugeben und es dem Zertifikat-Managementteil 26 zu ermöglichen, das ausgegebene neue normale Public Key-Zertifikat zu dem Hoch-Niveau-Apparat über das HTTPS-Server-Funktionsteil 21 zu übertragen.
  • Das Aktualisierungs-Key-Erzeugungsteil 24 weist eine Funktion einer Aktualisierungs-Key-Erzeugungseinheit auf, in welcher das Aktualisierungs-Key-Erzeugungsteil 24 einen eigenen Root-Key erzeugt, der als eigener Authentifizierungs-Key dient, der zum Erstellen einer digitalen Unterschrift verwendet wird, und einen Public-Authentifizierungs-Key (Authentifizierungs-Key), entsprechend zu dem eigenen Root Key zum Verifizieren der Authentizität des digitalen Zertifikats der digitalen Unterschrift.
  • Das Zertifikat-Ausgabeteil 25 weist eine Funktion des Ausgebens eines Public Keys auf, der bei der Authentifizierungs-Verarbeitung entsprechend des SSL-Protokolls bzw. Zertifikats durch den Zertifikat-Management-Apparat 20 selbst verwendet wird, den Hoch-Niveau-Apparat 30 und den Niedrig-Niveau-Apparat 40 und eigene Keys entsprechend dem Public Key ausgibt. Außerdem weist das Zertifikat-Ausgabeteil 25 eine Funktion einer Zertifikat-Ausgabeeinheit auf, in welcher das Zertifikat-Ausgabeteil 25 eine digitale Unterschrift an die ausgegebenen Public Keys anhängt, indem der Root Private Key, der durch das Aktualisierungs-Key-Erzeugungsteil 24 gemacht wird, verwendet wird, und ein Public Key-Zertifikat ausgibt (d. h. ein digitales Zertifikat). Weiter weist das Zertifikat-Ausgabeteil 25 eine Funktion des Ausgebens eines Root Key-Zertifikates auf, das eine digitale Unterschrift aufweist, die an einem Root Key angehängt ist.
  • Das Zertifikat-Managementteil 26 weist eine Funktion einer Zertifikat-Managementeinheit auf, in welcher das Zertifikat-Managementteil 26 die digitalen Zertifikate handhabt, die von dem Zertifikat-Ausgabeteil 25 ausgegeben werden, die eigenen Root Keys, die beim Herstellen der digitalen Zertifikate verwendet werden, und die Root Keys, die den eigenen Root Keys entsprechen. Außerdem werden die Zertifikate und Keys in Übereinstimmung mit Informationen, wie zum Beispiel einer Gültigkeitsdauer bzw. Validierungsbenennung, Ausgabeziel, ID und/oder Aktualisierungshistorie gespeichert (gehandhabt) werden. Das Zertifikat-Managementteil 26 weist ebenfalls eine Funktion zur Unterstützung der Authentifizierungsverarbeitung des Authentifizierungsverarbeitungsteils 22 auf, und zwar hinsichtlich der Zertifikate und eigenen Keys, die an ihn ausgegeben werden.
  • Die Funktionen von jedem der oben beschriebenen Teile werden ausgeführt, indem die CPU des Zertifikat-Management-Apparates 20 in die Lage versetzt wird, ein vorgeschriebenes Steuerungsprogramm(e) auszuführen, um dadurch die Operation der jeweiligen Teile des Zertifikat-Management-Apparates 20 zu steuern.
  • Als Nächstes werden die Merkmale, Verwendungen, etc. der Zertifikate und der Keys beschrieben, die in den oben beschriebenen Apparaten verwendet werden. 5A ist ein Diagramm, das die Typen von Zertifikaten und Keys zeigt, die in dem Zertifikat-Speicherteil 75 des Niedrig-Niveau-Apparates 40 gespeichert sind und 5B ist ein Diagramm, das die Typen von Zertifikaten und Keys zeigt, die in dem Zertifikat-Speicherteil 35 des Niedrig-Niveau-Apparates 30 gespeichert sind. Unter den Zertifikaten und Keys, die in dem Zertifikat-Managementteil 26 des Zertifikat-Management-Apparates 20 gespeichert sind, sind die Zertifikate und Keys, die in der Authentifizierungsverarbeitung des Zertifikat-Management-Apparates 20 verwendet werden, in 6 gezeigt.
  • Die Informationen, die in dem Hoch-Niveau-Apparat 40 gespeichert sind, und der Zertifikat-Management-Apparat 20 können die Informationen, die in dem Hoch-Niveau-Apparat 30, der Niedrig-Niveau-Apparat 40 und dem Zertifikat-Management-Apparat 20 gespeichert sind, weitestgehend in normale Authentifizierungs-Informationen und Rescue- bzw. Rettungs-Authentifizierungs-Informationen kategorisiert werden. Sowohl die normalen Authentifizierungs-Informationen als auch die Rescue- bzw. Rettungs-Authentifizierungs-Informationen sind aus Authentifizierungs-Informationen bezüglich sich selbst wie bezüglich Public Key-Zertifikat-Informationen und normalen Key-Informationen zusammengesetzt und Authentifizierungs-Informationen bezüglich dem Kommunikations-Gegenüber, wie zum Beispiel Root Key-Zertifikat-Informationen.
  • Entsprechend führen in einem Fall von normaler Kommunikation jeder der oben beschriebenen Apparate eine Zwei-Wege-Authentifizierung aus (wie in 2 gezeigt) oder ein Ein-Weg-Authentifizierung (wie in 24 gezeigt), wobei die normale Authentifizierungs-Informationen entsprechend SSL verwendet werden.
  • Zum Beispiel ist ein normales Public Key-Zertifikat eines Niedrig-Niveau-Apparates ein digitales Zertifikat, das eine digitale Unterschrift aufweist, die an einen normalen Public Key angehängt ist, der durch den Zertifikat-Management-Apparat 20 für den Niedrig-Niveau-Apparat 40 ausgegeben wird, in welchem es die digitale Unterschrift ermöglicht, ihre Authentifizierung mit einem normalen Root Key eines Niedrig-Niveau-Apparat-Authentifizierung zu verifizieren. Das normale Public Key-Zertifikat des Niedrig-Niveau-Apparates ist ein Zertifikat entsprechend eines Kurzzeit-Zertifikates.
  • 7 zeigt ein Beispiel eines Formates eines Public Key-Zertifikates. Das Format kann nicht nur Informationen des Public Keys selbst enthalten, sondern kann ebenfalls Informationen, wie zum Beispiel Ausgeber des Zertifikates, die Gültigkeit bzw. Validierung des Zertifikates und/oder den Gegenstand der Verifikation (z. B. einen Apparat eines Zertifikat-Ausgabeziels oder Anwender von derartigen Apparaten) enthalten. Insbesondere kann das Public Key-Zertifikat in Übereinstimmung mit einem Format gemacht werden, das als das X.509-Format bezeichnet wird. 8 zeigt ein Beispiel eines Public Key-Zertifikates, das in Übereinstimmung mit dem X.509-Format gemacht wurde.
  • In diesem Beispiel bezeichnet der Buchstabe A Identifikations-Informationen des CA und der Buchstabe bezeichnet Authentifizierungs-Informationen eines Apparates des Zertifikat-Ausgabeziels. Die Identifikations-Informationen können zum Beispiel eine Adresse, einen Namen, eine Apparatenummer oder einen Code enthalten. Der Buchstabe B bezeichnet eine Gültigkeitsdauer bzw. Validierungsbenennung, die ein Startdatum/-Zeit und ein Ende-Datum/-Zeit bezeichnet.
  • Weiter ist ein normaler Public Key eines Niedrig-Niveau-Apparates ein eigener Key, der dem oben beschriebenen normalen Public Key Niedrig-Niveau-Apparates entspricht, und ein normales Root Key-Zertifikat eines Niedrig-Niveau-Apparates ist ein digitales Zertifikat, das eine digitale Unterschrift aufweist, die an einen normalen Authentifizierungs-Root Key eines Niedrig-Niveau-Apparates angehängt wird, in welchem es die digitale Unterschrift ermöglicht, seine Authentizität mit einem eigenen Root Key, der ihm entspricht, zu verifizieren.
  • In einem Fall, wo mehrere Niedrig-Niveau-Apparate bereitgestellt werden, ist die digitale Unterschrift, die auf die normalen Public Keys der entsprechenden Apparate angewendet werden soll, angehängt, indem derselbe eigene Root Key verwendet wird, dadurch wird ein gemeinsames normales Root Key-Zertifikat verwendet. Der normale Public Key, der in dem normalen Public Key-Zertifikat enthalten ist, und der eigene Key, der dem Public Key entspricht, sind in Bezug auf jeden der Apparate unterschiedlich.
  • Die oben beschriebene Beziehung gilt für die eines normalen Public Key-Zertifikates eines Hoch-Niveau-Apparates, eines normalen eigenen Keys eines Hoch-Niveau-Apparates und eines normalen Root Key-Zertifikates eines Hoch-Niveau-Apparates; und ebenfalls der eines normale Public Key-Zertifikates eines CA, eines normalen Private Keys eines CA und eines normalen Authentifizierungs-Root Key-Zertifikates eines CA.
  • Entsprechend überträgt in einem beispielhaften Fall des Ausführens einer Zwei-Wege-Authentifizierung zwischen dem Hoch-Niveau-Apparat 30 und dem Niedrig-Niveau-Apparat 40 der Niedrig-Niveau-Apparat 40 zuerst eine erste Zufallszahl, die mit dem normalen Private Key des Niedrig-Niveau-Apparates verschlüsselt ist, zusammen mit dem normalen Public Key-Zertifikat des Niedrig-Niveau-Apparates zu dem Hoch-Niveau-Apparat 30 als Antwort auf eine Kommunikationsanforderung von dem Hoch-Niveau-Apparat 30. Der Hoch-Niveau-Apparat 30 verifiziert zuerst die Authentizität des normalen Public Key-Zertifikates des Niedrig-Niveau-Apparates (z. B. ob das Zertifikat beschädigt ist oder ob unerlaubte Änderungen vorgenommen wurden), indem das normale Root Key-Zertifikat des Niedrig-Niveau-Apparates verwendet wird und entschlüsselt die erste Zufallszahl mit dem Public Key in dem Public Key-Zertifikat, wenn das Public Key-Zertifikat als authentisch bestimmt wird. Wenn das Entschlüsseln erfolgreich ist, bestimmt der Hoch-Niveau-Apparat 30, dass der Niedrig-Niveau-Apparat 40 (Kommunikation-Gegenüber) in der Tat das ausgegebene Ziel des normale Public Key-Zertifikates des Niedrig-Niveau-Apparates ist und der Apparat kann aus Identifikations-Informationen identifiziert werden, die in dem normalen Public Key-Zertifikat des Niedrig-Niveau-Apparates enthalten sind. Der Erfolg der Authentifizierungsverarbeitung hängt davon ab, ob der identifizierte Apparat für ein Kommunikations-Gegenüber geeignet ist.
  • In einem Fall, in dem die Authentifizierung des Hoch-Niveau-Apparates 30 erfolgreich ist, empfängt der Niedrig-Niveau-Apparat 40 ein normales Public Key-Zertifikat eines Hoch-Niveau-Apparates und eine Zufallszahl, die mit dem normalen Private Key des Hoch-Niveau-Apparates verschlüsselt ist und führt eine Authentifizierung durch, wobei das gespeicherte Authentifizierungs-Root Key-Zertifikat des Hoch-Niveau-Apparates verwendet wird.
  • Die oben beschriebenen Abläufe sind ein Prozess, der in einem Fall ausgeführt wird, wo das HTTPS-Client-Funktionsteil 31 des Hoch-Niveau-Apparates 30 eine Kommunikation mit dem HTTPS-Server-Funktionsteil 42 des Niedrig-Niveau-Apparates 40 anfordert. Die Zertifikate und Keys für den vorangegangenen Falls sind dieselben in einem Fall, wo das HTTPS-Client-Funktionsteil 41 des Niedrig-Niveau-Apparates 40 eine Kommunikation mit dem HTTPS-Server-Funktionsteil 32 des Hoch-Niveau-Apparates 30 verlangt, der einzige Unterschied ist, dass die Verarbeitung, die durch den Hoch-Niveau-Apparat 30 und den Niedrig-Niveau-Apparat 40 ausgeführt werden, vertauscht werden.
  • Dieselben Verarbeitungen (Prozesse) werden bei einer Kommunikation zwischen dem Hoch-Niveau-Apparat 30 und dem Zertifikat-Management-Apparat 20 ausgeführt.
  • Wie oben beschrieben, wird in einem Fall, in dem entsprechende Apparate ein normales Public Key-Zertifikat von einem Kommunikations-Gegenüber empfangen, die Authentifizierung des normale Public Key-Zertifikates verweigert, bis die Gültigkeitsdauer bzw. Validierungsbenennung, die in dem normalen Public Key-Zertifikat bezeichnet ist, nicht abgelaufen ist. Daher kann eine Authentifizierung nicht ausgeführt werden, wenn die Gültigkeitsdauer bzw. Validierungsbenennung abgelaufen ist.
  • Daher wird, um zu vermeiden, dass dies auftritt, ein neues Public Key-Zertifikat, welches nach dem Verfall der Gültigkeitsdauer bzw. Validierungsbenennung verwendet werden soll, in jedem der Apparate vor dem Verfall des aktuell verwendeten Public Key-Zertifikates gespeichert. Jedoch kann auf einem Apparat von außerhalb in einem Fall nicht zugegriffen werden, in dem der Strom des Apparates ausgeschaltet ist, oder einem Fall, in dem der Apparat noch in einem Lager oder Ähnlichem aufbewahrt wird. Entsprechend kann eine Gültigkeitsdauer bzw. Validierungsbenennung verfallen, bevor ein neues Public Key-Zertifikat in dem Apparat gespeichert werden kann.
  • Angenommen, dass jeder der Apparate eine Authentifizierung nur ausführen kann, indem ein normales Public Key-Zertifikat verwendet wird, würde es ein anderes Verfahren zum sicheren Übertragen eines neuen normalen Public Key-Zertifikates, eines normalen privaten Keys und/oder eines normalen Root-Key-Zertifikates an einen Zielapparat über ein Netzwerk in einer Situation geben, in der die Gültigkeitsdauer bzw. Validierungsbenennung verfallen ist. Jedoch ist das Kommunikations- bzw. Datenübertragungssystem entsprechend einer Ausführungsform der vorliegenden Erfindung in der Lage, eine derartige Situation zu handhaben, indem Rescue-Authentifizierungs-Informationen gespeichert werden, sodass ein Kommunikations-Gegenüber authentifiziert werden kann, indem zwei unterschiedliche Typen von digitalen Zertifikaten verwendet werden. Indem die Rescue-Authentifizierungs-Informationen verwendet werden, können ein neues normales Public Key-Zertifikat und Ähnliches zu einem Zielapparat über ein Netzwerk sicher übertragen werden.
  • Die Rescue-Authentifizierungs-Informationen weisen eine Struktur auf, die grundsätzlich dieselbe wie die der normalen Authentifizierungs-Informationen ist. Zum Beispiel ist das normale Public Key-Zertifikat des Niedrig-Niveau-Apparates ein digitales Zertifikat, das eine digitale Unterschrift aufweist, die an einen Rescue Public Key bzw. Rettungs-Public Key angehängt ist, der durch den Zertifikat-Management-Apparat 20 für den Niedrig-Niveau-Apparat 40 ausgegeben wird, in welchem die digitale Unterschrift seiner Authentizität ermöglicht, die mit einem Rescue-Root-Key bzw. Rettungs-Root-Key verifiziert werden soll. Das Rescue Public Key-Zertifikat bzw. Rettungs-Public Key-Zertifikat des Niedrig-Niveau-Apparates ist ein Zertifikat, das einem Langzeit-Zertifikat entspricht. Weiter ist ein eigener Rescue Key des Niedrig-Niveau-Apparates ein eigener Key, der dem oben beschriebenen Rescue Public Key des Niedrig-Niveau-Apparates entspricht und ein Rescue Root Key-Zertifikat des Niedrig-Niveau-Apparates ist ein digitales Zertifikat, das eine digitale Unterschrift aufweist, die an einen Authentifizierungs-Rescue Root Key des Niedrig-Niveau-Apparates angehängt wird, in welchem die digitale Unterschrift seine Authentizität ermöglicht, die mit einem eigenen Root Key, der ihm entspricht, verifiziert werden soll.
  • Die Rescue-Authentifizierungs-Informationen sind unterschiedlich von den normalen Authentifizierungs-Informationen, und zwar dadurch, dass die Gültigkeitsdauer bzw. Validierungsbenennung des Rescue Public Key-Zertifikates mit einer Dauer eingestellt wird, die länger ist, als die des normalen Public Key-Zertifikates.
  • 9 zeigt ein Beispiel des normalen Public Key-Zertifikates und 10 zeigt ein Beispiel des Rescue Public Key-Zertifikates.
  • Sowohl das normale Public Key-Zertifikat in 9 als auch das Rescue Public Key-Zertifikat in 10 wird an denselben Apparat ausgegeben, in welchem Buchstaben F und I in 9 und 10 jeweils dieselben Authentifizierungs-Informationen bezüglich des Apparates des ausgegebenen Zieles bezeichnen. Jedoch ist, wie in dem Buchstabe E von 9 gezeigt, die Gültigkeitsdauer bzw. Validierungsbenennung des normalen Public Key-Zertifikates eine Jahres-Dauer, die von 0 Uhr des 1.2003 beginnt und um 0 Uhr des 1. Januar 2004 verfällt. Anderseits ist, wie in Buchstabe H von 10 gezeigt, die Gültigkeitsdauer bzw. Validierungsbenennung des Rescue Public Key-Zertifikates eine 50-Jahre-Dauer, die um 0 Uhr des 1. Januar 2000 beginnt, und um 0 Uhr des 1. Januars 2050 verfällt.
  • Weiter ist, obwohl der Aussteller für beide Zertifikate dieselbe CA der Firma XXX ist, die CA des normalen Public Key-Zertifikates „normale CA" (wie mit dem Buchstabe D in 9 bezeichnet) und die CA des Rescue Public Key-Zertifikates ist „Rescue CA" (wie mit Buchstabe G in 10 bezeichnet).
  • Obwohl das Rescue Public Key-Zertifikat eine lange Gültigkeitsdauer bzw. Validierungsbenennung aufweist, kann es, verglichen mit dem normalen Public Key-Zertifikat, das eine kurze Gültigkeitsdauer bzw. Validierungsbenennung aufweist, einen Mangel an Sicherheit geben, eine Authentifizierung eines Kommunikations-Gegenübers kann ausgeführt werden, selbst wenn die Gültigkeitsdauer bzw. Validierungsbenennung des normalen Public Key-Zertifikates zerfallen ist, indem das Rescue Public Key-Zertifikat verwendet wird, so lange bis die Gültigkeitsdauer des Rescue Public Key-Zertifikates nicht verfallen ist. Anschließend kann, wenn die Authentifizierung erfolgreich ist, ein gemeinsamer Key mit dem Kommunikations-Gegenüber geteilt werden und es kann ein sicherer Übertragungsweg erhalten werden, und zwar durch Codieren unter Verwendung des gemeinsamen Keys. Entsprechend kann, indem der erhaltene Übertragungsweg verwendet wird, ein neues normales Public Key-Zertifikat übertragen werden und für das Kommunikations-Gegenüber eingestellt werden.
  • Es ist zu beachten, dass in dem oben beschriebenen Fall der Ausführung der Authentifizierungsverarbeitung durch Verwenden der Rescue-Authentifizierungs-Informationen das Abschwächen der Sicherheit auf das Ausmaß der Gültigkeitsdauer bzw. Validierungsbenennung kein kritisches Problem sein würde, da es nur beschränkten Operationen erlaubt ist, ausgeführt zu werden (z. B. Aktualisieren der normalen Authentifizierungs-Informationen, wie zum Beispiel dem normalen Public Key-Zertifikat).
  • Wenn man dieses Punkt in Betracht zieht, ist es zu bevorzugen, eine lange Gültigkeitsdauer bzw. Validierungsbenennung für das Rescue Public Key-Zertifikat in einem Fall bereitzustellen, in dem die Gültigkeitsdauer bzw. Validierungsbenennung des normalen Public Key-Zertifikates verfallen ist. Genauer gesagt, kann hier die Gültigkeitsdauer bzw. Validierungsbenennung des Rescue Public Key-Zertifikates zum Beispiel eine Produktlebensdauer des Zielapparates sein. Die Produktservice-Lebensdauer kann zum Beispiel eine geschätzte Betriebsdauer sein oder eine bestimmte Laufzeit, in welcher die Lebensspanne zum Beispiel entsprechend einer Verwendungsdauer eingestellt werden kann, die während der Entwicklung geschätzt wird, eine geschätzte Dauer der Haltbarkeit und/oder Qualitätsgarantiedauer des Apparates.
  • Durch Einstellen der Gültigkeitsdauer bzw. Validierungsbenennung des Rescue Public Key-Zertifikates länger als eine Dauer, in der man angibt, dass der Apparat normal funktioniert, so lange eine Wartung des Apparates ordentlich durchgeführt wird, kann das Rescue Public Key-Zertifikat ein Zertifikat mit einer nicht verfallbaren Lebensdauer sein, unter der Bedingung, dass der Apparat aktiv ist (betreibbar). Daher kann, so lange der Apparat aktiv ist (betreibbar), eine Authentifizierung, die das Rescue Public Key-Zertifikat verwendet (d. h. eine Authentifizierung, die die Rescue-Authentifizierungs-Informationen verwendet), immer ausgeführt werden. Weiter kann, da das Rescue Public Key-Zertifikat keine Aktualisierung, Beschädigung und Ähnliches erfordert, kann verhindert werden, dass die Aktualisierungsverarbeitung auftritt.
  • Es ist sogar noch bevorzugter, wenn die Gültigkeitsdauer bzw. Validierungsbenennung beträchtlich länger ist als die oben beschriebene Produktservice-Lebensdauer oder die Betriebsdauer des Apparates. In dem Beispiel, das in 10 gezeigt ist, kann ein Einstellen der Gültigkeitsdauer bzw. Validierungsbenennung auf fünfzig Jahre als ausreichend für einen durchschnittlichen Apparat betrachtet werden. Jedoch wird die Gültigkeitsdauer lediglich auf 50 Jahre eingestellt, aus dem Grund, dass die Gültigkeitsdauer entsprechend dem X.509-Format nur auf ein Maximum von fünfzig Jahren eingestellt werden kann. Jedoch kann eine längere Gültigkeitsdauer ebenfalls eingestellt werden, zum Beispiel eine Dauer von 100 Jahren oder eine Dauer von mehreren 100 Jahren. Das Verfallsdatum der Gültigkeitsdauer ist bloß für den Fall einer Anforderung des Formates des Public Key-Zertifikates bezeichnet. Entsprechend kann das Rescue Public Key-Zertifikat so betrachtet werden, als ob es im Wesentlichen kein Verfallsdatum aufweist. Dies kann ebenfalls für den Fall gelten, in dem die Gültigkeitsdauer 20 Jahre, 30 Jahre oder eine weit kürzere Dauer beträgt.
  • Außerdem kann, wenn die Gültigkeitsdauer des Rescue Public Key-Zertifikates kürzer ist als die Produktservice-Lebensdauer eine Authentifizierung, die das Rescue Public Key-Zertifikat verwendet, in einem Fall ausgeführt werden, in dem die Gültigkeitsdauer des normalen Public Key-Zertifikates ausläuft, so lange die Gültigkeitsdauer des Rescue Public Key-Zertifikates länger ist als die normalen Public Key-Zertifikates.
  • Es ist zu beachten, dass die Gültigkeitsdauer des Public Key-Zertifikates unter Berücksichtigung der Sicherheit mit einer geeigneten Dauer eingestellt werden kann, sodass die Gültigkeitsdauer des normalen Public Key-Zertifikates oft früher verfallt als die Produktservice-Lebensdauer, oder verfällt, wenn der Apparat noch in Betrieb ist.
  • Zwischenzeitlich gibt, in einem Fall der Ausführung einer Authentifizierungsverarbeitung in Übereinstimmung mit einem SSL-Protokoll bzw. Zertifikat ein Server dasselbe Public Key-Zertifikat zurück, wenn auf ihn durch eine vorbestimmte URL (Uniform Ressource Locator) zugegriffen wird, da der Zustand jetzt noch nicht den Zustand seines Clients zu dem Zeitpunkt des Empfangens einer Kommunikationsanforderung von dem Client kennt. Daher kann ein einzelner Apparat einfach nicht eine Vielzahl von Public Key-Zertifikaten behalten und verwendet selektiv einen Typ von Public Key-Zertifikaten entsprechend des Kommunikations-Gegenübers, um eine Authentifizierung auszuführen. Jedoch kann mit den Apparaten entsprechend einer Ausführungsform der vorliegenden Erfindung, gezeigt in 1 und 2, eine Authentifizierung ausgeführt werden, indem das normale Public Key-Zertifikat und das Rescue Public Key-Zertifikat entsprechend den Umständen verwendet wird.
  • Als Nächstes wird ein Beispiel der Verwendung des normalen Public Key-Zertifikates und des Rescue Public Key-Zertifikates entsprechend der Umstände mit Bezug auf 11 beschrieben. Obwohl 11 nur den Hoch-Niveau-Apparat 30 und den Hoch-Niveau-Apparat 40 zeigt, kann das Beispiel ebenfalls auf den Zertifikat-Management-Apparat 20 angewendet werden.
  • Wie oben beschrieben kann ein Server grundsätzlich nur ein bestimmtes Public Key-Zertifikat als Antwort auf eine Kommunikationsanforderung von einem Client übertragen. Jedoch kann in einem Fall, in dem Adressen zum Empfangen (Akzeptieren) der Kommunikationsanforderung unterschiedlich sind, unterschiedliche Public Key-Zertifikate entsprechend der jeweiligen Adressen zurückgegeben werden. Die Adressen können zum Beispiel in Übereinstimmung mit einer URL eingestellt werden.
  • In dem Beispiel, das in 11 gezeigt ist, werden sowohl der Hoch-Niveau-Apparat 30 und der Niedrig-Niveau-Apparat 40 mit einer normalen URL zum Ausführen einer Identifizierung mit einem normalen Public Key-Zertifikat bereitgestellt und eine Rescue-URL zum Ausführen einer Identifizierung mit einem Rescue Public Key-Zertifikat, in welcher ein Apparat zum Anfragen einer Kommunikation (Apparat (Seite), die als ein Client arbeitet) eine Kommunikationsanforderung überträgt, indem selektiv eine der URLs entsprechend des angeforderten Typs von Authentifizierung bezeichnet wird. Selbst in einem Fall, in welchem die URLs physikalisch derselben Apparatur entsprechen, werden die URLs eingestellt, um logisch den unterschiedlichen Apparaten durch Umrüsten zu entsprechen, zum Beispiel eine IP-Adresse und/oder eine Port-Nummer. Das heißt, die URLs werden zum Erreichen einer Funktion eines so genannten virtuellen Servers eingestellt.
  • Entsprechend bestimmt (unterscheidet) ein Apparat, der die Kommunikationsanforderung (Apparat) (Seite), der als ein Server (arbeitet), den Typ des Zertifikates, das entsprechend der empfangenen URL zurückgeben wird, wobei der Apparat in der Lage ist, ein normales Public Key-Zertifikat zurückzugeben, wenn er eine normale URL empfängt, und ein Rescue Public Key-Zertifikat zurückzugeben, wenn er ein Rescue Public Key-Zertifikat empfängt.
  • Da der Client, der eine Kommunikation angefordert hat, die URL kennt, an welche der Request übertragen wurde, ist der Client in der Lage, das entsprechende Public Key-Zertifikat entsprechend der URL auszuwählen und zu übertragen, und zwar in einem Fall einer Zwei-Wege-Authentifizierung.
  • Wenn der Hoch-Niveau-Apparat 30 eine Authentifizierung des Niedrig-Niveau-Apparats 40 ausführt, versucht der Hoch-Niveau-Apparat 30 zuerst die Authentifizierung, indem ein normales Public Key-Zertifikat verwendet wird. In einem Fall, in welchem die Authentifizierung, die das normale Public Key-Zertifikat aufgrund eines Verfalls der Gültigkeitsdauer des normalen Public Key-Zertifikates fehlschlägt, versucht dann der Hoch-Niveau-Apparat 30 zu authentifizieren, indem ein Rescue Public Key-Zertifikat verwendet wird. Wenn der Niedrig-Niveau-Apparat 40 ein geeignetes Kommunikations-Gegenüber (Apparat) ist, bei dem die Gültigkeitsdauer des Rescue Public Key-Zertifikates noch nicht verfallen ist, folgt die Authentifizierung, die das Rescue Public Key-Zertifikat verwendet. Der Hoch-Niveau-Apparat 30 weist eine Funktion der Aktualisierung der normalen Authentifizierungs-Informationen des Niedrig-Niveau-Apparates 40 auf, wenn die Authentifizierung ein Erfolg ist.
  • Daher überträgt in einem Fall, in welchem der Hoch-Niveau-Apparat 30 eine Kommunikation mit dem Niedrig-Niveau-Apparat 40 anfordert, der Hoch-Niveau-Apparat 30 zuerst eine Kommunikationsanforderung an die normale URL und versucht eine Authentifizierung, wobei das normale Public Key-Zertifikat verwendet wird. Wenn die Authentifizierung, die das normale Public Key-Zertifikat verwendet, fehlschlägt, überträgt der Hoch-Niveau-Apparat 30 dann eine Kommunikationsanfrage an die Rescue-URL und versucht eine Authentifizierung, wobei das Rescue Public Key-Zertifikat verwendet wird. Wenn die Authentifizierung, die das Rescue Public Key-Zertifikat verwendet, erfolgreich ist, erhält der Hoch-Niveau-Apparat 30 ein Update-Zertifikat-Set von dem Zertifikat-Management-Apparat 20, überträgt das erhaltene Update-Zertifikat-Set an den Niedrig-Niveau-Apparat 40 und fordert den Niedrig-Niveau-Apparat 40 an, das Update-Zertifikat-Set zu speichern. Das Teilen eines gemeinsamen Keys kann ebenfalls in der Authentifizierungs-Verarbeitung ausgeführt werden, wobei das Rescue Public Key-Zertifikat auf dieselbe Art und Weise ausgeführt wird, wie die Authentifizierungs-Verarbeitung, wobei das normale Public Key-Zertifikat verwendet wird. Daher kann die Übertragung des Zertifikat-Sets sicher durch Codierung des Zertifikat-Sets mit dem gemeinsamen Key ausgeführt werden.
  • 12 zeigt ein Beispiel des Zertifikat-Sets einschließlich normaler Authentifizierungs-Informationen, die in dem Niedrig-Niveau-Apparat 40 gespeichert werden können. Das normale Public Key-Zertifikat des Niedrig-Niveau-Apparates in dem Update-Zertifikat-Set weist eine Gültigkeitsdauer bzw. Validierungsbildung auf, die unverfallbar ist.
  • Der Root Private Key, der verwendet wird, um das normale Public Key-Zertifikat des Niedrig-Niveau-Apparates zu machen, ist ein Root Key, entsprechend des Root Keys, der in dem normalen Root Key-Zertifikat des Niedrig-Niveau-Apparates enthalten ist, das in dem Hoch-Niveau-Apparat 30 während eines Erhaltens gespeichert wird. Das normale Public Key-Zertifikat des Hoch-Niveau-Apparates enthält einen Root Key zum Verifizieren einer Authentizität der digitalen Unterschrift, die an das normale Public Key-Zertifikat des Hoch-Niveau-Apparates angehängt ist, das in dem Hoch-Niveau-Apparat 30 gespeichert ist. Weiter kann durch Ausgabe des Update-Zertifikat-Sets ein neuer eigener Root Key ausgegeben werden und die Version des Public Key-Zertifikates kann aktualisiert werden (Ausgabe eines Public Key-Zertifikates, das eine digitale Signatur aufweist, die an ein Public Key-Zertifikat angehängt wird, indem ein eigener neuer Root Key verwendet wird).
  • Zwischenzeitlich wird, wenn der Niedrig-Niveau-Apparat 40 eine Anforderung empfangt, dass die Zertifikate, die Zertifikate speichern, das empfangene Zertifikat in dem Zertifikat-Speicherteil 45 speichert, und das Zertifikat-Aktualisierungsteil 48 aktualisiert die normalen Authentifizierungs-Informationen mit den empfangenen Zertifikat-Set.
  • Wenn das Update genauer ausgeführt wird, kann ein unverfallbares normales Public Key-Zertifikat neu in dem Niedrig-Niveau-Apparat 40 gespeichert werden, wodurch ein Zustand erhalten wird, in dem eine Authentifizierung ausgeführt werden kann, wobei das normale Public Key-Zertifikat verwendet wird. Danach eine Kommunikation durch die Authentifizierungsverarbeitung ausgeführt werden, die das normale Public Key-Zertifikat verwendet.
  • In den Authentifizierungs-Informationen, die in 5 und 6 gezeigt sind, muss das Root Key-Zertifikat nicht den Authentifizierungs-Gegenstand bezeichnen, aber ein selber Root Key kann ebenfalls verwendet werden (zum Beispiel das Root Key-Zertifikat des Hoch-Niveau-Apparates und das Authentifizierungs-Zertifikat des Niedrig-Niveau-Apparates kann dasselbe sein). Nachdem die Authentifizierung des Public Key-Zertifikates verifiziert ist, kann der Typ oder die Apparatenummer des Apparates identifiziert werden, indem Identifikations-Informationen hinzugenommen werden, die an das Public Key-Zertifikat angehängt sind.
  • Als Nächstes wird eine Zertifikat-Aktualisierungsverarbeitung für zwei Typen von Zertifikaten, einschließlich des normalen Public Key-Zertifikats und des Rescue Public Key-Zertifikats beschrieben. 13 ist ein Flussdiagramm, das einen Prozess zeigt, der durch den Hoch-Niveau-Apparat 30 ausgeführt wird (Hoch-Niveau-Apparate-Seite) und 14 ist ein Flussdiagramm, das einen Prozess zeigt, der durch den Niedrig-Niveau-Apparat 40 ausgeführt wird (Niedrig-Niveau-Apparate-Seite). Diese Prozesse werden durch die CPUs des Hoch-Niveau-Apparates 30 und des Niedrig-Niveau-Apparates 40 ausgeführt, indem vorgeschriebene Steuerungsprogramme ausgeführt werden. Diese Prozesse sind ein Beispiel eines Zertifikat-Übertragungsverfahrens entsprechend einer Ausführungsform der vorliegenden Erfindung.
  • Die Flussdiagramme in den 13 und 14 zeigen die Prozesse in einem Fall, in dem der Hoch-Niveau-Apparat 30 eine Kommunikation mit dem Niedrig-Niveau-Apparat 40 anfordert. Aus Gründen der Einfachheit wird die Authentifizierungsverarbeitung in diesem Beispiel ausgeführt, durch den Hoch-Niveau-Apparat 30 den Niedrig-Niveau-Apparat 40 authentifiziert, indem ein Public Key-Zertifikat, das von dem Niedrig-Niveau-Apparat 40 empfangen wird (Ein-Wege-Authentifizierungsverarbeitung, wie in 24 gezeigt). Jedoch muss eine Kreuz-Zertifikation, wie in 22 gezeigt, ebenfalls in diesem Beispiel angewendet werden, in welcher ein Public Key-Zertifikat ebenfalls von dem Hoch-Niveau-Apparat 30 zu dem Niedrig-Niveau-Apparat 40 übertragen wird.
  • Der Prozess, der in dem Flussdiagramm von 13 gezeigt ist, wird in einem Fall gestartet, in dem der Hoch-Niveau-Apparat 30 versucht, eine Anforderung oder Anmeldung bei dem Niedrig-Niveau-Apparat 40 zu übertragen oder einen Fall, in dem der Hoch-Niveau-Apparat 30 versucht, eine Kommunikation zum Empfangen einer Anforderung oder Anmeldung von dem Niedrig-Niveau-Apparat 40 anzufordern. In Schritt S101 überträgt der Hoch-Niveau-Apparat 30 eine Kommunikationsanforderung an die normale URL. Es sollte beachtet werden, dass die normalen URLs und Rescue-URLs, die allen Apparaten des Kommunikations-Gegenübers entsprechen, in dem Hoch-Niveau-Apparat 30 gespeichert werden.
  • Der Niedrig-Niveau-Apparat 40 startet dann den Prozess, der in dem Flussdiagramm in 14 gezeigt ist, bis zum Empfangen der Kommunikationsanforderung. In Schritt S201 bestimmt der Niedrig-Niveau-Apparat 40, ob die URL, die die Kommunikationsanforderung empfängt, eine normale URL oder eine Rescue-URL ist.
  • Wenn die Kommunikationsanforderung an eine normale URL gerichtet ist, überträgt der Niedrig-Niveau-Apparat 40 ein normales Public Key-Zertifikat und eine erste Zufallszahl, die mit einem normalen eigenen Key verKeyt ist (eigener normaler Key des Niedrig-Niveau-Apparates) zu dem Hoch-Niveau-Apparat 30 (Schritt S202). Die oben beschriebenen Operationen entsprechen den Schritten S21 und 22 von 22 und 24.
  • Auf der Seite des Hoch-Niveau-Apparates 30 führt der Hoch-Niveau-Apparat 30 eine Authentifizierungsverarbeitung aus, wenn er eine Antwort von dem Niedrig-Niveau-Apparat 40 empfängt, oder wenn eine vorher festgelegte Zeitspanne vergangen ist (Schritt S102). Diese Authentifizierungsverarbeitung verwendet ein normales Root Key-Zertifikat des Niedrig-Niveau-Apparates und entspricht Schritten S12 und S13 der 22 oder 24.
  • Dann bestimmt der Hoch-Niveau-Apparat 30, ob die Authentifizierungsverarbeitung erfolgreich ist (Schritt S103). Wenn die Authentifizierungsverarbeitung ein Erfolg ist (JA in Schritt S103 überträgt der Hoch-Niveau-Apparat 30 einen Startparameter des gemeinsamen Keys (gemeinsamer Key-Startparameter) an den Niedrig-Niveau-Apparat 40 und erzeugt den gemeinsamen Key, der in einen späteren Kommunikation verwendet werden soll (Schritt S112). Dieser Prozess entspricht den Schritten S14 bis einschließlich S17 in 22 oder 24.
  • Auf der einen Seite des Niedrig-Niveau-Apparates 40 wartet der Niedrig-Niveau-Apparat 40 auf eine Antwort als Antwort auf die Übertragung des normalen Public Key-Zertifikates zum Bestimmen des Ergebnisses der Authentifizierung (Schritt S203). Der Niedrig-Niveau-Apparat 40 bestimmt, dass die Authentifizierung ein Erfolg ist, wenn er den gemeinsamen Key-Startparameter von dem Hoch-Niveau-Apparat 30 empfängt (JA in Schritt S203) und erzeugt den gemeinsamen Key, der in den späteren Kommunikationen verwendet werden soll (Schritt S204). In einem Fall, in welchem eine Authentifizierungs-Fehler-Antwort empfangen wird (oder wenn keine Antwort von dem Hoch-Niveau-Apparat 30 innerhalb einer vorbestimmten Zeitspanne übertragen worden ist) bestimmt der Niedrig-Niveau-Apparat 40, dass die Authentifizierung ein Fehler ist und beendet den Prozess (NEIN in Schritt S203). Diese Prozesse entsprechen den Schritten S23 bis S26 von 22 oder Schritten 25 und 26 von 24.
  • Auf der Seite des Hoch-Niveau-Apparates 30 überträgt der Hoch-Niveau-Apparat 30 nachfolgend an Schritt S112 eine Anforderung (Befehl) zusammen mit vorgeschriebenen Daten zu dem Niedrig-Niveau-Apparat 40 (Schritt S113). Dann wartet der Hoch-Niveau-Apparat 30 auf eine Antwort (Reaktion) als Reaktion auf die übertragene Anforderung (Schritt S114). Dann bestimmt der Hoch-Niveau-Apparat 30, ob alle Anforderungen übertragen wurden (Schritt S115). Wenn noch eine Anforderung zurückbleibt, kehrt der Prozess zu Schritt S113 zurück und der Prozess wird wiederholt (NEIN in Schritt S115). Wenn alle Anforderungen übertragen sind (JA in Schritt S115), wird die Kommunikation abgeschaltet (Schritt S116) und der Prozess wird beendet.
  • Auf der Seite des Niedrig-Niveau-Apparates 40 bestimmt der Niedrig-Niveau-Apparat 40, ob eine Anforderung für den Hoch-Niveau-Apparat 30 empfangen wird (Schritt S205). Wenn die Anforderung von dem Hoch-Niveau-Apparat 30 empfangen wird (JA in Schritt 205) führt der Niedrig-Niveau-Apparat 40 einen Prozess in Übereinstimmung mit der Anforderung durch und kehrt als Reaktion zu dem Hoch-Niveau-Apparat 30 zurück (Schritt S206). Weiter bestimmt der Niedrig-Niveau-Apparat 40, ob es irgendwelche Informationen gibt, die an den Hoch-Niveau-Apparat 30 berichtet werden sollen (Schritt S207). Wenn es derartige Informationen gibt, überträgt der Niedrig-Niveau-Apparat 40 eine Benachrichtigung an den Hoch-Niveau-Apparat 30 (Schritt S208). Dann bestimmt der Niedrig-Niveau-Apparat 40, ob der Hoch-Niveau-Apparat 30 Kommunikationen unterbrochen hat (Schritt S209). Wenn die Kommunikationen bzw. Verbindungen nicht unterbrochen sind (NEIN in Schritt S209), kehrt der Prozess zu Schritt S205 zurück. Wenn die Kommunikation bzw. Verbindung unterbrochen ist (JA in Schritt S209), wird der Prozess beendet.
  • In der Zwischenzeit bestimmt auf der Seite des Hoch-Niveau-Apparates 30, in einem Fall, in dem die Authentifizierungsverarbeitung ein Fehler ist (NEIN in Schritt S103), der Hoch-Niveau-Apparat 30, ob der Grund für den Fehler aufgrund des Verfalls der Gültigkeitsdauer bzw. Validierungsbenennung erfolgt ist (Schritt S104). Wie für die Gründe des Authentifizierungsfehlers gibt es zum Beispiel ein Verfall der Gültigkeitsdauer bzw. der Validierungsbenennung des Public Key-Zertifikates, einen Fehler bei der Bestätigung der Authentizität aufgrund einer Nicht-Konformität zwischen den Versionen des Public Key-Zertifikates und des Root Key-Zertifikates, ein beschädigtes Public Key-Zertifikat, keine Übertragung des Public Key-Zertifikates, Kommunikationen bzw. Verbindungen mit einem vollständig unterschiedlichen Apparat und/oder einem nicht geeigneten Apparat für ein Kommunikations-Gegenüber entsprechend den Identifikations-Informationen, die an das Public Key-Zertifikat angehängt werden. Wenn der Hoch-Niveau-Apparat 30 bestimmt, dass der Fehler aufgrund eines anderen Grundes als den Verfall der Gültigkeitsdauer des Public Key-Zertifikates erfolgt (NEIN in Schritt S104), wird der Prozess beendet.
  • Die Prozesse von Schritt S105 und solche, die folgen, werden ausgeführt, um ein neues normales Public Key-Zertifikat für das Kommunikations-Gegenüber in einem Fall zu speichern, in dem die Gültigkeitsdauer des normalen Public Key-Zertifikates verfallen ist. Es ist jedoch zu beachten, dass eine alternative Maßnahme ergriffen werden kann, wenn der Hoch-Niveau-Apparat bestimmt, dass der Fehler aufgrund eines anderen Grundes als dem Verfall der Gültigkeitsdauer des Public Key-Zertifikates erfolgt ist (z. B. eine Nicht-Konformität der Version des Public Key-Zertifikates, kein Empfang eines geeigneten Public Key-Zertifikates).
  • Zwischenzeitlich überträgt, wenn der Hoch-Niveau-Apparat 30 bestimmt, dass der Fehler aufgrund des Verfalls der Gültigkeitsdauer des Public Key-Zertifikates erfolgt (JA in Schritt S104), der Hoch-Niveau-Apparat 30 eine Kommunikationsanforderung an die Rescue URL des Niedrig-Niveau-Apparates 40.
  • In diesem Fall zeigt der Niedrig-Niveau-Apparat 40 wieder den Prozess, der im Flussdiagramm von 14 gezeigt ist; jedoch bestimmt in diesem Fall der Niedrig-Niveau-Apparat 40, dass die Kommunikationsanforderung an den Rescue-URL in Schritt S201 adressiert ist. Dann überträgt der Niedrig-Niveau-Apparat 40 ein Rescue Public Key-Zertifikat des Niedrig-Niveau-Apparates und eine erste Zufallszahl, die mit einem eigenen Rescue Key codiert ist (eigener Rescue Key des Niedrig-Niveau-Apparates) an den Hoch-Niveau-Apparat 30 (Schritt S210). Ähnlich zum Schritt S202 entsprechen diese Prozesse den Schritten S21 und S22 von 22 oder 24.
  • Auf der Seite des Hoch-Niveau-Apparates 30 führt der Hoch-Niveau-Apparat 30 bis zum Empfangen des Rescue Public Key-Zertifikates und der verschlüsselten ersten Zufallszahl, die in Schritt S210 übertragen wurde, eine Authentifizierungsverarbeitung durch (Schritt S106). Diese Authentifizierungsverarbeitung wird mit dem Rescue-Root Key-Zertifikat des Niedrig-Niveau-Apparates ausgeführt und entspricht den Schritten S12 und S13 von 22 oder 24.
  • Die Authentifizierungsverarbeitung kann als Fehler bestimmt werden, wenn es keinen Empfang innerhalb einer vorbestimmten Zeitspanne nach Schritt S105 gibt. Die CPU des Hoch-Niveau-Apparates 30 arbeitet als eine Authentifizierungseinheit für die Prozesse von den Schritten S105 und S106.
  • Dann bestimmt der Hoch-Niveau-Apparat 30, ob die Authentifizierungsverarbeitung ein Erfolg ist (Schritt S107). Wenn die Authentifizierungsverarbeitung ein Erfolg ist (JA in Schritt S107), wird ein gemeinsamer Key-Startparameter an den Niedrig-Niveau-Apparat 40 übertragen und der gemeinsame Key wird für spätere Kommunikationen erzeugt (Schritt S108). Diese Prozesse, genau wie solche von Schritten S103 und S112 entsprechen den Schritten S14 bis einschließlich S17 von 22 oder 24.
  • Auf der Seite des Niedrig-Niveau-Apparates 40 wartet der Niedrig-Niveau-Apparat auf eine Antwort als Reaktion auf die Übertragung in Schritt S201 zum Bestimmen des Ergebnisses der Authentifizierung (Schritt S211). Der Niedrig-Niveau-Apparat 40 bestimmt, dass die Authentifizierung ein Erfolg ist, wenn er die gemeinsamen Key-Startparameter von dem Hoch-Niveau-Apparat 30 empfängt (JA in Schritt S211) und erzeugt den gemeinsamen Key, der in späteren Kommunikation verwendet werden soll (Schritt S212). In einem Fall, in welchem eine Authentifizierungs-Fehlerantwort empfangen wird oder in welchem keine Antwort von dem Hoch-Niveau-Apparat 30 innerhalb einer vorbestimmten Zeitspanne übertragen wird, bestimmt der Niedrig-Niveau-Apparat 40, dass die Authentifizierung ein Fehler ist und beendet den Prozess (NEIN in Schritt S211). Diese Prozesse, genauso wie Schritte S203 und S204 entsprechen Schritten S23 bis S26 von 22 oder Schritten 25 und 26 von 24.
  • Zwischenzeitlich bestimmt auf der Seite des Hoch-Niveau-Apparates 30 der Hoch-Niveau-Apparat 30, dass der Niedrig-Niveau-Apparat 40 ein geeigneter Apparat für ein Kommunikations-Gegenüber ist, nachdem die Authentifizierungsverarbeitung, die das Rescue Public Key-Zertifikat verwendet, ein Erfolg ist (JA in Schritt S107). Anschließend nach Schritt S108 überträgt der Hoch-Niveau-Apparat 30 vorgeschriebene Informationen an den Zertifikat-Management-Apparat 20, um es dem Zertifikat-Management-Apparat 20 (CA) zu ermöglichen, ein Update-Zertifikat-Set zu erzeugen und erhält das erzeugte neue Update-Zertifikat-Set, um das normale Public Key-Zertifikat des Niedrig-Niveau-Apparates 40 zu aktualisieren (Schritt S109). Weitere Details dieses Prozesses sind unten beschrieben.
  • Der Hoch-Niveau-Apparat 30 überträgt nach dem Erhalten des neuen Zertifikat-Sets von dem Zertifikat-Management-Apparat 20 eine Zertifikat-Update-Anforderung und das neue Zertifikat-Set an den Niedrig-Niveau-Apparat 40, um die normalen Authentifizierungs-Informationen anzufordern, die in dem Niedrig-Niveau-Apparat 40 gespeichert sind und mit den Inhalten des neuen Zertifikat-Sets aktualisiert werden sollen (Schritt Silo). In diesem Prozess arbeitet die CPU des Hoch-Niveau-Apparates 30 als eine Zertifikat-Übertragungseinheit.
  • Dann wartet der Hoch-Niveau-Apparat 30 auf eine vorgeschriebene Reaktion (Antwort) von dem Niedrig-Niveau-Apparat 40 (Schritt S111). Anschließend an Schritt S111 trennt der Hoch-Niveau-Apparat 30 eine Verbindung, um dadurch den Prozess zu beenden. In einem Fall von Wiederübertragung einer ursprünglich übertragenen Anforderung oder Ähnlichem kann der Hoch-Niveau-Apparat 30 den Prozess wieder von Anfang an beginnen. Jedoch kann der Hoch-Niveau-Apparat 30 ebenfalls den Prozess von Schritt S103 bis Schritt S113 ausführen und weiter Anforderungen an den Niedrig-Niveau-Apparat 40 übertragen, da eine Authentifizierung, die das normale Public Key-Zertifikat verwendet, wahrscheinlich ist, um diesem Punkt nachzufolgen.
  • In der Zwischenzeit wartet auf der Seite des Niedrig-Niveau-Apparates 40 der Niedrig-Niveau-Apparat 40 anschließend an Schritt S212, um eine vorgeschriebene Anforderung von dem Hoch-Niveau-Apparat 30 zu empfangen (Schritt S213). Der Prozess fährt mit Schritt S214 fort, wenn der Niedrig-Niveau-Apparat 40 eine Anfrage von dem Hoch-Niveau-Apparat 30 empfängt (JA in Schritt S213). Dann bestimmt der Niedrig-Niveau-Apparat 30, ob die Anforderung eine Zertifikat-Update-Anforderung ist (Schritt S214). Hier ermöglicht, wie oben beschrieben, das Anforderung-Managementteil 44 des Niedrig-Niveau-Apparates 40 nur eine Ausführung einer Zertifikat-Update-Operation in einem Fall, in welchem das Rescue Public Key-Zertifikat in der Authentifizierungsverarbeitung verwendet wird (siehe 4). Wenn die Anforderung nicht die Zertifikat-Update-Anforderung ist (NEIN in Schritt S214), ignoriert der Niedrig-Niveau-Apparat 40 die Anforderung und kehrt zu Schritt S212 zurück, um auf die nächste Anforderung zu warten. Hier kann der Niedrig-Niveau-Apparat 40 alternativ eine Antwort zurückgeben und berichten, dass die Anforderung nicht akzeptiert werden kann.
  • Wenn die Anforderung die Zertifikat-Update-Anforderung ist (JA in Schritt S214), speichert der Niedrig-Niveau-Apparat 40 das neue Zertifikat-Set, das zusammen mit der Zertifikat-Update-Anforderung in dem Zertifikat-Speicherteil 45 empfangen wird und aktualisiert seine normalen Authentifizierungs-Informationen (wie in 5A gezeigt) mit den Inhalten des neuen Zertifikat-Sets (Schritt S215). Dann berichtet der Niedrig-Niveau-Apparat 40 die Aktualisierungsergebnisse als Antwort auf die Anforderung, die von dem Hoch-Niveau-Apparat übertragen wurde (Schritt S216). Dann ist der Prozess beendet.
  • Als Nächstes wird ein Beispiel zur Ausführung des Prozesses des Hoch-Niveau-Apparates und des Niedrig-Niveau-Apparates, gezeigt in 13 und 14, zusammen mit dem Prozess des Zertifikat-Management-Apparates 20 beschrieben, und zwar als eine Folgeoperation in Bezug auf 15 und 16. Es ist zu beachten, dass dieses Beispiel in einem Fall beschrieben wird, in dem die Gültigkeitsdauer des normalen Public Key-Zertifikates des Niedrig-Niveau-Apparates, das in dem Niedrig-Niveau-Apparat 40 gespeichert ist, verfallen ist.
  • In diesem Beispiel weist der Hoch-Niveau-Apparat 30 das HTTPS-Client-Funktionsteil 31 auf, das als ein Niedrig-Niveau-Apparat-Client arbeitet, und überträgt eine Kommunikationsanforderung an die normale URL des Niedrig-Niveau-Apparates 40 (Schritt S301). In diesem Fall wird die Anforderung von dem HTTPS-Server-Funktionsteil 42 des Niedrig-Niveau-Apparates 40 empfangen und wird an das Authentifizierungsverarbeitungsteil 43 berichtet. Weiter wird in diesem Fall eine Authentifizierung, die das normale Public Key-Zertifikat verwendet, mit dem Niedrig-Niveau-Apparat 40 angefordert. Dann gibt das Authentifizierungsverarbeitungsteil 43 in Übereinstimmung mit einem SSL-Protokoll bzw. Zertifikat eine Zufallszahl zurück, die mit dem normalen eigenen Key des Niedrig-Niveau-Apparates codiert ist, die in dem Zertifikat-Speicherteil 45 zusammen mit dem normalen Public Key-Zertifikat des Niedrig-Niveau-Apparates gespeichert ist (ebenfalls gespeichert in dem Zertifikat-Speicherteil 45), an den Hoch-Niveau-Apparat 30 zurück (S302).
  • Der Hoch-Niveau-Apparat 30 versucht bis zum Empfang des normalen Public Key-Zertifikates des Niedrig-Niveau-Apparates eine Authentifizierungsverarbeitung. Jedoch bestimmt der Hoch-Niveau-Apparat 30, dass die Authentifizierungsverarbeitung ein Fehler ist, da die Gültigkeitsdauer bzw. Validierungsbenennung des normalen Public Key-Zertifikates des Niedrig-Niveau-Apparates verfallen ist (S303). Dann gibt der Hoch-Niveau-Apparat 30 eine Authentifizierungs-Fehlerantwort an den Niedrig-Niveau-Apparat 40 zurück (S304).
  • Dann überträgt der Hoch-Niveau-Apparat 40 eine Kommunikationsanforderung an die Rescue-URL des Niedrig-Niveau-Apparates 40 in einem Versuch, um eine Authentifizierung auszuführen, wobei ein Zertifikat mit einer Gültigkeitsdauer länger als die des normalen Public Key-Zertifikates verwendet wird (S305).
  • Auf eine ähnliche Weise wie in Schritt S301 wird die Anforderung an das Authentifizierungs-Verarbeitungsteil 43 des Niedrig-Niveau-Apparates 40 berichtet. Nur in diesem Fall wird eine Authentifizierung, die das Rescue Public Key-Zertifikat verwendet, von dem Niedrig-Niveau-Apparat 40 angefordert. Dann gibt das Authentifizierungs-Verarbeitungsteil 43 in Übereinstimmung mit einem SSL-Protokoll bzw. Zertifikat eine Zufallszahl zurück, die mit dem eigenen Rescue Key des Niedrig-Niveau-Apparates gespeichert ist, und zwar zusammen mit dem Rescue Public Key-Zertifikat des Niedrig-Niveau-Apparates (ebenfalls gespeichert in dem Zertifikat-Speicherteil 45) an den Niedrig-Niveau-Apparat 30 zurück (S306).
  • Der Hoch-Niveau-Apparat 30 versucht bis zum Empfangen des Rescue Public Key-Zertifikates des Niedrig-Niveau-Apparates eine Authentifizierungs-Verarbeitung. Der Hoch-Niveau-Apparat 30 bestimmt, dass die Authentifizierungs-Verarbeitung ein Erfolg ist, und zwar unter einer Bedingung, dass der Niedrig-Niveau-Apparat ein geeigneter Apparat für ein Kommunikation-Gegenüber ist und dass die Gültigkeitsdauer des Rescue Public Key-Zertifikates des Niedrig-Niveau-Apparates nicht verfallen ist (S307). Dann gibt in einem Fall einer Ein-Weg-Authentifizierung der Hoch-Niveau-Apparat 30 einen gemeinsamen Key-Startparameter zurück, der mit dem Public Key codiert ist, der in den Rescue Public Key-Zertifikat des Niedrig-Niveau-Apparates enthalten ist, an die Rescue-URL des Niedrig-Niveau-Apparates 40. In einem Fall einer Zwei-Wege-Authentifizierung gibt der Hoch-Niveau-Apparat 30 eine zweite Zufallszahl zurück, die mit dem eigenen Rescue Key des Hoch-Niveau-Apparates codiert ist, die in dem Zertifikat-Speicherteil 35 zusammen mit dem Rescue Public Key-Zertifikat des Hoch-Niveau-Apparates gespeichert ist, an die Rescue-URL des Niedrig-Niveau-Apparates 40 zurück (S308).
  • Der Niedrig-Niveau-Apparat 40 sendet die Informationen, die von dem Hoch-Niveau-Apparat 30 empfangen werden zu dem Authentifizierungs-Verarbeitungsteil 43 und entschlüsselt die gemeinsamen Key-Startparameter, wobei der eigene Rescue Key des Niedrig-Niveau-Apparates verwendet wird. Weiter führt in dem Fall der Zwei-Wege-Authentifizierung der Niedrig-Niveau-Apparat, nachdem er die Authentizität des Rescue Public Key-Zertifikates des Niedrig-Niveau-Apparates mit dem Authentifizierungs-Root Key-Zertifikat des Hoch-Niveau-Apparates verifiziert hat, die Authentifizierungs-Verarbeitung durch, indem die zweite Zufallszahl mit dem Public Key entschlüsselt wird, der in dem Public Key-Zertifikat enthalten ist. Da die Authentifizierungs-Verarbeitung in diesem Fall entsprechend ausgeführt wird, bestimmt der Niedrig-Niveau-Apparat, dass die Authentifizierungs-Verarbeitung ein Erfolg ist (S309) und gibt eine Authentizitäts-Erfolgs-Antwort an den Hoch-Niveau-Apparat 30 zurück (S310). Dann wird der gemeinsame Key aus den gemeinsamen Key-Startparameter erzeugt, die zwischen dem Hoch-Niveau-Apparat 30 und dem Niedrig-Niveau-Apparat 40 in Schritt S308 übertragen werden (nicht gezeigt in einer Zeichnung).
  • Zwischenzeitlich bestimmt der Hoch-Niveau-Apparat 30 bis zum Empfangen der Antwort in Schritt S310, dass das Kommunikations-Gegenüber, das zur Kommunikation bzw. Verbindung in Schritt S301 angefordert wurde, ein Apparat ist, der ein geeignetes Kommunikations-Gegenüber ist, obwohl die Gültigkeitsdauer des normalen Public Key-Zertifikates verfallen ist (S311).
  • Dann arbeitet, fortfahrend mit dem Prozess, der in 16 gezeigt ist, das HTTPS-Client-Funktionsteil 31 des Hoch-Niveau-Apparates 30 als ein Management-Apparat-Client und fordert eine Erzeugung (Herstellung) eines neuen Zertifikat-Sets für den Niedrig-Niveau-Apparat 40 an, indem eine normale Zertifikat-Ausgabe-Anforderung übertragen wird, eine Apparate-Nummer, eine Key-Adresse und die MAC-Adresse des Niedrig-Niveau-Apparates 40 zu dem Zertifikat-Management-Apparat 20 (S312).
  • Die Informationen, die von dem Hoch-Niveau-Apparat 30 zu dem Zertifikat-Management-Apparat 20 übertragen werden sollen, können als Kommunikations-Gegenüber-Informationen in dem Hoch-Niveau-Apparat 30 vorher gespeichert werden, oder können von dem Niedrig-Niveau-Apparat 40 übertragen werden, nachdem eine Authentifizierung mit dem Rescue Public Key-Zertifikat erfolgreich war. Obwohl das Zertifikat-Set entsprechende Zertifikate enthält und den eigenen Key (wie in 12 gezeigt), kann das Root Key-Zertifikat des Hoch-Niveau-Apparates aus dem Zertifikat-Set weggelassen werden, und zwar in dem Fall einer Ein-Weg-Authentifizierung. Ähnlich zu dem Kommunikationen bzw. Verbindungen zwischen dem Hoch-Niveau-Apparat 20 und dem Niedrig-Niveau-Apparat 40 können der Hoch-Niveau-Apparat 30 und der Zertifikat-Management-Apparat 20 kommunizieren, indem eine Authentifizierungs-Verarbeitung mit einem normalen Public Key-Zertifikat in Übereinstimmung mit einem SSL-Protokoll bzw. Zertifikat ausgeführt wird (obwohl in der Zeichnung nicht gezeigt), sodass eine sicherer Kommunikations- bzw. Verbindungsweg erhalten werden kann.
  • Der Zertifikat-Management-Apparat 20 erzeugt das Zertifikat-Set und eine Zertifikat-Set-Anforderung (S313). Das Public Key-Zertifikat, das in dem Zertifikat-Set enthalten ist, weist eine Gültigkeitsdauer auf, die noch nicht verfallen ist. Zum Beispiel kann die Gültigkeitsdauer so eingestellt werden, um von dem Punkt der Erzeugung des Zertifikat-Sets zu beginnen und zu enden, nachdem Ablauf einer vorbestimmten Dauer.
  • Da der Zertifikat-Management-Apparat 20 eine Version des normalen Root Key-Zertifikates des Niedrig-Niveau-Apparates handhabt, das durch den Hoch-Niveau-Apparat 30 gespeichert ist, ist der Zertifikat-Management-Apparat 20 in der Lage, ein normales Public Key-Zertifikat mit einer digitalen Unterschrift zu erzeugen, die mit dem normalen Authentifizierungs-Root Key des Niedrig-Niveau-Apparates verifiziert werden kann. Das normale Public Key-Zertifikat enthält Identifikations-Informationen des Niedrig-Niveau-Apparates 40. Wie zum Beispiel die Apparate Nr. des Niedrig-Niveau-Apparates 40. In diesem Prozess kann der Zertifikat-Management-Apparat 20 verifizieren, ob das Ausgabeziel des normalen Public Key-Zertifikates ein geeigneter Apparat ist, in dem die Informationen (IP-Adresse etc.), die von dem Hoch-Niveau-Apparat 30 empfangen werden, mit Informationen verglichen werden, die durch den Zertifikat-Management-Apparat 20 selbst gehandhabt werden. Wie oben beschrieben, kann ein eigener Root Key, der für die digitale Unterschrift verwendet wird, neu erzeugt werden, um dadurch das Root Key-Zertifikat gleichzeitig zu aktualisieren. Die neu erzeugten Zertifikate und Key(s) werden durch das Zertifikat-Managementteil 26 auf dieselbe Art gespeichert und gehandhabt wie die früheren Zertifikate und Ähnliches.
  • Anschließend nach der Übertragung der Anforderung in Schritt S312 überträgt der Hoch-Niveau-Apparat 30 eine Kommunikationsanforderung an den Zertifikat-Management-Apparat 20, im Wesentlichen mit einem Zeitablauf, zu dem die Erzeugung des Zertifikat-Sets abgeschlossen ist, und fragt, ob es irgendwelche Anforderungen von dem Zertifikat-Management-Apparat 20 gibt (S314). Wenn der Prozess von Schritt S313 abgeschlossen ist, überträgt der Zertifikat-Management-Apparat 20 als Antwort auf die Kommunikationsanforderung von dem Hoch-Niveau-Apparat 30 die Zertifikat-Set-Anforderung, das neue Zertifikat-Set und die IP-Adresse und MAC-Adresse des Niedrig-Niveau-Apparates 40 (in welchem das neue Zertifikat-Set gespeichert werden soll) an den Hoch-Niveau-Apparat 30 (S315). Das heißt, der Hoch-Niveau-Apparat 30 erhält die Zertifikat-Set-Anforderung zusammen mit einem neuen Zertifikat-Set, das in dem Niedrig-Niveau-Apparat 40 gespeichert werden soll.
  • Der Hoch-Niveau-Apparat 30 überträgt bis zum Empfangen der Zertifikat-Set-Anforderung eine Zertifikat-Update-Anforderung, und das neue Zertifikat-Set an eine definierte IP-Adresse (in diesem Beispiel eine Rescue-URL) (S316). Vor einer Übertragung des neuen Zertifikat-Sets an den Niedrig-Niveau-Apparat 40, kann der Hoch-Niveau-Apparat 30 eine MAC-Adresse von dem Übertragungsziel erhalten, um die erhaltene MAC- Adresse mit der MAC-Adresse zu vergleichen, die in der Zertifikat-Set-Anforderung bezeichnet ist.
  • Zwischenzeitlich sendet in den Niedrig-Niveau-Apparat 40 das HTTPS-Server-Funktionsteil 42 die empfangene Zertifikat-Update-Anforderung an das Anforderung-Managementteil 44. Dann befiehlt das Anforderungs-Managementteil 44 dem Zertifikat-Aktualisierungsteil 48 ein Zertifikat-Update-Verfahren auszuführen, um dadurch die normalen Authentifizierungs-Informationen, die in dem Zertifikat-Speicherteil 45 gespeichert sind, mit den Inhalten des empfangenen neuen Zertifikat-Sets zu vergleichen (S317). Dann gibt der Niedrig-Niveau-Apparat 40 eine Zertifikat-Update-Anforderungs-Antwort, die bezeichnend für die Udpate-Ergebnisse des Hoch-Niveau-Apparates 30 sind zurück (S18). Basierend auf der Zertifikat-Update-Anforderung-Antwort gibt der Hoch-Niveau-Apparat 30 eine Zertifikat-Set-Anforderung-Antwort als Antwort auf die Zertifikat-Set-Anforderung von dem Zertifikat-Management-Apparat 20 zurück (S319). Dann wird der Prozess vorübergehend abgeschlossen.
  • Es ist vorzuziehen, die Kommunikationen bzw. Verbindungen zwischen dem Hoch-Niveau-Apparat 30 und dem Niedrig-Niveau-Apparat 40 vorübergehend abzubrechen und in Schritt S316 eine Verbindung wieder einzurichten, indem wieder eine Kommunikationsanforderung an die Rescue-URL des Niedrig-Niveau-Apparates übertragen wird.
  • Nachdem die Aktualisierung der Zertifikate abgeschlossen ist, weist der Niedrig-Niveau-Apparat 14 das HTTPS-Client-Funktionsteil auf, das als ein Hoch-Niveau-Apparat-Client arbeiten soll und überträgt eine Kommunikationsanforderung an die normale URL des Hoch-Niveau-Apparates 30 (obwohl in dem Flussdiagramm von 13 und 14 nicht beschrieben). Dann überträgt der Niedrig-Niveau-Apparat 40 eine Zertifikat-Update-Ergebnis-Benachrichtigung, die für die Update-Prozess-Ergebnisse zusammen mit den Versions-Informationen des aktualisierten Zertifikat-Sets, eine Apparate-Nr. und eine IP-Adresse bezeichnend ist (S321). Der Hoch-Niveau-Apparat 30 gibt eine Zertifikat-Update-Ergebnis-Benachrichtigungsantwort als Antwort auf die Benachrichtigung von dem Niedrig-Niveau-Apparat 40 zurück (S322). Bei dieser Kommunikation bzw. Verbindung wird die Authentifizierungs-Verarbeitung mit einem normalen Public Key-Zertifikat ausgeführt, in welcher die Authentifizierungs-Verarbeitung erfolgreich sein wird, indem das Zertifikat, das in dem neuen Zertifikat-Set enthalten ist, verwendet wird.
  • Der Hoch-Niveau-Apparat 30 überträgt bis zum Empfang der Benachrichtigung in Schritt S321 eine Kommunikationsanforderung (Niedrig-Niveau-Apparat-Neusuche-Anforderung) an die normale URL des Niedrig-Niveau-Apparates 40 zum Neusuchen des Niedrig-Niveau-Apparates 40 (S331). Das Neusuchen wird ausgeführt, um zu bestätigen, dass die Authentifizierung, die das normale Public Key-Zertifikat verwendet, erfolgreich ausgeführt werden kann und dass eine geeignete Kommunikation bzw. Verbindung in einem Fall erreicht werden kann, in dem eine Kommunikation von der Seite des Hoch-Niveau-Apparates 30 angefordert wird. Der Niedrig-Niveau-Apparat 40 gibt eine Neusuchen-Antwort des Niedrig-Niveau-Apparates als Antwort auf die Anforderung an den Hoch-Niveau-Apparat 30 zurück (S332).
  • Der Hoch-Niveau-Apparat 30 bestimmt, bis zum Empfangen der Neusuchen-Antwort, dass das Zertifikat-Update ein Erfolg ist, und dass das normale Public Key-Zertifikat mit einer unbegrenzten Gültigkeitsdauer erfolgreich in dem Niedrig-Niveau-Apparat 40 gespeichert ist, um dadurch die Zertifikat-Update-Ergebnis-Benachrichtigung und zusätzliche Informationen zu dem Zertifikat-Management-Apparat 20 zu übertragen und den Erfolg des Update-Prozesses zu berichten (S333). Dann gibt als Antwort auf die Zertifikat-Update-Ergebnis-Benachrichtigung der Zertifikat-Management-Apparat 20 eine Zertifikat-Update-Ergebnis-Benachrichtigungs-Antwort an den Hoch-Niveau-Apparat 30 zurück.
  • Entsprechend zu dem Kommunikations- bzw. Datenübertragungssystem, das in 1 und 2 gezeigt ist, kann durch Ausführung der oben beschriebenen Verfahren das Zertifikat des Niedrig-Niveau-Apparates 40 aktualisiert werden und die Authentifizierungs-Verarbeitung kann erreicht werden, selbst in einem Fall, in dem die Gültigkeitsdauer des Public Key-Zertifikates in den normalen Authentifizierungs-Informationen des Niedrig-Niveau-Apparates 40 verfallen ist.
  • Beim Ausführen der oben beschriebenen Verfahren mit dem Hoch-Niveau-Apparat 30 und dem Niedrig-Niveau-Apparat 40 wird in einem normalen Fall der Anfrage einer Kommunikation bzw. Verbindung die Authentifizierungs-Verarbeitung ausgeführt, indem das normale Public Key-Zertifikat verwendet wird und das Kommunikations-Gegenüber identifiziert wird, um dadurch einen sicheren Kommunikationsweg entsprechend eines SSL-Protokolls bzw. Zertifikats zu erhalten. Zwischenzeitlich wird in einem Fall, in dem eine Authentifizierung, die das normale Public Key-Zertifikat verwendet, fehlschlägt, die Authentifizierungs-Verarbeitung ausgeführt, in dem das Rescue Public Key-Zertifikat verwendet wird, was eine längere Gültigkeitsdauer als das des normalen Public Key- Zertifikates aufweist und die normale Authentifizierungs-Informationen aktualisiert werden (wenn die Authentifizierung, die das Rescue Public Key-Zertifikat verwendet, erfolgreich ist), indem ein neues Zertifikat-Set von dem Hoch-Niveau-Apparat 30 zu dem Niedrig-Niveau-Apparat 40 übertragen wird, um dadurch sicher, automatisch und leicht eine nicht verfallbare Gültigkeitsdauer für das normale Public Key-Zertifikat einzustellen, um eine Authentifizierung zu ermöglichen.
  • Obwohl das Rescue Public Key-Zertifikat schlechter sein kann als das normale Public Key-Zertifikat unter dem Aspekt der Sicherheit, kann das Rescue Public Key-Zertifikat immer noch einen beträchtlichen Grad an Sicherheit bereitstellen. Weiter kann durch Vorbereiten des Rescue Public Key-Zertifikats zusammen mit dem normalen Public Key-Zertifikat ein sicherer Verbindungsweg, der einen gemeinsamen Key-Code verwendet, aufrechterhalten werden, selbst wenn die Gültigkeitsdauer des normalen Public Key-Zertifikates verfällt, solange wie die Gültigkeitsdauer des Rescue Public Key-Zertifikates nicht verfallen ist.
  • Weiter kann mit der Authentifizierungs-Verarbeitung, die das Rescue Public Key-Zertifikat verwendet, das neue Zertifikat-Set davor bewahrt werden, in einem ungeeigneten Apparat gespeichert zu werden, da die Bestimmung des Zertifikat-Sets vor einer Übertragung verifiziert werden kann. Im Fall einer Zwei-Wege-Authentifizierung kann der Niedrig-Niveau-Apparat 40 davor bewahrt werden, ein ungeeignetes (betrügerisches) Zertifikat als die normalen Authentifizierungs-Informationen zu speichern, da der Niedrig-Niveau-Apparat 40 die Authentizität des Übertragungsursprungs des neuen Zertifikat-Sets verifizieren kann. Weiter kann, selbst in einem Fall, in welchem eine Authentifizierung, die das normale Public Key-Zertifikat benutzt nicht ausgeführt werden kann, das neue Zertifikat-Set über einen sicheren Kommunikationsweg entsprechend des SSL-Protokolls bzw. Zertifikats durch die Authentifizierung übertragen werden, die das Rescue Public Key-Zertifikat verwendet, und dadurch kann eine Sicherheit aufrechterhalten werden, ohne den Inhalt des neuen Zertifikat-Sets an eine dritte Person durchsickern zu lassen.
  • Da der Niedrig-Niveau-Apparat 40 nur eine Zertifikat-Update-Anforderung von einem Kommunikations-Gegenüber akzeptieren kann, der mit dem Rescue Public Key-Zertifikat authentifiziert ist, können auf andere Informationen als die Zertifikat-Update-Informationen nur über einen entsprechenden Kommunikations-Gegenüber, der mit dem normalen Public Key-Zertifikat authentifiziert wird, zugegriffen werden. Daher kann, selbst in einem unwahrscheinlichen Fall, in dem eine dritte Person in betrügerischer Weise den eigenen Rescue Key innerhalb der Gültigkeitsdauer des Rescue Public Key-Zertifikates erhält, wichtige Informationen des Niedrig-Niveau-Apparates 30 davor bewahrt werden, durch die dritte Person zugegriffen zu werden.
  • Da das Public Key-Zertifikat automatisch aktualisiert werden kann, entsprechend der oben beschriebenen Ausführungsform der vorliegenden Erfindung, ist es besonders effektiv, wenn der Kommunikations- bzw. Datenübertragungsapparat des Kommunikations-Gegenübers ein Apparat ist, der nicht durch den Operateur aktualisiert werden kann, an der Stelle, wo der Apparat installiert ist (z. B. Set-Topbox für Kabel-TV oder ein Bilderzeugungsapparat, der einer entfernten Wartung ausgesetzt ist). [Eine andere (Variation) einer Ausführungsform entsprechend der vorliegenden Erfindung].
  • Bei der oben beschriebenen Ausführungsform der vorliegenden Erfindung werden die normalen Authentifizierungs-Informationen des Niedrig-Niveau-Apparates 40 aktualisiert, wenn die Authentifizierungs-Verarbeitung erfolgreich ausgeführt wird, und zwar in einem Fall, in dem die Authentifizierungs-Verarbeitung, die das normale Public Key-Zertifikat verwendet, aufgrund des Verfalls der Gültigkeitsdauer des normalen Public Key-Zertifikates nicht ausgeführt werden kann. Bei der oben beschriebenen Ausführungsform der vorliegenden Erfindung kann das oben beschriebene System mehrere Niedrig-Niveau-Apparate 40 umfassen, die mit einem einzelnen Hoch-Niveau-Apparat 30 verbunden/abgetrennt sind. Daher kann das Handhaben des Niedrig-Niveau-Apparates(e) 40 schwieriger sein, verglichen mit dem Handhaben eines einzelnen Niedrig-Niveau-Apparates 30 und ein Auftreten eines Verfalls der Gültigkeitsdauer des normalen Public Key-Zertifikates in dem Niedrig-Niveau-Apparat(en) 40 ist wahrscheinlicher als in dem Hoch-Niveau-Apparat 30. Entsprechend werden bei der oben beschriebenen Ausführungsform der vorliegenden Erfindung die normalen Authentifizierungs-Informationen für den Niedrig-Niveau-Apparat 40 eher aktualisiert als die des Hoch-Niveau-Apparates 30.
  • Jedoch kann ein Verfall der Gültigkeitsdauer des normalen Public Key-Zertifikates für den Hoch-Niveau-Apparat 30 auftreten. In einem Fall, in welchem der Hoch-Niveau-Apparat 30 den Verfall realisiert, kann der Hoch-Niveau-Apparat 30 ein Update der normalen Authentifizierungs-Informationen entsprechend des Hoch-Niveau-Apparates 30 selbst ausführen. Dieser Fall ist oben beschrieben als eine Folgeversion in Bezug auf 17.
  • In diesem Fall weist der Hoch-Niveau-Apparat 30 das HTTPS-Client-Funktionsteil 31 auf, das als der CA-Client (Management-Apparat-Client) arbeitet, und erfordert eine Erzeugung eines neuen Zertifikat-Sets für den Hoch-Niveau-Apparat 30 selbst durch Übertragen einer normalen Zertifikat-Ausgabe-Anforderung und einer Apparate-Nr. des Hoch-Niveau-Apparates selbst zu dem Zertifikat-Management-Apparat 20 an (S401). Hier kann das normale Public Key-Zertifikat des Hoch-Niveau-Apparates 30 nicht für eine Zwei-Wege-Authentifizierung verwendet werden, da die Gültigkeitsdauer des normalen Public Key-Zertifikats des Hoch-Niveau-Apparates 30 verfallen ist. Entsprechend greift der Hoch-Niveau-Apparat 30 auf die Rescue-URL des Zertifikat-Management-Apparates 20 zu, um das Rescue Public Key-Zertifikat für eine Authentifizierung zu verwenden. In einem Fall, in welchem der Hoch-Niveau-Apparat 30 nur eine Authentizität des Zertifikat-Management-Apparates 20 verifiziert, kann eine Authentifizierung ausgeführt werden, die das normale Public Key-Zertifikat verwendet.
  • Der Zertifikat-Management-Apparat 20 erzeugt bis zum Empfang der Anforderung von Schritt S401 ein Zertifikat-Set und eine Zertifikat-Set-Anforderung (S402). Das Public Key-Zertifikat, das in dem Zertifikat-Set enthalten ist, weist eine Gültigkeitsdauer auf, die unverfallbar ist.
  • Anschließend an eine Übertragung der Anforderung in Schritt S401 überträgt der Hoch-Niveau-Apparat 30 eine Kommunikationsanforderung an den Zertifikat-Management-Apparat 20, im Wesentlichen bei einem Zeitablauf, in dem die Erzeugung des Zertifikat-Sets abgeschlossen ist und fragt an, ob es irgendeine Anforderung von dem Zertifikat-Management-Apparat 20 gibt (S403). Wenn der Prozess von Schritt S402 abgeschlossen ist, überträgt der Zertifikat-Management-Apparat 20 als Antwort auf die Kommunikationsanforderung von dem Hoch-Niveau-Apparat 30 die Zertifikat-Set-Anforderung und das neue Zertifikat-Set zu dem Hoch-Niveau-Apparat 30 (S404).
  • Der Hoch-Niveau-Apparat 30 aktualisiert bis zum Empfang der Anforderung die normalen Authentifizierungs-Informationen, die in dem Zertifikat-Speicherteil 45 enthalten sind, mit den Inhalten des empfangenen neuen Zertifikat-Sets (S405) und gibt eine Zertifikat-Update-Anforderungs-Antwort an dem Zertifikat-Management-Apparat 20 zurück, die bezeichnend für die Ergebnisse des Update-Prozesses sind (S406). Der Zertifikat-Management-Apparat 20 gibt einen Antwort(Benachrichtigung)-Berichts-Empfang der Zertifikat-Update-Anforderungs-Antwort an den Hoch-Niveau-Apparat 40 zurück (S407).
  • Entsprechend können, ähnlich zu dem Niedrig-Niveau-Apparat 40, die normalen Authentifizierungs-Informationen des Hoch-Niveau-Apparates 30 aktualisiert werden, indem die oben beschriebenen Prozesse ausgeführt werden.
  • Außerdem kann, obwohl die oben beschriebene Ausführungsform entsprechend der vorliegenden Erfindung als ein Fall beschrieben wurde, in welchem die Authentifizierung mit dem normalen Public Key-Zertifikat ausgeführt wird, wenn der Hoch-Niveau-Apparat 30 eine Kommunikation mit dem Niedrig-Niveau-Apparat 40 anfordert, der Hoch-Niveau-Apparat 30 periodisch eine Kommunikation bzw. Verbindung mit entsprechenden Niedrig-Niveau-Apparaten 40 anfordern und eine Suche ausführen, in Bezug auf den bzw. die Niedrig-Niveau-Apparat(e) 40. Mit diesem Ablauf kann bzw. können ein Niedrig-Niveau-Apparat(e) 40, der bzw. die ein normales Public Key-Zertifikat mit einer verfallenen Gültigkeitsdauer aufweisen, periodisch geprüft werden und eine Aktualisierung kann ausgeführt werden, wann immer ein Niedrig-Niveau-Apparat 40, der ein normales Public Key-Zertifikat mit einer verfallenen Gültigkeitsdauer aufweist, gefunden werden. Entsprechend kann jeder Apparat in diesem Kommunikations- bzw. Datenübertragungssystem fortfahren, eine Authentifizierung eines Kommunikations-Gegenübers zu verifizieren.
  • Weiter kann die Suche nicht nur für die IP-Adresse des Kommunikations-Gegenüber durchgeführt werden, die in dem Speicher des Hoch-Niveau-Apparates 30 gespeichert ist, sondern kann für alle IP-Adressen durchgeführt werden, die einen vorbestimmten Bereich abdecken. Daher wird, selbst wenn ein neuer Niedrig-Niveau-Apparat 40 mit dem Kommunikations- bzw. Datenübertragungssystem verbunden wird, der Hoch-Niveau-Apparat 30 in der Lage sein, den neuen Niedrig-Niveau-Apparat 40 automatisch zu detektieren und eine Authentifizierung zu ermöglichen, die das normale Public Key-Zertifikat verwendet. Entsprechend kann, selbst wenn die Gültigkeitsdauer des normalen Public Key-Zertifikates, das ursprünglich in dem Niedrig-Niveau-Apparat 40 während einer Herstellung gespeichert ist, verfällt, bevor es mit dem Kommunikations- bzw. Datenübertragungssystem verbunden wird, ein neues normales Public Key-Zertifikat für den Niedrig-Niveau-Apparat 40 durch den Zertifikat-Management-Apparat 20 erzeugt werden und in den Niedrig-Niveau-Apparat 40 gespeichert werden, wenn die Authentifizierung, die das Rescue Public Key-Zertifikat verwendet, ein Erfolg ist.
  • Da die Aktualisierung des normalen Public Key-Zertifikates ausgeführt wird, sobald der Verfall der Gültigkeitsdauer durch die Suche detektiert wird, kann die Suche als Teil einer Aktualisierungsoperation des Niedrig-Niveau-Apparates 40 betrachtet werden.
  • Obwohl die oben beschriebene Ausführungsform entsprechend der vorliegenden Erfindung als ein Fall beschrieben wurde, in welchem der Hoch-Niveau-Apparat 30 eine Kommunikation bzw. Verbindung mit dem Niedrig-Niveau-Apparat 40 anfordert, kann der Niedrig-Niveau-Apparat 40 ebenfalls alternativ eine Kommunikation bzw. Verbindung mit dem Hoch-Niveau-Apparat 30 anfordern.
  • Entsprechend wird dieser Fall als Nächstes als eine Folgeoperation mit Bezug auf 18 bis 20 beschrieben. Es sollte beachtet werden, dass diese Sequenzoperation verglichen mit der von 15 vereinfacht ist.
  • In dem Beispiel, das in 18 gezeigt ist, fordert der Niedrig-Niveau-Apparat 40 eine Kommunikation bzw. Verbindung mit dem Hoch-Niveau-Apparat 30 in einem Fall zur Ausführung einer Authentifizierung mit dem normalen Public Key-Zertifikat an und in einem Fall des Ausführens einer Authentifizierung mit dem Rescue Public Key-Zertifikat.
  • Zuerst überträgt der Niedrig-Niveau-Apparat 40 eine Kommunikations- bzw. Verbindungsanforderung an die normale URL des Hoch-Niveau-Apparates 40 zum Einrichten einer normalen Kommunikation mit dem Hoch-Niveau-Apparat 30 (S501). Dann wird eine Authentifizierung ausgeführt, wobei das normale Public Key-Zertifikat zwischen dem Hoch-Niveau-Apparat 30 und dem Niedrig-Niveau-Apparat 40 verwendet wird (S502).
  • Obwohl die Authentifizierungs-Verarbeitung durch eine Zwei-Wege-Authentifizierung ausgeführt werden kann (wie in 22 gezeigt) oder einer Ein-Weg-Authentifizierung, muss der Hoch-Niveau-Apparat 30 wenigstens eine Authentizität des Niedrig-Niveau-Apparates 40 verifizieren, indem das Public Key-Zertifikat des Niedrig-Niveau-Apparates 40 verwendet wird. In diesem Beispiel kann der Prozess leicht unterschiedlich von dem Fall sein, der in 24 gezeigt ist, da der Niedrig-Niveau-Apparat 40 den Client entspricht in einem Fall einer Ein-Wege-Authentifizierung. Jedoch ist er derselbe, und zwar dahingehend, dass der Niedrig-Niveau-Apparat 40 das Public Key-Zertifikat zusammen mit der Zufallszahl übermittelt, die mit ihrem eigenen Key zu dem Hoch-Niveau-Apparat 30 verKeyt ist, und dass der Hoch-Niveau-Apparat 30 eine Authentifizierung ausführt, indem die Zufallszahl entschlüsselt wird, nachdem die Authentizität des empfangenen Public Key-Zertifikates verifiziert wurde.
  • Dann, wenn der Hoch-Niveau-Apparat 30 bestimmt, dass die Authentifizierungs-Verarbeitung in Schritt S502 aufgrund des Verfalls der Gültigkeitsdauer des normalen Public Key-Zertifikats ein Fehlschlag ist (S503), überträgt der Hoch-Niveau-Apparat 30 eine Authentifizierung-Fehlschlag-Antwort zu dem Niedrig-Niveau-Apparat 40 (S504). Dann überträgt der Niedrig-Niveau-Apparat 40 bis zum Empfangen der Antwort eine Kommunikationsanforderung an die Rescue-URL des Hoch-Niveau-Apparates 30 (S505).
  • Dann wird die Authentifizierungs-Verarbeitung zwischen dem Hoch-Niveau-Apparat 30 und dem Niedrig-Niveau-Apparat 40 ausgeführt (S506). Wenn der Hoch-Niveau-Apparat 30 bestimmt, dass die Authentifizierungs-Verarbeitung ein Erfolg ist (S507), bestimmt der Hoch-Niveau-Apparat 30 ähnlich zu Schritt S311 von 15, dass der Niedrig-Niveau-Apparat 40 ein authentisches Kommunikations-Gegenüber ist, obwohl die Gültigkeitsdauer des normalen Public Key-Zertifikates verfallen ist (S508). Dann wird der Prozess, der in 16 gezeigt ist, zur Aktualisierung der normalen Authentifizierungs-Informationen des Niedrig-Niveau-Apparates 40 ausgeführt.
  • 19 zeigt ein Beispiel, in dem eine Kommunikation bzw. Verbindung von dem Niedrig-Niveau-Apparat 40 zu dem Hoch-Niveau-Apparat 30 angefordert wird, wenn die Authentifizierungs-Verarbeitung ausgeführt wird, indem das normale Public Key-Zertifikat verwendet wird, und in welchem die Kommunikation bzw. Verbindung durch den Hoch-Niveau-Apparat 30 zu dem Niedrig-Niveau-Apparat 40 angefordert wird, wenn die Authentifizierungs-Verarbeitung ausgeführt wird, indem das Rescue Public Key-Zertifikat verwendet wird.
  • In diesem Beispiel entsprechen Schritte S511 bis S514 den Schritten S501 bis S504 von 18. In diesem Beispiel jedoch überträgt der Hoch-Niveau-Apparat 30 eine Anforderung an die Rescue-URL des Niedrig-Niveau-Apparates 40, nachdem eine Authentifizierungs-Fehlschlag-Antwort an den Niedrig-Niveau-Apparat 40 zurückgegeben wurde (S515). Dann wird die Authentifizierungs-Verarbeitung, die das Rescue Public Key-Zertifikat verwendet, zwischen dem Hoch-Niveau-Apparat 30 und dem Niedrig-Niveau-Apparat 40 ausgeführt (S516). Wenn der Hoch-Niveau-Apparat 30 bestimmt, dass die Authentifizierungs-Verarbeitung ein Erfolg ist (S517), bestimmt der Hoch-Niveau-Apparat 30 ähnlich zum Schritt S311 von 15, dass der Niedrig-Niveau-Apparat 40 ein authentisches Kommunikations-Gegenüber ist, obwohl die Gültigkeitsdauer des normalen Public Key-Zertifikates verfallen ist (S518). Dann wird der Prozess, der in 13 gezeigt ist, zur Aktualisierung der normalen Authentifizierungs-Informationen des Niedrig-Niveau-Apparates 40 ausgeführt.
  • 20 zeigt ein Beispiel, in welchem eine Kommunikation bzw. Verbindung durch den Hoch-Niveau-Apparat 30 für den Niedrig-Niveau-Apparat 40 angefordert wird, wenn die Authentifizierungs-Verarbeitung ausgeführt wird, indem das normale Public Key-Zertifikat verwendet wird, und in welchem die Kommunikation bzw. Verbindung durch den Niedrig-Niveau-Apparat 40 für den Hoch-Niveau-Apparat 30 angefordert wird, wenn die Authentifizierungs-Verarbeitung ausgeführt wird, indem das Rescue Public Key-Zertifikat verwendet wird.
  • Der Hoch-Niveau-Apparat 30 überträgt eine Kommunikationsanforderung an die normale URL des Niedrig-Niveau-Apparates 40 zum Einrichten von normalen Kommunikationen bzw. Verbindungen mit dem Niedrig-Niveau-Apparat 40 (S521). Dann wird eine Authentifizierung, die das normale Public Key-Zertifikat verwendet, zwischen dem Hoch-Niveau-Apparat 30 und dem Niedrig-Niveau-Apparat 40 ausgeführt (S522). Dann kann die Authentifizierungs-Verarbeitung durch eine Zwei-Wege-Authentifizierung ausgeführt werden (wie in 22 gezeigt) oder eine Ein-Weg-Authentifizierung (wie in 24 gezeigt).
  • Dann überträgt, wenn der Hoch-Niveau-Apparat 30 bestimmt, dass die Authentifizierungs-Verarbeitung in Schritt S522 aufgrund des Verfalls der Gültigkeitsdauer des normalen Public Key-Zertifikates ein Fehlschlag ist (S523), der Hoch-Niveau-Apparat 30 eine Authentifizierungs-Fehlschlag-Antwort an den Niedrig-Niveau-Apparat 40 (S524). Dann überträgt der Niedrig-Niveau-Apparat 40 bis zum Empfangen der Antwort eine Kommunikationsanforderung an die Rescue-URL des Hoch-Niveau-Apparates 30 (S525). Dann wird die Authentifizierungs-Verarbeitung zwischen dem Hoch-Niveau-Apparat 30 und dem Niedrig-Niveau-Apparat 40 ausgeführt (S526). Wenn der Hoch-Niveau-Apparat 30 bestimmt, dass die Authentifizierungs-Verarbeitung ein Erfolg ist (S527), bestimmt der Hoch-Niveau-Apparat 30 ähnlich zum Schritt S311 von 15, dass der Niedrig-Niveau-Apparat 40 ein authentisches Kommunikations-Gegenüber ist, obwohl die Gültigkeitsdauer des normalen Public Key-Zertifikates verfallen ist (S528). Dann wird der Prozess, der in 16 gezeigt ist, zum Aktualisieren der normalen Authentifizierungs-Informationen des Niedrig-Niveau-Apparates 40 ausgeführt.
  • Entsprechend können dieselben Vorteile ebenfalls mit dem Arbeitsablauf entsprechend den Ausführungsformen der vorliegenden Erfindung erzielt werden, die in 18 bis einschließlich 20 gezeigt sind, in welchen der Niedrig-Niveau-Apparat 40 als ein authentisches Kommunikations-Gegenüber bestimmt werden kann, selbst wenn die Gültigkeitsdauer des normalen Public Key-Zertifikates verfallen ist, unter der Bedingung, dass die Authentifizierung, die das Rescue Public Key-Zertifikat verwendet, ein Erfolg ist. Hier erhält der Hoch-Niveau-Apparat 30 ein neues Zertifikat-Set und überträgt das neue Zertifikat-Set zu dem Niedrig-Niveau-Apparat 30, um es dem Niedrig-Niveau-Apparat 40 zu ermöglichen, seine normalen Authentifizierungs-Informationen zu aktualisieren. Dadurch kann das normale Public Key-Zertifikat sicher, automatisch und leicht eingestellt werden, um eine effiziente Authentifizierung zu erzielen.
  • Der Apparat zum Übertragen der Kommunikationsanforderung kann entsprechend der Umstände abgewandelt werden. Zum Beispiel kann der Hoch-Niveau-Apparat 30 eine Kommunikationsanforderung an die Rescue-URL des Niedrig-Niveau-Apparates 40 übertragen, wenn eine Authentifizierung, die das normale Public Key-Zertifikat verwendet, fehlschlägt, oder der Niedrig-Niveau-Apparat 40 kann eine Kommunikationsanforderung an die Rescue-URL des Hoch-Niveau-Apparates 30 übertragen, wenn er eine Authentifizierungs-Fehlschlag-Antwort von dem Hoch-Niveau-Apparat 30 empfangt. Daher können die Prozesse danach ausgeführt werden, unabhängig davon, welcher Apparat ursprünglich eine Kommunikationsanforderung an die normale URL des Kommunikations-Gegenübers überträgt.
  • Bei der Übertragung des neuen Zertifikat-Sets (d. h. Schritt S316 von 16) kann der Niedrig-Niveau-Apparat 40 eine Kommunikationsanforderung zu dem Hoch-Niveau-Apparat 30 übertragen und der Hoch-Niveau-Apparat 40 kann dann eine Zertifikat-Update-Anforderung als Antwort auf die Kommunikationsanforderung von dem Niedrig-Niveau-Apparat 40 übertragen.
  • Bei den oben beschriebenen Ausführungsformen der vorliegenden Erfindung werden das normale Public Key-Zertifikat und das Rescue Public Key-Zertifikat beide durch eine CA desselben Anbieters ausgegeben. Jedoch ist es zu bevorzugen, eine hochzuverlässige Dritt-Partei CA anzufordern, um das normale Public Key-Zertifikat anzufordern. Obwohl die normale Public Key-Zertifikate, die durch einen Dritt-Anbieter CA oft eine größere Gültigkeitsdauer aufweisen, würde die kurze Gültigkeitsdauer kein Problem darstellen, da das normale Public Key-Zertifikat sicher, automatisch und einfach aktualisiert werden kann, selbst wenn die Gültigkeitsdauer des normalen Public Key-Zertifikates verfallen ist. Durch Einsetzen der Authentifizierung, wobei das Public Key-Zertifikat, das durch eine hochvertrauenswürdige CA einer Dritt-Parteiorganisation ausgegeben wird, kann das Kommunikations- bzw. Datenübertragungssystem entsprechend einer Ausführungsform der vorliegenden Erfindung effizient betrieben werden.
  • In diesem Fall kann das Ausgeben des normalen Public Key-Zertifikates direkt von dem Hoch-Niveau-Apparat 30 an die CA der Dritt-Organisation angefordert werden, oder kann von dem Hoch-Niveau-Apparat 30 zu der CA der Dritt-Organisation über den Zertifikat-Management-Apparat 20 angefordert werden.
  • In der Zwischenzeit können der Anbieter des Hoch-Niveau-Apparates 30 und/oder des Niedrig-Niveau-Apparates 40 eine CA durch sie selbst einrichten, um die Gültigkeitsdauer von ihren Rescue Public Key-Zertifikaten frei einzustellen. Jedoch ist es, da die Gültigkeitsdauer des Rescue Public Key-Zertifikates als eine relativ lange Dauer eingestellt wird, vorzuziehen, das Rescue Public Key-Zertifikat unter einen strengen Geheimhaltung zu halten, um zu verhindern, dass der eigene Rescue Root Key von einer unautorisierten Person erhalten wird und eine sichere Kommunikation bzw. Verbindung aufrechtzuerhalten. Ein Beispiel zum Herstellen einer sicheren Kommunikation bzw. Verbindung ist es, einen Zertifikat-Management-Apparat einzusetzen, auf den nicht von außerhalb zugegriffen werden kann (d. h. einen Zertifikat-Management-Apparat, der mit einer Installation zum Speichern des Rescue Public Key-Zertifikates nur über eine bestimmte Kommunikationsleitung kommunizieren kann).
  • Der Zertifikat-Management-Apparat 20 kann in Übereinstimmung mit dem Zielapparat separat bereitgestellt werden, zu welchem das Zertifikat ausgegeben wird (d. h. ein Zertifikat-Management-Apparat zum Ausgeben eines Zertifikates für einen Hoch-Niveau-Apparat, ein Zertifikat-Management-Apparat zum Ausgeben eines Zertifikates für einen Niedrig-Niveau-Apparat und ein Zertifikat-Management-Apparat zum Ausgeben eines Zertifikates für einen anderen Zertifikat-Management-Apparat).
  • Das normale Public Key-Zertifikat und das Rescue Public Key-Zertifikat können durch getrennte CAs ausgegeben werden oder können alternativ durch dieselbe CA ausgegeben werden.
  • Die oben beschriebenen Zertifikate entsprechend den Ausführungsformen der vorliegenden Erfindung werden beschrieben, und zwar einschließlich eines normalen Public Key-Zertifikates, das eine kurze Gültigkeitsdauer aufweist und eines Rescue Public Key-Zertifikates, das eine lange Gültigkeitsdauer aufweist. Jedoch kann das Erste einem Zertifikat entsprechen, das einen hohen Sicherheitsgrad aufweist und das Letzte kann einem Zertifikat entsprechen, das einen relativ niedrigen Sicherheitsgrad aufweist.
  • Im Allgemeinen ist ein Zertifikat, das eine hohe Schaltung aufweist Gegenstand verschiedener Restriktionen (z. B. eine Anforderung für einen großen Umfang an Informationen, die hierauf beschrieben werden sollen, Export-Restriktionen, eine Anforderung für ein spezielles Authentifizierungs-Programm). Daher ist es schwierig, ein derartiges Zertifikat in jedem Apparat zum Ausführen einer Authentifizierung zu speichern. Andererseits ist ein Zertifikat, das einen niedrigen Sicherheitsgrad aufweist, nicht Gegenstand derartiger Restriktionen. Daher ist es relativ einfach, das Zertifikat in allen Apparaten zum Ausführen einer Authentifizierung zu speichern.
  • Zusätzlich gibt es Nachfragen zum Speichern des Zertifikates, das den hohen Sicherheitsgrad aufweist, in dem Apparat, der das Zertifikat mit dem niedrigen Sicherheitsgrad aufweist, entsprechend zu seinen Umgebungen, nachdem Apparat hergestellt und/oder verkauft worden ist. Obwohl verschiedene Verfahren (Techniken) zum Verbessern der Sicherheit eingesetzt werden (z. B. Anordnung der Authentifizierungs-Verarbeitung, Auswahl einer hochzuverlässigen CA), kann es einen Fall geben, in welchem ein Zertifikat für eine normale Authentifizierungs-Verarbeitung erforderlich ist, das verändert wird, um eine Sicherheit zu erhöhen (z. B. bewegen (installiert) eines Apparates von einem System zu einem anderen, welches ein Ändern der Einstellung des Apparates enthält). Weiter kann es einen Fall geben, in welchem das Authentifizierungs-Verfahren aufgrund eines Defektes geändert werden muss, der später in dem Zertifikat mit einem hohen Sicherheitsgrad gefunden wird.
  • Die oben beschriebenen Ausführungsformen der vorliegenden Erfindung können ebenfalls auf derartige Fälle angewendet werden. Zum Beispiel kann in einem Fall, in welchem eine Authentifizierung, die das Zertifikat mit dem hohen Sicherheitsgrad verwendet, fehlschlägt, das Zertifikat mit dem niedrigen Sicherheitsgrad für eine Authentifizierung verwendet werden. Wenn die Authentifizierung, die das Zertifikat mit dem niedrigen Sicherheitsgrad wählt, ein Erfolg ist, bestimmt der Hoch-Niveau-Apparat 30, dass eine Abnormalität in einer Authentifizierung der Grund für einen Fehler in der Authentifizierung ist, die das Zertifikat mit dem hohen Sicherheitsgrad verwendet. Dann erhält der Hoch-Niveau-Apparat 30 ein Zertifikat-Set einschließlich eines Zertifikates mit einem hohen Sicherheitsgrad und überträgt das Zertifikat-Set zu dem Niedrig-Niveau-Apparat 40. Dann speichert der Niedrig-Niveau-Apparat 40 das empfangene Zertifikat-Set. Entsprechend kann zum Beispiel in einem Fall, in welchem ein Apparat bewegt wird, ein Zertifikat, das der neuen Umgebung entspricht, in dem Apparat gespeichert werden, während ein wesentlicher Grad an Sicherheit aufrechterhalten wird.
  • Obwohl die Authentifizierungs-Verarbeitungen (wie in 22 oder 24 gezeigt), die den Hoch-Niveau-Apparat 30 verwenden, den Niedrig-Niveau-Apparat 40 und/oder den Zertifikat-Management-Apparat 20 oben in Übereinstimmung mit SSL (SSL-Protokoll bzw. Zertifikat) beschrieben sind, können andere Protokolle, Verfahren und Techniken alternativ eingesetzt werden.
  • Zum Beispiel kann ein TLS-Protokoll bzw. Zertifikat alternativ für die Authentifizierungs-Verarbeitung entsprechend einer Ausführungsform der vorliegenden Erfindung eingesetzt werden.
  • Obwohl der Zertifikat-Management-Apparat 20 und der Hoch-Niveau-Apparat 30 als bekannte Apparate entsprechend der oben beschriebenen Ausführungsformen der vorliegenden Erfindung beschrieben werden, können der Zertifikat-Management-Apparat 20 und der Hoch-Niveau-Apparat 30 als ein vereinter Körper bereitgestellt werden. In diesem Fall können Komponenten, wie zum Beispiel die CPU, das ROM und/oder das RAM getrennt bereitgestellt werden, um die Funktionen des Zertifikat-Management-Apparates 20 und die Funktionen des Hoch-Niveau-Apparates 30 oder der CPU, des ROM und/oder des RAM des Hoch-Niveau-Apparates 30 auszuführen, zusammen mit der Software zum Ausführen der Funktionen des Zertifikat-Management-Apparates 20.
  • In diesem Fall beinhaltet die Kommunikation bzw. Verbindung zwischen dem Zertifikat-Management-Apparat und dem Hoch-Niveau-Apparat 20, die einen vereinten Körper ausbilden, eine Prozess-zu-Prozess-Kommunikation zum Erreichen von Kommunikationen bzw. Verbindungen zwischen einem Prozess, die es einer Hardware ermöglicht, als der Zertifikat-Management-Apparat zu arbeiten, und einem Prozess, der es der Hardware ermöglicht, als der Hoch-Niveau-Apparat 30 zu arbeiten. Obwohl der Zertifikat-Management-Apparat 20 entsprechend der oben beschriebenen Ausführungsform der vorliegenden Erfindung beschrieben worden ist als ein Root Key und ein digitales Zertifikat durch ihn selbst zu erzeugen, können die Funktionen des Authentifizierungs-Key-Erzeugungsteil 24 und des Zertifikat-Ausgabeteils 25 durch einen getrennten Apparat(e) ausgeführt werden, in welchem der Zertifikat-Management-Apparat 20 den Root Key und das digitale Zertifikat von einem getrennten Apparat(en) erhält.
  • Obwohl die Authentifizierungs-Verarbeitung bei den oben beschriebenen Ausführungsformen der vorliegenden Erfindung in einem Fall eingesetzt wird, in welchem die Authentifizierungs-Verarbeitung, die das normale Public Key-Zertifikat verwendet, aufgrund des Verfalls der Gültigkeitsdauer des normalen Public Key-Zertifikates fehlschlägt, die Authentifizierungs-Verarbeitung in einem Fall eingesetzt werden, in welchem die Authentifizierungs-Verarbeitung aufgrund eines anderen Grundes bzw. Gründen fehlschlägt. Zum Beispiel kann der Prozess nach Schritt S104, gezeigt in 13, ausgeführt werden, selbst wenn das Fehlschlagen der Authentifizierungs-Verarbeitung an einem anderen Grund bzw. Gründen liegt.
  • In diesem Fall kann der Hoch-Niveau-Apparat 30 ebenfalls feststellen, dass das Gegenüber, das Kommunikationen bzw. Verbindungen angefordert hat, ein authentisches Kommunikations-Gegenüber ist, wenn die Authentifizierungs-Verarbeitung, die das Rescue Public Key-Zertifikat verwendet, erfolgreich ist. Weiter kann festgestellt werden, dass das Fehlschlagen der Authentifizierungs-Verarbeitung, die das normale Public Key-Zertifikat verwendet, aufgrund eines Defektes in dem normalen Public Key-Zertifikat in dem Niedrig-Niveau-Apparat 40 gespeichert wird. Entsprechend kann ein derartiger Effekt sofort eliminiert werden und eine Authentifizierung, die das normale Public Key-Zertifikat wird, kann nochmals zugelassen werden, indem neue Authentifizierungs-Informationen an den Niedrig-Niveau-Apparat 40 übertragen werden und Authentifizierungs-Informationen, die in dem Niedrig-Niveau-Apparat gespeichert sind, mit den neuen Authentifizierungs-Informationen aktualisiert werden.
  • Zum Beispiel kann, wenn das Fehlschlagen der Authentifizierungs-Verarbeitung zum Beispiel daran liegt, dass der gegenüberliegende Apparat als ein Kommunikations-Gegenüber entsprechend den Identifikations-Informationen in dem Public Key-Zertifikat ungeeignet ist, zum Beispiel indem keine Antwort auf eine Kommunikationsanforderung gegeben wird oder eine Antwort, die eine Nichtkonformität mit der Authentifizierungs-Verarbeitung berichtet, das Kommunikations-Gegenüber ein Apparat sein, der keine Beziehung mit dem Hoch-Niveau-Apparat 30 aufweist. Daher kann in diesem Fall ein Zugriff auf die Rescue-URL verweigert werden.
  • Weiter kann, wenn der Zertifikat-Management-Apparat einen vorher ausgegebenen Public Key aufweist oder einen eigenen Key für den Niedrig-Niveau-Apparat 30, der Zertifikat-Management-Apparat 20 den Public Key oder eigenen Key in einem Fall verwenden, in welchem die Gültigkeitsdauer des normalen Public Key-Zertifikates noch nicht verfallen ist.
  • Obwohl das Rescue Public Key-Zertifikat entsprechend der oben beschriebenen Ausführungsform der vorliegenden Erfindung Identifikations-Informationen entsprechend der jeweiligen Apparate beinhaltet, können derartige Identifikations-Informationen hiervon weggelassen werden. Entsprechend können Apparate desselben Niveaus (in dem Beispiel gezeigt in 1 und 2 gibt es Niveaus für den Zertifikat-Management-Apparat, den Hoch-Niveau-Apparat und den Niedrig-Niveau-Apparat) mit demselben Rescue Public Key-Zertifikat gespeichert werden. In diesem Fall können der Rescue Public Key und der entsprechende eigene Key, die in dem Rescue Public Key-Zertifikat enthalten sind, dieselben sein, da es von den Apparaten desselben Niveaus nicht erforderlich ist, unterscheidbar zu sein. Weiter ist das Root Key-Zertifikat dasselbe für alle Apparate eines vorgeschriebenen Niveaus, da das Rescue Public Key-Zertifikat des Kommunikations-Gegenübers dasselbe ist. Das heißt, in einem Fall, in welchem mehrere Niedrig-Niveau-Apparate bereitgestellt werden (siehe 21) werden dieselben Rescue-Authentifizierungs-Informationen in allen der Niedrig-Niveau-Apparate gespeichert.
  • Dies gilt für die Rescue-Authentifizierungs-Informationen des Hoch-Niveau-Apparates 30 und die Rescue-Authentifizierungs-Informationen des Zertifikat-Management-Apparates 20.
  • Zum Beispiel kann in einem Fall der Koordination des Datenformates in Bezug auf das normale Public Key-Zertifikat der Begriff „Gegenstand" in 8 als ein Leerzeichen gelassen werden oder die Apparate-Nr. kann mit einer = bezeichnet werden, um nur den Namen des Anbieters als eine Bezeichnung eines Rescue Public Key-Zertifikates zurückzulassen.
  • Entsprechend werden, da die Rescue-Authentifizierungs-Informationen dieselben für alle Apparate desselben Niveaus sind, dieselben Rescue-Authentifizierungs-Informationen in entsprechenden Apparaten während der Herstellung entsprechend des Niveaus des Apparates bzw. der Apparate gespeichert. Da die Rescue-Authentifizierungs-Informationen keine Informationen für die entsprechenden Apparate beinhalten, ist kein Zertifikat erforderlich, das auf die entsprechenden Apparate verteilt wird, die mit Identifikations-Nummern nach einem Inspektionsprozess markiert wurden. Dadurch können Rescue-Authentifizierungs-Informationen in vielen Apparaten mit einem einfachen Prozess gespeichert werden. Zum Beispiel können Rescue-Authentifizierungs-Informationen in dem Master-Steuerungsprogramm enthalten sein und die Rescue-Authentifizierungs-Informationen können gespeichert werden, wenn das Steuerungsprogramm auf die Apparate kopiert wird.
  • Durch Einstellen der Gültigkeitsdauer des Rescue Public Key-Zertifikates mit einer beträchtlich langen Dauer kann die Notwendigkeit der Aktualisierung des Rescue Public Key-Zertifikates beseitigt oder reduziert werden, dadurch ist ein Aufrechterhalten eines Zustandes, in welchem eine Authentifizierung, die das Rescue Public Key-Zertifikat verwendet, in einem Fall möglich, in welchem die Gültigkeitsdauer des normalen Public Key-Zertifikates verfallen ist.
  • In diesem Fall können der Apparat des Kommunikation-Gegenübers nicht speziell identifiziert werden, da Identifikations-Informationen des Apparates nicht in dem Rescue Public Key-Zertifikat enthalten sind. Jedoch können einige Informationen bezüglich des Kommunikations-Gegenübers noch erhalten werden.
  • Zum Beispiel kann in einem Fall, in welchem ein Anbieter Rescue-Authentifizierungs-Informationen speichert, die seine Niedrig-Niveau-Apparate bezeichnen (Rescue Public Key-Zertifikate des Niedrig-Niveau-Apparates, eigener Key des Niedrig-Niveau-Apparates und Authentifizierungs-Root Key des Hoch-Niveau-Apparates), in all seinen Niedrig-Niveau-Apparaten 40, und speichert Rescue-Authentifizierungs-Informationen, die seinen Hoch-Niveau-Apparaten zugeordnet sind (Rescue Public Key-Zertifikate des Hoch-Niveau-Apparates, eigener Key des Hoch-Niveau-Apparates und Authentifizierungs-Root Key-Zertifikate des Niedrig-Niveau-Apparates), in all seinen Hoch-Niveau-Apparaten 30, der Niedrig-Niveau-Apparat 40 feststellen, dass das Kommunikations-Gegenüber ein Hoch-Niveau-Apparat 30 ist, der von demselben Anbieter stammt, wenn die Authentifizierungs-Verarbeitung entsprechend dem Rescue Root Key-Zertifikat des Hoch-Niveau-Apparates erfolgreich ist, der hierin gespeichert ist. Andererseits kann der Hoch-Niveau-Apparat 30 bestimmen, dass das Kommunikation-Gegenüber ein Hoch-Niveau-Apparat 30 ist, der von demselben Anbieter stammt, wenn die Authentifizierungs-Verarbeitung entsprechend dem Rescue Root Key-Zertifikat des Niedrig-Niveau-Apparates erfolgreich ist, der hierin gespeichert ist.
  • Nach dem Erfolg der Authentifizierungs-Verarbeitung kann ein gemeinsamer Key zwischen dem Hoch-Niveau-Apparat 30 und dem Niedrig-Niveau-Apparat 40 geteilt werden, um dadurch einen sicheren Kommunikationsweg durch Verschlüsseln mit demselben Key zu erhalten. Nachfolgend kann das Kommunikations-Gegenüber identifiziert werden, indem Informationen, wie zum Beispiel Apparate-Nummer, ausgetauscht werden. Dies bezieht sich auf die Beziehung zwischen dem Zertifikat-Management-Apparat 20 und dem Hoch-Niveau-Apparat 30.
  • Es ist zu beachten, dass Apparat-Identifikations-Informationen ebenfalls aus dem normalen Public Key-Zertifikat weggelassen werden können. Dies ermöglicht es, eine Sicherheit zu verbessern, da das normale Public Key-Zertifikat eine Gültigkeitsdauer aufweist, die kürzer ist als die des Rescue Public Key-Zertifikates.
  • Das Programm entsprechend einer Ausführungsform der vorliegenden Erfindung ist ein Programm, das einem Computer ermöglicht, als ein Kommunikations- bzw. Datenübertragungsapparat zu arbeiten (z. B. Hoch-Niveau-Apparat 30, Niedrig-Niveau-Apparat 40) und/oder als ein Kommunikations-Gegenüber des Kommunikations- bzw.
  • Datenübertragungsapparates, der ein Kommunikationsteil zum Authentifizieren eines Kommunikations-Gegenübers aufweist, indem während einer Kommunikation ein digitales Zertifikat verwendet wird. Bei Ausführung des Programmes können die oben beschriebenen Vorteile und Funktionen erreicht weiden.
  • Das Programm kann vorher auf einem Computer in einem Speicherteil gespeichert werden (z. B. ROM, HDD) und/oder in einem Aufzeichnungsmedium gespeichert werden, wie zum Beispiel einer CD-ROM oder einer Diskette oder einem nicht-volatilen Aufzeichnungsmedium (Speicher), wie zum Beispiel einem SRAM, EEPROM oder einer Speicherkarte. Beim Ausführen der oben beschriebenen Prozesse kann zum Beispiel das Programm, das in dem Speicher gespeichert ist, auf einem Computer zum Ausführen durch eine CPU installiert werden, oder die CPU kann das Programm auf dem Speicher auslesen und das Programm ausführen.
  • Weiter können die oben beschriebenen Prozesse ausgeführt werden, durch eine Verbindung eines Netzwerks an einen externen Apparat, der ein Aufzeichnungsmedium aufweist, mit Programmen, die hierauf aufgezeichnet sind, oder durch Herunterladen des Programmes von einem externen Apparat, der eine Speichereinheit aufweist mit dem Programm, das hierin gespeichert ist.
  • Weiter ist die vorliegende Erfindung nicht auf diese Ausführungsformen beschränkt, sondern verschiedene Variationen und Modifikationen können gemacht werden, ohne vom Geltungsbereich der vorliegenden Erfindung abzuweichen.

Claims (31)

  1. Kommunikations- bzw. Datenübertragungsapparat (30), welcher Folgendes umfasst: erste und zweite digitale Zertifikate, wobei das zweite digitale Zertifikat einem normalen Public Key, und das erste digitale Zertifikat einem Rescue Public Key bzw. Rettungs-Public Key entspricht, wobei das erste digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, die länger ist als die Gültigkeitsdauer bzw. Validierungsbenennung des zweiten digitalen Zertifikats; ein Authentifikationsteil (33), um einen anderen Kommunikations- bzw. Datenübertragungsapparat (40) mit dem ersten digitalen Zertifikat zu authentifizieren, wenn das Authentifikationsteil (33) bei der Authentifikation des anderen Kommunikations- bzw. Datenübertragungsapparates (40) aufgrund eines Auslaufens der Gültigkeitsdauer bzw. Validierungsbenennung des zweiten digitalen Zertifikats fehlschlägt, und ein Zertifikatübertragungsteil (31), um ein neues, zweites digitales Zertifikat zu dem anderen Kommunikations- bzw. Datenübertragungsapparat (40) zu übertragen, wenn das Authentifikationsteil (33) der Authentifikation des anderen Kommunikation- bzw. Datenübertragungsapparates (40) mit dem ersten digitalen Zertifikat erfolgreich ist.
  2. Kommunikation- bzw. Datenübertragungsapparat nach Anspruch 1, wobei das erste digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, die länger ist als eine Lebensdauer des anderen Kommunikations- bzw. Datenübertragungsapparates, und das zweite digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, welche kürzer ist als die Lebensdauer des anderen Kommunikations- bzw. Datenübertragungsapparates.
  3. Kommunikations- bzw. Datenübertragungsapparat nach Anspruch 1, wobei das erste digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, welche nicht innerhalb der Betriebsdauer des anderen Kommunikations- bzw. Datenübertragungsapparates ausläuft, und das zweite digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, welche innerhalb der Betriebsdauer des anderen Kommunikations- bzw. Datenübertragungsapparates ausläuft.
  4. Kommunikations- bzw. Datenübertragungsapparat nach Anspruch 1, wobei das erste digitale Zertifikat eine unbegrenzte Gültigkeitsdauer bzw. Validierungsbenennung aufweist und das zweite digitale Zertifikat eine begrenzte Gültigkeitsdauer bzw. Validierungsbenennung aufweist.
  5. Kommunikations- bzw. Datenübertragungsapparat nach Anspruch 1, wobei das Authentifikationsteil den anderen Kommunikations- bzw. Datenübertragungsapparat in Übereinstimmung mit dem SSL-Zertifikat und/oder dem TLS-Zertifikat authentifiziert.
  6. Kommunikations- bzw. Datenübertragungsapparat nach Anspruch 1, wobei das zweite digitale Zertifikat ein Public Key-Zertifikat des anderen Kommunikations- bzw. Datenübertragungsapparates ist.
  7. Kommunikations- bzw. Datenübertragungsapparat (40), der Folgendes umfasst: ein Zertifikatspeicherteil (45), um ein erstes digitales Zertifikat und ein zweites digitales Zertifikat zu speichern, und wobei das zweite digitale Zertifikat einem normalen Public Key entspricht, wobei das erste digitale Zertifikat einem Rescue Public Key bzw. Rettungs-Public Key entspricht, wobei das erste digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, die länger ist als die Gültigkeitsdauer bzw. Validierungsbenennung des zweiten digitalen Zertifikats; ein Zertifikataktualisierungsteil (48), um ein altes zweites digitales Zertifikat zu aktualisieren, das in dem Zertifikatspeicherteil (45) gespeichert ist, und zwar mit einem neuen zweiten digitalen Zertifikat, das von einem anderen Kommunikation- bzw. Datenübertragungsapparat (30) empfangen wird, wenn es dem Kommunikation- bzw. Datenübertragungsapparat (30) misslingt, den Kommunikation- bzw. Datenübertragungsapparat (40) mit dem alten, zweiten digitalen Zertifikat zu authentifizieren, und zwar aufgrund eines Auslaufens der Gültigkeitsdauer bzw. Validierungsbenennung des alten zweiten digitalen Zertifikats; wobei das neue zweite digitale Zertifikat von dem anderen Kommunikations- bzw. Datenübertragungsapparat (30) empfangen wird, wenn eine Authentifikation des Kommunikations- bzw. Datenübertragungsapparates (40) bei Verwendung des ersten digitalen Zertifikats erfolgreich ist.
  8. Kommunikations- bzw. Datenübertragungssystem (100), welches Folgendes umfasst: einen ersten Kommunikations- bzw. Datenübertragungsapparat (40), wobei der erste Kommunikations- bzw. Datenübertragungsapparat (40) ein Zertifikatspeicherteil (45) beinhaltet, um ein erstes digitales Zertifikat und ein zweites digitales Zertifikat zu speichern, wobei das zweite digitale Zertifikat einem normalen Public Key entspricht, und das erste digitale Zertifikat einem Rescue Public Key entspricht, wobei das erste digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, die langer ist als die Gültigkeitsdauer bzw. Validierungsbenennung des zweiten digitalen Zertifikats; einen zweiten Kommunikations- bzw. Datenübertragungsapparat (30), wobei der zweite Kommunikations- bzw. Datenübertragungsapparat (30) ein Authentifikationsteil (33) zum Authentifizieren des ersten Kommunikations- bzw. Datenübertragungsapparates (40) mit dem ersten digitalen Zertifikat beinhaltet, wenn es dem Authentifikationsteil (33) misslingt, den Kommunikations- bzw. Datenübertragungsapparat (40) aufgrund eines Auslaufens der Gültigkeitsdauer bzw. Validierungsbenennung des zweiten digitalen Zertifikates zu authentifizieren; und der zweite Kommunikation- bzw. Datenübertragungsapparat ebenfalls ein Zertifikatübertragungsteil (31) zum Übertragen eines neuen, zweiten digitalen Zertifikates an den ersten Kommunikations- bzw. Datenübertragungsapparat (40) beinhaltet, wenn das Authentifikationsteil (33) der Authentifikation des anderen Kommunikations- bzw. Datenübertragungsapparates (40) mit dem ersten digitalen Zertifikat nachfolgt.
  9. Kommunikations- bzw. Datenübertragungssystem nach Anspruch 8, wobei das erste digitale Zertifikat für eine Authentifikation des ersten Kommunikations- bzw. Datenübertragungsapparates verwendet wird, wenn das neue, zweite digitale Zertifikat in dem ersten Kommunikations- bzw. Datenübertragungsapparat gespeichert wird.
  10. Kommunikations- bzw. Datenübertragungsapparat nach Anspruch 8, wobei das erste digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, die länger ist als eine Lebensdauer des ersten Kommunikations- bzw. Datenübertragungsapparates, und das zweite digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, welche kürzer ist als die Lebensdauer des ersten Kommunikations- bzw. Datenübertragungsapparates.
  11. Kommunikations- bzw. Datenübertragungssystem nach Anspruch 8, wobei das erste digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, die nicht innerhalb der Betriebsdauer des ersten Apparates auslauft, und das zweite digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, welche innerhalb der Betriebsdauer des ersten Kommunikations- bzw. Datenübertragungsapparates ausläuft.
  12. Kommunikations- bzw. Datenübertragungssystem nach Anspruch 8, wobei das erste digitale Zertifikat eine unbegrenzte Gültigkeitsdauer bzw. Validierungsbenennung aufweist und das zweite digitale Zertifikat eine begrenzte Gültigkeitsdauer bzw. Validierungsbenennung aufweist.
  13. Kommunikations- bzw. Datenübertragungssystem nach Anspruch 8, welches weiter dadurch gekennzeichnet ist, dass es Folgendes umfasst: einen anderen Kommunikations- bzw. Datenübertragungsapparat, wobei der andere erste Kommunikations- bzw. Datenübertragungsapparat ein anderes Zertifikatspeicherteil zum Speichern des ersten digitalen Zertifikats und/oder des zweiten digitalen Zertifikats umfasst.
  14. Kommunikations- bzw. Datenübertragungssystem nach Anspruch 8, wobei das Authentifikationsteil den ersten Kommunikations- bzw. Datenübertragungsapparat in Übereinstimmung mit dem SSL-Zertifikat und/oder dem TSL-Zertifikat berechtigt.
  15. Kommunikations- bzw. Datenübertragungssystem nach Anspruch 8, wobei das zweite digitale Zertifikat ein Public Key-Zertifikat des ersten Kommunikations- bzw. Datenübertragungsapparates ist.
  16. Zertifikatübertragungsverfahren, das folgende Schritte umfasst: a) Authentifizieren eines Datenkommunikation- bzw. Datenübertragungsapparates (40) mit einem ersten digitalen Zertifikat, wenn eine Authentifikation, die ein zweites Zertifikat verwendet, aufgrund des Auslaufens der Gültigkeitsdauer bzw. Validierungsbenennung des zweiten digitalen Zertifikats fehlschlägt, wobei das zweite digitale Zertifikat einem normalen Public Key entspricht, und wobei das erste digitale Zertifikat einem Rescue Public Key bzw. Rettungs-Public Key entspricht, wobei das erste digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, die länger ist als die Gültigkeitsdauer bzw. Validierungsbenennung des zweiten digitalen Zertifikats; b) Übertragen eines neuen, zweiten digitalen Zertifikats, wenn die Authentifikation des anderen Kommunikations- bzw. Datenübertragungsapparates (40) dem ersten digitalen Zertifikat in Schritt a) nachfolgt; wobei der andere Kommunikations- bzw. Datenübertragungsapparat (40) mit dem ersten digitalen Zertifikat in Schritt a) berechtigt wird, wenn ein Authentifikationsschritt des anderen Kommunikations- bzw. Datenübertragungsapparates (40) mit einem alten, zweiten digitalen Zertifikat aufgrund des Auslaufens der Gültigkeitsdauer bzw. Validierungsbenennung des alten, zweiten digitalen Zertifikats fehlschlägt.
  17. Authentifikationsübertragungsverfahren nach Anspruch 16, wobei das erste digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, die länger ist als eine Lebensdauer des anderen Kommunikations- bzw. Datenübertragungsapparates, und das zweite digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, die kürzer ist als die Lebensdauer des anderen Kommunikations- bzw. Datenübertragungsapparates.
  18. Authentifikationsübertragungsverfahren nach Anspruch 16, wobei das erste digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, die nicht innerhalb der Betriebsdauer des anderen Kommunikations- bzw. Datenübertragungsapparates ausläuft, und das zweite digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, welche innerhalb der Betriebsdauer des anderen Kommunikations- bzw. Datenübertragungsapparates ausläuft.
  19. Authentifikationsübertragungsverfahren nach Anspruch 16, wobei das erste digitale Zertifikat eine unbegrenzte Gültigkeitsdauer bzw. Validierungsbenennung aufweist und das zweite digitale Zertifikat eine begrenzte Gültigkeitsdauer bzw. Validierungsbenennung aufweist.
  20. Authentifikationsübertragungsverfahren nach Anspruch 16, wobei der andere Kommunikation- bzw. Datenübertragungsapparat in Schritt a) in Übereinstimmung mit dem SSL-Zertifikat und/oder dem TLS-Zertifikat berechtigt wird.
  21. Authentifikationsübertragungsverfahren nach Anspruch 16, wobei das zweite digitale Zertifikat ein Public Key-Zertifikat des anderen Kommunikation- bzw. Datenübertragungsapparates ist.
  22. Authentifikationsübertragungsverfahren nach Anspruch 16, dadurch gekennzeichnet, dass es weiter folgenden Schritt umfasst: Speichern des neuen zweiten digitalen Zertifikates in dem anderen Kommunikations- bzw. Datenübertragungsapparat.
  23. Authentifikationsübertragungsverfahren nach Anspruch 22, wobei das erste digitale Zertifikat zum Authentifizieren des anderen Kommunikations- bzw. Datenübertragungsapparates in einem Fall verwendet wird, in dem das neue zweite digitale Zertifikat in dem anderen Kommunikations- bzw. Datenübertragungsapparat gespeichert wird.
  24. Authentifikationsübertragungsverfahren nach Anspruch 22, wobei das erste digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, die langer ist als eine Lebensdauer des anderen Kommunikations- bzw. Datenübertragungsapparates, und das zweite digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, die kürzer ist als die Lebensdauer des anderen Kommunikation- bzw. Datenübertragungsapparates.
  25. Authentifikationsübertragungsverfahren nach Anspruch 22, wobei das erste digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, die nicht innerhalb der Betriebsdauer des anderen Kommunikations- bzw. Datenübertragungsapparates ausläuft, und wobei das zweite digitale Zertifikat eine Gültigkeitsdauer bzw. Validierungsbenennung aufweist, die innerhalb der Betriebsdauer des anderen Kommunikation- bzw. Datenübertragungsapparates ausläuft.
  26. Authentifikationsübertragungsverfahren nach Anspruch 22, wobei das erste digitale Zertifikat eine unbegrenzte Gültigkeitsdauer bzw. Validierungsbenennung aufweist und das zweite digitale Zertifikat eine begrenzte Gültigkeitsdauer bzw. Validierungsbenennung aufweist.
  27. Authentifikationsübertragungsverfahren nach Anspruch 22, dadurch gekennzeichnet, dass sie Folgendes umfasst: einen Schritt zum Speichern von entweder dem ersten digitalen Zertifikat und/oder dem zweiten digitalen Zertifikat in noch einem anderen Kommunikations- bzw. Datenübertragungsapparat.
  28. Authentifikationsübertragungsverfahren nach Anspruch 22, wobei der andere Kommunikations- bzw. Datenübertragungsapparat in Schritt b) in Übereinstimmung mit dem SSL-Zertifikat und/oder dem TLS-Zertifikat berechtigt wird.
  29. Authentifikationsübertragungsverfahren nach Anspruch 22, wobei das zweite digitale Zertifikat ein Public Key-Zertifikat des anderen Kommunikations- bzw. Datenübertragungsapparates ist.
  30. Programm, das ein Codemittel umfasst, das angepasst ist, um die Schritte des Verfahrens von irgendeinem der Ansprüche 16–29 auszuführen.
  31. Trägermedium, auf welchem ein gespeichertes Codemittel angepasst ist, um die Schritte des Verfahrens von irgendeinem der Ansprüche 16–29 auszuführen.
DE602004012506T 2003-09-30 2004-09-30 Kommunikationsgerät, Kommunikationssystem, Verfahren und Programm zur Zertifikatsübertragung Active DE602004012506T2 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2003341329 2003-09-30
JP2003341329 2003-09-30
JP2004217713 2004-07-26
JP2004217713A JP4611678B2 (ja) 2003-07-25 2004-07-26 通信装置、通信システム、通信方法及びプログラム

Publications (2)

Publication Number Publication Date
DE602004012506D1 DE602004012506D1 (de) 2008-04-30
DE602004012506T2 true DE602004012506T2 (de) 2009-04-16

Family

ID=34315725

Family Applications (1)

Application Number Title Priority Date Filing Date
DE602004012506T Active DE602004012506T2 (de) 2003-09-30 2004-09-30 Kommunikationsgerät, Kommunikationssystem, Verfahren und Programm zur Zertifikatsübertragung

Country Status (3)

Country Link
US (1) US8015399B2 (de)
EP (1) EP1521426B1 (de)
DE (1) DE602004012506T2 (de)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1693983B1 (de) * 2003-07-25 2007-08-29 Ricoh Company, Ltd. Authentifizierungs-System- und Verfahren unter Verwendung von individualisierten und nicht-individualisierten Zertifikaten
JP4712325B2 (ja) * 2003-09-12 2011-06-29 株式会社リコー 通信装置、通信システム、通信方法及びプログラム
US7387235B2 (en) 2005-03-16 2008-06-17 Lear Corporation Mutual authentication security system with recovery from partial programming
US7953971B2 (en) * 2005-10-27 2011-05-31 Research In Motion Limited Synchronizing certificates between a device and server
US8458455B2 (en) * 2006-10-10 2013-06-04 International Business Machines Corporation Techniques for handling SSL certificate expiration and renewal
WO2008091768A2 (en) * 2007-01-22 2008-07-31 Global Crypto Systems Methods and systems for digital authentication using digitally signed images
US8301877B2 (en) * 2008-03-10 2012-10-30 Secureauth Corporation System and method for configuring a valid duration period for a digital certificate
TW202216656A (zh) * 2008-05-23 2022-05-01 美商Ｐｒｔｋ Ｓｐｖ２公司 四環素化合物之甲苯磺酸鹽及同素異形體
US8856869B1 (en) * 2009-06-22 2014-10-07 NexWavSec Software Inc. Enforcement of same origin policy for sensitive data
CN102118386B (zh) * 2009-12-25 2013-11-27 佳能It解决方案株式会社 中继处理装置、中继处理方法
US8838962B2 (en) * 2010-09-24 2014-09-16 Bryant Christopher Lee Securing locally stored Web-based database data
JP5286380B2 (ja) * 2011-03-07 2013-09-11 株式会社東芝 データ送信装置および送信方法
JP5704322B2 (ja) * 2011-03-10 2015-04-22 セイコーエプソン株式会社 画像生成装置、プロジェクターおよび画像生成方法
US10855734B2 (en) * 2011-06-29 2020-12-01 Interdigital Ce Patent Holdings Remote management of devices
JP5612006B2 (ja) 2012-03-13 2014-10-22 株式会社東芝 データ送信装置、データ受信装置、及びプログラム
US9306906B2 (en) * 2013-03-25 2016-04-05 Salesforce.Com, Inc. Systems and methods for utilizing uni-directional inter-host communication in an air gap environment
JP6079394B2 (ja) * 2013-04-11 2017-02-15 富士通株式会社 証明書生成方法、証明書生成装置、情報処理装置、通信機器、及びプログラム
DE102013222503A1 (de) * 2013-11-06 2015-05-07 Siemens Aktiengesellschaft Client-Einrichtung und Verfahren zum Prägen einer Client-Einrichtung auf mindestens eine Server-Einrichtung
BR112016012359A2 (pt) * 2013-12-02 2017-08-08 Mastercard International Inc Método e sistema para transmissão segura de mensagens de serviço de notificação remota para dispositivos móveis sem elementos seguros
CN114710351A (zh) * 2014-03-26 2022-07-05 大陆-特韦斯股份有限公司 用于在通信过程中改进数据安全性的方法和系统
JP6573880B2 (ja) * 2014-06-16 2019-09-11 富士通株式会社 更新プログラム及び方法、及び、管理プログラム及び方法
US10275767B2 (en) 2014-10-21 2019-04-30 Mastercard International Incorporated Method and system for generating cryptograms for validation in a webservice environment
US9843452B2 (en) 2014-12-15 2017-12-12 Amazon Technologies, Inc. Short-duration digital certificate issuance based on long-duration digital certificate validation
JP6331031B2 (ja) 2015-03-26 2018-05-30 パナソニックＩｐマネジメント株式会社 認証方法、認証システム及び通信機器
US10205598B2 (en) * 2015-05-03 2019-02-12 Ronald Francis Sulpizio, JR. Temporal key generation and PKI gateway
CN105515768B (zh) * 2016-01-08 2017-07-21 腾讯科技（深圳）有限公司 一种更新密钥的方法、装置和系统
US10063536B2 (en) * 2016-03-25 2018-08-28 Ca, Inc. Short term or one-time-use X.509 digital certificates
GB2561822B (en) * 2017-04-13 2020-02-19 Arm Ip Ltd Reduced bandwidth handshake communication
US10771439B2 (en) * 2017-06-28 2020-09-08 Microsoft Technology Licensing, Llc Shielded networks for virtual machines
JP7091911B2 (ja) * 2018-07-24 2022-06-28 株式会社リコー 情報処理装置および情報処理方法
CN110768940B (zh) * 2018-07-27 2022-03-22 深信服科技股份有限公司 基于https协议密文数据管控方法、系统、代理服务器及存储介质
JP7054796B2 (ja) * 2018-08-28 2022-04-15 パナソニックＩｐマネジメント株式会社 証明書生成方法、証明書生成装置およびコンピュータプログラム
FR3098614B1 (fr) * 2019-07-11 2022-11-04 Idemia Identity & Security France Procédé de contrôle de commandes propres à être traitées par un périphérique tel qu’un actionneur
EP3866428B1 (de) * 2020-02-13 2021-12-29 Axis AB Verfahren zur erneuten bereitstellung eines digitalen sicherheitszertifikats und system und nichttransitorisches computerprogrammprodukt davon

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05336108A (ja) 1992-06-04 1993-12-17 Toshiba Corp 無線通信システム
US5659617A (en) * 1994-09-22 1997-08-19 Fischer; Addison M. Method for providing location certificates
US6367013B1 (en) * 1995-01-17 2002-04-02 Eoriginal Inc. System and method for electronic transmission, storage, and retrieval of authenticated electronic original documents
JPH09200194A (ja) 1995-12-29 1997-07-31 Intel Corp 安全保護の行われた通信を行うための装置および方法
US5781723A (en) * 1996-06-03 1998-07-14 Microsoft Corporation System and method for self-identifying a portable information device to a computing unit
JP3905961B2 (ja) 1997-11-11 2007-04-18 インターナショナル・ビジネス・マシーンズ・コーポレーション 臨時署名認証の方法及びそのシステム
US6314521B1 (en) * 1997-11-26 2001-11-06 International Business Machines Corporation Secure configuration of a digital certificate for a printer or other network device
WO1999035783A1 (en) 1998-01-09 1999-07-15 Cybersafe Corporation Client side public key authentication method and apparatus with short-lived certificates
US6615347B1 (en) * 1998-06-30 2003-09-02 Verisign, Inc. Digital certificate cross-referencing
CA2347211A1 (en) 1998-10-23 2000-05-04 L-3 Communications Corporation Apparatus and methods for managing key material in heterogeneous cryptographic assets
WO2000077974A1 (en) * 1999-06-11 2000-12-21 Liberate Technologies Hierarchical open security information delegation and acquisition
GB9914262D0 (en) 1999-06-18 1999-08-18 Nokia Mobile Phones Ltd WIM Manufacture certificate
US6584567B1 (en) 1999-06-30 2003-06-24 International Business Machines Corporation Dynamic connection to multiple origin servers in a transcoding proxy
JP2001094553A (ja) 1999-09-22 2001-04-06 Nippon Telegr & Teleph Corp <Ntt> 匿名認証方法および装置
US6826690B1 (en) 1999-11-08 2004-11-30 International Business Machines Corporation Using device certificates for automated authentication of communicating devices
US6816900B1 (en) * 2000-01-04 2004-11-09 Microsoft Corporation Updating trusted root certificates on a client computer
US6763459B1 (en) 2000-01-14 2004-07-13 Hewlett-Packard Company, L.P. Lightweight public key infrastructure employing disposable certificates
US7340600B1 (en) * 2000-01-14 2008-03-04 Hewlett-Packard Development Company, L.P. Authorization infrastructure based on public key cryptography
JP2001237820A (ja) 2000-02-25 2001-08-31 Nec Corp 認証用証明書書き換えシステム
JP4321944B2 (ja) * 2000-04-27 2009-08-26 富士通株式会社 生体情報を用いた個人認証システム
JP2001326632A (ja) 2000-05-17 2001-11-22 Fujitsu Ltd 分散グループ管理システムおよび方法
JP2002141895A (ja) * 2000-11-01 2002-05-17 Sony Corp コンテンツ配信システムおよびコンテンツ配信方法
US7017041B2 (en) * 2000-12-19 2006-03-21 Tricipher, Inc. Secure communications network with user control of authenticated personal information provided to network entities
CA2437611C (en) * 2001-02-06 2015-09-15 Certicom Corp. Mobile certificate distribution in a pki
US7395430B2 (en) * 2001-08-28 2008-07-01 International Business Machines Corporation Secure authentication using digital certificates
JP2002247032A (ja) 2001-02-19 2002-08-30 Hitachi Ltd 暗号通信装置および暗号通信方法
JP4070413B2 (ja) 2001-02-22 2008-04-02 株式会社リコー 電子取引装置、方法及び電子取引システム
JP4106875B2 (ja) 2001-03-26 2008-06-25 凸版印刷株式会社 電子デバイス、電子デバイス内の情報更新システム、情報更新方法およびそのプログラム
JP3724564B2 (ja) 2001-05-30 2005-12-07 日本電気株式会社 認証システム及び認証方法並びに認証用プログラム
EP1271875A1 (de) 2001-06-21 2003-01-02 Koninklijke Philips Electronics N.V. Vorrichtung zum Datenaustausch, und Verfahren zur Herstellung
JP2003016031A (ja) 2001-07-02 2003-01-17 Toshiba Corp クライアント／サーバー・システムの優先接続制御方式
US6854057B2 (en) * 2001-09-06 2005-02-08 America Online, Inc. Digital certificate proxy
FI114956B (fi) * 2001-12-27 2005-01-31 Nokia Corp Menetelmä palvelun käyttämiseksi, järjestelmä ja päätelaite
US7480937B2 (en) * 2002-02-26 2009-01-20 Ricoh Company, Ltd. Agent device, image-forming-device management system, image-forming-device management method, image-forming-device management program, and storage medium
JP3682777B2 (ja) * 2002-03-25 2005-08-10 株式会社リコー 画像形成装置および遠隔管理システム
US20040255113A1 (en) * 2003-03-31 2004-12-16 Masaaki Ogura Digital certificate management system, apparatus and software program
JP4504099B2 (ja) * 2003-06-25 2010-07-14 株式会社リコー デジタル証明書管理システム、デジタル証明書管理装置、デジタル証明書管理方法、更新手順決定方法およびプログラム
JP4522771B2 (ja) * 2003-09-22 2010-08-11 株式会社リコー 通信装置、通信システム、通信装置の制御方法及びプログラム

Also Published As

Publication number Publication date
US20050102503A1 (en) 2005-05-12
EP1521426B1 (de) 2008-03-19
EP1521426A1 (de) 2005-04-06
DE602004012506D1 (de) 2008-04-30
US8015399B2 (en) 2011-09-06

Similar Documents

Publication Publication Date Title
DE602004012506T2 (de) Kommunikationsgerät, Kommunikationssystem, Verfahren und Programm zur Zertifikatsübertragung
DE602004002044T2 (de) Authentifizierungs-System- und Verfahren unter Verwendung von individualisierten und nicht-individualisierten Zertifikaten
EP3488555B1 (de) Gesichertes verarbeiten einer berechtigungsnachweisanfrage
DE60214632T2 (de) Multidomäne Berechtigung und Authentifizierung
DE602004012485T2 (de) Vorrichtung, Verfahren und Rechnerprogramm zur Verwaltung von digitalen Zertifikaten
DE60114986T2 (de) Verfahren zur herausgabe einer elektronischen identität
DE10051571B4 (de) Methode und System zur Unterstützung von Sicherheitsvorgaben unter Verwendung einer Stylesheet-Verarbeitung
DE69830726T2 (de) Verfahren zum betrieb eines systems von authentifizierungsservern sowie ein solches system
US8291225B2 (en) Communications apparatus, communications system, and method of setting certificate
EP3655880B1 (de) Hardwaresystem mit blockchain
DE60308601T2 (de) Verfahren und System zur Authentifizierung von Kommunikationsendgeräten
DE10392208T5 (de) Mechanismus zum Unterstützten drahtgebundener und drahtloser Verfahren für eine client- und serverseitige Authentifizierung
US20050160259A1 (en) Digital certificate management system, apparatus and software program
DE10224743A1 (de) Verwendung von Auftragsetiketten, um einen Ressourcenzugriff zu sichern
DE112010004135T5 (de) Sicherung Asynchroner Client-Server-Transaktionen
WO2010031700A2 (de) Telekommunikationsverfahren, computerprogrammprodukt und computersystem
EP3681102B1 (de) Verfahren zur validierung eines digitalen nutzerzertifikats
EP3422628B1 (de) Verfahren, sicherheitseinrichtung und sicherheitssystem
WO2020143877A1 (de) Verfahren zum sicheren bereitstellen einer personalisierten elektronischen identität auf einem endgerät
DE112011104941T5 (de) Langzeit-Signaturendgerät, Langzeit-Signaturserver, Langzeitsignaturendgeräteprogramm und Langzeit-Signaturserverprogramm
JP4509678B2 (ja) 証明書設定方法
WO2022022997A1 (de) Kanalbasierte kommunikation in einem iot-netzwerk
EP2137943B1 (de) Portable datenträger als web-server
JP4611678B2 (ja) 通信装置、通信システム、通信方法及びプログラム
DE102019112119B4 (de) Ortsfest installierbare Adaptervorrichtung für ein Netzwerksystem

Legal Events

Date Code Title Description
8364 No opposition during term of opposition