DE112022000280T5 - Identitätsautorität - Google Patents

Identitätsautorität Download PDF

Info

Publication number
DE112022000280T5
DE112022000280T5 DE112022000280.8T DE112022000280T DE112022000280T5 DE 112022000280 T5 DE112022000280 T5 DE 112022000280T5 DE 112022000280 T DE112022000280 T DE 112022000280T DE 112022000280 T5 DE112022000280 T5 DE 112022000280T5
Authority
DE
Germany
Prior art keywords
peers
peer
certificate
certificates
service
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.)
Pending
Application number
DE112022000280.8T
Other languages
English (en)
Inventor
Bryan James Donlan
Petr Praus
Douglas Stewart Laurence
Andrew C. Schleit
Daniel Leon Gregory Gardner
Zaher Dannawi
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.)
Amazon Technologies Inc
Original Assignee
Amazon Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Amazon Technologies Inc filed Critical Amazon Technologies Inc
Publication of DE112022000280T5 publication Critical patent/DE112022000280T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • 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
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)

Abstract

Es werden Systeme und Verfahren zum Rotieren von Schlüsseln in einem Vertrauensspeicher beschrieben, die von einer Gruppe von Peer-Vorrichtungen für die sichere Kommunikation zwischen den Peers in der Gruppe verwendet werden. In einigen Beispielen kann ein Dienst, wie beispielsweise ein Identifizierungsautoritätsdienst, eine Bestimmung vornehmen, dass eine Gruppe von Peers, die individuell mindestens einem öffentlichen Schlüssel aus einer Gruppe von öffentlichen Schlüsseln vertrauen, eine Reihe von Bedingungen erfüllt. Als Ergebnis der Bestimmung kann der Dienst die Vielzahl der öffentlichen Schlüssel aktualisieren, indem er mindestens einen öffentlichen Schlüssel aus der Gruppe der öffentlichen Schlüssel entfernt und die aktualisierte Vielzahl der öffentlichen Schlüssel mindestens einem der Peers in der Gruppe anzeigt. Der Dienst kann den mindestens einen öffentlichen Schlüssel aus der Gruppe entfernen, wenn er bestimmt, dass weniger als eine Schwellenanzahl von Peers in der Gruppe den mindestens einen öffentlichen Schlüssel verwenden.

Description

  • QUERVERWEIS AUF VERWANDTE ANMELDUNG
  • Diese Anmeldung beansprucht die Priorität der US-Patentanmeldung Nr. 17/362,899 , eingereicht am 29. Juni 2021, mit dem Titel „ „IDENTITY AUTHORITY” „‚ deren gesamter Inhalt durch Bezugnahme in vollem Umfang und für alle Zwecke hierin aufgenommen ist.
  • ALLGEMEINER STAND DER TECHNIK
  • Der Aufbau von Vertrauen und vertrauenswürdigen Kommunikationskanälen zwischen Rechenvorrichtungen, wie beispielsweise Cloud-Computing-Diensten, ist ein sich ständig weiterentwickelndes Problem. Da immer mehr Rechenleistungen über verschiedene Netzwerke in Anspruch genommen und angeboten werden, wird es immer wichtiger, sichere Kommunikationskanäle für die Datenübertragung zwischen verschiedenen Endpunkten effizient einrichten zu können. Verschiedene öffentliche Schlüsselinfrastruktur(Public Key Infrastructure - PKI)-Systeme wurden entwickelt, um dieses Problem zu lösen. Diese Systeme stellen die Vertrauenswürdigkeit in der Regel über Zertifikate her, die öffentliche Schlüssel mit den Identitäten von Entitäten verbinden und von einer Zertifizierungsstelle (certificate authority - CA) ausgestellt werden. Diese Infrastrukturen wiesen in der Vergangenheit zum Schutz vor unerwünschtem Zugang Zertifikate auf, die natürlich nach kurzer Zeit ablaufen, so dass regelmäßig neue Zertifikate ausgestellt werden müssen. Dieser Prozess der regelmäßigen Ausstellung von Zertifikaten hat in verschiedenen Anwendungen den Nachteil, dass sichere und vertrauenswürdige Kommunikationskanäle unterbrochen werden, wenn kein kompromittierendes Ereignis erkannt wurde. In Fällen, in denen eine vertrauenswürdige Gruppe von Entitäten nur mit anderen Elementen der vertrauenswürdigen Gruppe kommuniziert, kann dies zu einem zusätzlichen und unnötigen Aufwand führen, da regelmäßig neue Zertifikate ausgestellt werden müssen, ohne die Sicherheit innerhalb der Gruppe zu erhöhen.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Verschiedene Techniken werden unter Bezugnahme auf die Zeichnungen beschrieben, in denen Folgendes gilt:
    • 1 veranschaulicht eine beispielhafte Umgebung, in der die beschriebenen Techniken angewandt werden können, gemäß mindestens einer Ausführungsform;
    • 2 veranschaulicht eine beispielhafte Kommunikation zwischen Peer-Vorrichtungen und einem Identitätsautoritätsdienst, um einen sicheren Kommunikationskanal zwischen den Peer-Vorrichtungen einzurichten, gemäß mindestens einer Ausführungsform;
    • 3 veranschaulicht einen beispielhaften Prozess zum Aktualisieren eines individuellen Schlüssels eines Vertrauensspeichers gemäß mindestens einer Ausführungsform;
    • 4 veranschaulicht einen beispielhaften Prozess zum Drehen von Schlüsseln in einem Vertrauensspeicher gemäß mindestens einer Ausführungsform;
    • 5 veranschaulicht ein Diagramm der Eigentumsrollen für eine Route, gemäß mindestens einer Ausführungsform;
    • 6 veranschaulicht einen beispielhaften Prozess zur Einrichtung einer sicheren Route zwischen gleichrangigen Vorrichtungen, gemäß mindestens einer Ausführungsform ; und
    • 7 veranschaulicht ein System, in welchem verschiedene Ausführungsformen implementiert werden können.
  • DETAILLIERTE BESCHREIBUNG
  • Hier werden Systeme und Verfahren beschrieben, die sich auf die Verwendung von rotierenden kryptographischen Schlüsseln beziehen, um sichere Kommunikationskanäle zwischen Peers aufzubauen. Ein Dienst, wie beispielsweise ein Identitätsbehörden(identity authority - IA)-Dienst, kann eingesetzt werden, um eine Reihe von kryptografischen Schlüsseln für die Verwendung zwischen gleichrangigen Vorrichtungen auszugeben und aufrechtzuerhalten. Peer-Vorrichtungen werden verschiedenen Routen oder Gruppen von Peer-Vorrichtungen zugewiesen, die sicher miteinander kommunizieren können. Die Menge von kryptografischen Schlüssel ist Teil eines Vertrauensspeichers, der vom IA-Dienst und den einzelnen Peer-Vorrichtungen aufrechterhalten wird. Den kryptografischen Schlüsseln im Vertrauensspeicher, die als Routenschlüsselpaare bezeichnet werden, wird ein unterschiedlicher Status oder Zustand zugewiesen, wie beispielsweise „ „ausstehend” „, „ „ausgestellt” „und” „ „veraltet” „.Schlüssel, die auf „Ausstellen" eingestellt sind, können zur Ausstellung von Zertifikaten für die Verschlüsselung der Kommunikation zwischen Peers verwendet werden. Die Peers können dann die ausgestellten Zertifikate verwenden, um sichere Kommunikationskanäle aufzubauen, wie beispielsweise gegenseitig authentifizierte TLS 1.3-Sitzungen, ohne zusätzliche Netzwerkanrufe und die damit verbundene Latenzzeit. Schlüssel, die auf „ausstehend" gesetzt sind, sind Schlüssel, die kürzlich zum Vertrauensspeicher hinzugefügt wurden, denen aber einige oder die meisten Peers noch nicht vertrauen. Veraltete Schlüssel sind Schlüssel, denen die Vorrichtungen der Gegenseite vertrauen, die aber nicht mehr für die Ausstellung von Zertifikaten verwendet werden. Die Schlüssel im Vertrauensspeicher können zwischen den verschiedenen Status und Zuständen rotieren, beispielsweise in regelmäßigen Abständen. Ein Beispiel für eine Rotation kann ein Schlüsselpaar beinhalten, das als ausstehend beginnt, in einen ausstellenden Zustand übergeht und dann in den veralteten Zustand übergeht. Die Schlüssel weisen keine zeitliche Begrenzung auf, so dass sie nicht natürlich oder standardmäßig ablaufen können. Vielmehr dürfen Schlüsselpaare für Routen erst dann deaktiviert werden, wenn sichergestellt ist, dass die Schlüsselpaare von der Gruppe der Peers nicht mehr verwendet werden. Der IA-Dienst verfolgt, welche Schlüssel von verschiedenen Peers in der Gruppe verwendet werden, um die Rotation der Schlüssel in verschiedene Zustände zu kontrollieren.
  • In einigen Aspekten ist der IA-Dienst ein System, das als öffentliche Schlüsselinfrastruktur (PKI) und als Verteilungssystem für Berechtigungsnachweise arbeitet. Der IA-Dienst implementiert ein operativ sichereres PKI-Modell, bei dem Zertifikate nicht mehr vertrauenswürdig sind, wenn ein oder mehrere externe Systeme überprüfen, dass die Zertifikate nicht mehr verwendet werden (Zertifikatsrückzug), sondern auf einem Zeitwert für den Ablauf (z. B. einem bestimmten Datum und einer bestimmten Uhrzeit) basieren. Der IA-Dienst überwacht, welche Zertifikate in den Systemen der Herstellung (z. B. auf öffentlich zugänglichen Servern) verwendet werden und entfernt keine Zertifikate, die noch in Gebrauch sind. Im Gegensatz zum traditionellen PKI-Modell, bei dem das Ausbleiben von Maßnahmen (Nichtverlängerung eines Zertifikats) zu einem defekten System führt, kann das Ausbleiben von Maßnahmen, die vom IA-Dienst erkannt werden, zu einer Veränderung der Schlüsselrotation führen und nicht zu einem Bruch oder der Nichtverfügbarkeit der Schlüssel.
  • Im Gegensatz zu traditionellen PKI-Systemen müssen die beschriebenen Techniken keine langlebigen, auslaufenden Stammschlüssel aufrechterhalten, denen jeder Peer vertraut. Stattdessen hält der IA-Dienst für jede Route eine Liste von Routenschlüsselpaaren aufrecht, die er zur Ausstellung von Peer-Zertifikaten verwendet. Jedes Routenschlüsselpaar (route key pair - RKP) weist ein zugehöriges selbstsigniertes Routenzertifikat auf, das den öffentlichen Routenschlüssel enthält. Jeder Peer auf einer Route kann in regelmäßigen Abständen die aktuelle Liste der Routenzertifikate abfragen, wie beispielsweise in einem Vertrauensspeicher aufrechterhalten. In einigen Fällen laufen Schlüsselpaare und Zertifikate nicht basierend auf der Zeit ab, sondern werden vom IA-Dienst entfernt, wenn eine externe Komponente die Entfernung der Schlüssel verlangt. Der IA-Dienst verfolgt jeden Peer, so dass er Maßnahmen, die von externen Komponenten oder Systemen angefordert werden, auf ihre Zulässigkeit überprüfen kann. Der IA-Dienst wird das RKP, das ein Peer-Zertifikat ausgestellt hat, in der Regel erst dann entfernen, wenn der Peer verifiziert hat, dass er auf ein neueres Peer-Zertifikat umgestiegen ist, oder wenn der IA-Dienst (vom Peer selbst oder einer externen Komponente) angewiesen wird, dass der Peer ignoriert werden soll. In ähnlicher Weise verfolgt der IA-Dienst, welche RKPs von Peers als vertrauenswürdig eingestuft werden, und erlaubt die Aktivierung einer RKP, wenn bestimmt wird, dass die neue RPK in den Vertrauensspeichern aller aktiven (nicht ignorierten) Peers enthalten ist.
  • In einigen Fällen können Peer-Geräte vorhandene Anmeldedaten verwenden, die bei einem Anbieter, der den IA-Dienst hostet oder mit ihm interagiert, erstellt wurden, um dann ein Peer-Zertifikat vom IA-Dienst anzufordern. In einigen Beispielen enthält die Anfrage nach einem Peer-Zertifikat den öffentlichen Schlüssel des Peers und kann mit den zugrunde liegenden, vom Anbieter ausgestellten Anmeldedaten authentifiziert werden. Der lA-Dienst authentifiziert dann die Anfrage und signiert den öffentlichen Schlüssel der Gegenstelle, wodurch ein Gegenstellenzertifikat ausgestellt wird. Der Peer weist nun eine vollständige Identität auf. Das Zertifikat stellt eine Genehmigung des IA-Dienstes für die Operation des Peers auf einer bestimmten Route dar.
  • Ähnlich wie Peer-Vorrichtungen weisen auch die Routen eine kryptografische Identität auf. Stattdessen hält der IA-Dienst für jede Route eine Liste von Routenschlüsselpaaren aufrecht, die er zur Ausstellung von Peer-Zertifikaten verwendet. Jedes Schlüsselpaar für eine Route weist auch ein zugehöriges selbstsigniertes CA-Zertifikat auf, das als Routenzertifikat bezeichnet wird. Dies ist eine bequeme Möglichkeit, den öffentlichen Abschnitt des Schlüsselpaares so zu verteilen, dass er von jeder TLS-Implementierung problemlos genutzt werden kann. Jeder Peer auf einer Route kann den IA-Dienst in regelmäßigen Abständen nach der Liste aller Routenzertifikate fragen, denen er zum Zeitpunkt des Anrufs vertrauen sollte. In einigen Fällen delegiert der IA-Dienst die Authentifizierung und Autorisierung von Kunden an ein externes System, das die Vertrauensbasis für den IA-Dienst und die Peers bildet. In einigen Fällen wird das Vertrauen vorübergehend an die Autorität des externen Systems delegiert.
  • In der vorhergehenden und nachfolgenden Beschreibung werden verschiedene Techniken beschrieben. Zu Erklärungszwecken werden spezifische Konfigurationen und Details dargelegt, um ein umfassendes Verständnis möglicher Wege zur Implementierung der Techniken bereitzustellen. Es wird jedoch auch deutlich, dass die im Folgenden beschriebenen Techniken in unterschiedlichen Konfigurationen ohne die spezifischen Details ausgeführt werden können. Darüber hinaus können bekannte Merkmale weggelassen oder vereinfacht werden, um zu verhindern, dass die beschriebenen Techniken unkenntlich gemacht werden.
  • Wie ein Fachmann in der Technik im Lichte dieser Offenbarung beachten wird, können bestimmte Ausführungsformen in der Lage sein, bestimmte Vorteile zu erzielen, die einige oder alle der folgenden beinhalten: 1) Aufbauen von sicheren Kanälen mit geringer Latenz zwischen Peer-Vorrichtungen, 2) Verringern der Netzwerkkommunikation und der Bandbreitennutzung, um sichere Kommunikationskanäle zwischen Peer-Vorrichtungen aufzubauen, und 3) andere Vorteile, die im weiteren Verlauf dieser Offenbarung beschrieben und deutlich gemacht werden.
  • 1 veranschaulicht eine beispielhafte Umgebung 100, wobei ein Identitätsautoritätsdienst (IA) 104 von einem Anbieter von Rechenressourcendiensten 102 bereitgestellt werden kann. Verschiedene Peer-Vorrichtungen 118, 120, 122 können über ein oder mehrere Netzwerke miteinander und mit dem Anbieter des Rechenressourcendienstes 102 kommunizieren. Der Rechenressourcendienstanbieter 102 kann eine beliebige Anzahl von Diensten bereitstellen, die den Peer-Vorrichtungen 118, 120, 122 zugänglich gemacht werden können, wie beispielsweise ein Identitätsautoritätsdienst 104, ein Datenspeicherdienst 106, ein Schlüsselverwaltungssystem oder -dienst (key management system - KMS) 112, ein Flottenverwaltungsdienst 134 und ein Identitäts- und Zugriffsverwaltungsdienst 114, wie im Folgenden näher erläutert wird.
  • Eine Peer-Vorrichtung 118, 120, 122 kann jede Rechenvorrichtung betreffen, wie beispielsweise einen Host oder Server, die über ein Netzwerk kommunizieren. Bei der Peer-Vorrichtung 118, 120, 122 kann es sich um eine Gruppe von Servern handeln, die eine beliebige Anzahl von Diensten bereitstellen, wie sie beispielsweise vom Rechenressourcendienstanbieter 102 bereitgestellt werden können. In anderen Beispielen kann sich ein Peer-Rechensystem 118, 120, 122 auf ein Kunden-Computersystem oder eine Rechenvorrichtung beziehen, die über ein Netzwerk mit einem Server (z. B. dem Rechenressourcendienstanbieter 102) verbunden ist. Eine Peer-Vorrichtung 118, 120, 122 kann eine physische Rechenvorrichtung oder eine virtuelle Rechenvorrichtung sein. Eine Gruppe von Peer-Vorrichtungen 118, 120, 122, die miteinander kommunizieren, wird hier als Route 116 bezeichnet. Optional können Kunden- und Server-Rollen auf einer Route 116 definiert werden und können entweder statisch zugewiesen werden (z. B. eine Flotte spricht mit einer anderen) oder sich dynamisch verändern (z. B. wählen die Hosts einen Anführer, der als Server fungiert, und alle anderen sind Kunden). Die Route 116 kann eine beliebige Anzahl von Hosts oder Servern, eine beliebige Anzahl von Kundenvorrichtungen oder eine Kombination davon beinhalten. Es sollte beachtet werden, dass die Identifizierungsautorität (IA) 104 eine beliebige Anzahl verschiedener Routen 116 definieren kann, die jeweils unterschiedliche oder sich überschneidende Peer-Vorrichtungen 118, 120, 122 beinhalten.
  • Jeder Peer 118, 120, 122 in einer Route 116 kann mit anderen Peer-Vorrichtungen kommunizieren, indem er einen sicheren Kommunikationskanal unter Verwendung eines Zertifikats einrichtet, das vom IA-Dienst 104 ausgestellt und verwaltet wird. Wie veranschaulicht, kann Peer 118 mit Peer 122 unter Verwendung eines Zertifikats 124 kommunizieren, um eine sichere Kommunikationsverbindung herzustellen, die eine Version von TLS, wie beispielsweise TLS 1.3, implementiert. In ähnlicher Weise kann Peer 118 mit Peer 120 über einen sicheren Kanal unter Verwendung von Zertifikat 124 kommunizieren, und die Peers 120 und 122 können über einen Kanal kommunizieren, der durch Zertifikat 124 gesichert ist. Der IA-Dienst 104 kann Routenzertifikate, wie beispielsweise das Zertifikat 126, an eine Gruppe von Peers 118, 120, 122 ausgeben, damit die Peers sicher miteinander kommunizieren können, wie weiter unten noch näher beschrieben wird. In einigen Fällen kann das Zertifikat 126 ein Schlüsselpaar beinhalten oder darauf basieren, das hier als Routenschlüsselpaar (RKP) bezeichnet wird und von den Peer-Vorrichtungen 118, 120, 122 in der Route 116 verwendet werden kann, um das Zertifikat 124 für die sichere Kommunikation mit anderen Peers 118, 120, 122 der Route 116 auszustellen. Beispiele für die Kommunikation zwischen den Peers 118, 120, 122 und dem IA-Dienst 104 werden im Folgenden unter Bezugnahme auf 2 näher beschrieben.
  • In einigen Fällen kann jede Peer-Vorrichtung 118, 120, 122 mindestens zwei Arten von Identitäten aufweisen: eine Identität, die mit dem IAM-Dienst 134 eingerichtet ist, und eine Identität, die mit dem IA-Dienst 104 eingerichtet ist. Bei Host-Vorrichtungen (z. B. Infrastrukturvorrichtungen oder Servern, die intern zum Rechenressourcendienstanbieter 102 gehören oder zu ihm gehören können) kann das Bereitstellen der IAM-Identität von einem Verteilungssystem für Berechtigungsnachweise durchgeführt werden, das vom Rechenressourcendienstanbieter 102 bereitgestellt wird. Für Kundenvorrichtungen kann die IAM-Identität von einem ähnlichen oder anderen System bereitgestellt werden. Jeder Peer 118, 120, 122 kann also eine Reihe von Anmeldedaten aufweisen, die es ihm ermöglichen, mit dem Rechenressourcendienstanbieter 102 über den IAM-Dienst 134 zu interagieren. In einigen Implementierungen kann der LA-Dienst 104 den IAM-Dienst 134 und die entsprechenden IAM-Zugangsdaten nutzen, um sich von den Details der Implementierung von Identitäten in verschiedenen Netzwerken zu lösen. In einigen Aspekten kann der IA-Dienst 104 die gleichen oder ähnliche Authentifizierungs- und Autorisierungsmechanismen verwenden wie andere vom Rechenressourcendienstanbieter 102 bereitgestellte Dienste.
  • In einigen Beispielen identifiziert die Identität des IA-Dienstes 104 einer Peer-Vorrichtung jeden Peer auf einer Route eindeutig und dient als Grundlage für das Vertrauen. Die Peer-Identität kann ein vom Peer erzeugtes Peer-Schlüsselpaar und ein Peer-Zertifikat beinhalten. Das Zertifikat bindet die IAM-Identität des Peers an das Peer-Schlüsselpaar und stellt die Erlaubnis von dem IA-Dienst 104 dar, dass der Peer einer Route beitreten darf. Zusammen bilden das Schlüsselpaar und das Zertifikat die Identität der Gegenstelle. Peers verwenden ihr Schlüsselpaar, um anderen Peers während des Handshakes des Transportverschlüsselungsprotokolls die Kontrolle über die Identität zu beweisen (z. B. CertificateVerify in TLS 1.3).
  • Der Rechenressourcendienstanbieter 102 kann verschiedene Dienste bereitstellen, wie beispielsweise die Verarbeitung von Daten, die Lagerung von Daten, Softwareanwendungen, Sicherheit, Verschlüsselung und/oder andere derartige Dienste. Ein hierin beschriebener Anbieter von Rechenressourcen kann unter Verwendung von Techniken implementiert werden, die im Folgenden unter Bezugnahme auf 7 beschrieben werden. Der Rechenressourcendienstanbieter 102 kann Dienste bereitstellen, auf die über verschiedene Software, Hardware und/oder Variationen davon zugegriffen werden kann. In einigen Beispielen können die Dienste als Softwareanwendungen oder Dienste implementiert werden, die auf verschiedenen Rechenvorrichtungen ausgeführt werden. Beispiele für solche Rechenvorrichtungen beinhalten eine oder mehrere Instanzen einer physischen Rechenvorrichtung (z. B. einen physischen Server-Computer, eine mobile Kommunikationsvorrichtung, einen Laptop-Computer, einen Tablet-Computer, einen Personal-Computer, einen Großrechner usw.) oder eine oder mehrere Instanzen einer virtuellen Rechenvorrichtung, wie z. B. eine virtuelle Maschine, die auf einem oder mehreren Computer-Servern gehostet wird, oder andere verschiedene fähige Rechensysteme.
  • In einigen Beispielen kann der Rechenressourcendienstanbieter 102 einen Identitätsautoritäts(IA)-Dienst 104 bereitstellen. Der IA-Dienst 104 kann eine Sammlung von Berechungsressourcen sein, die so konfiguriert sind, dass sie auf Daten zugreifen und diese analysieren, z. B. von einem oder mehreren Datenspeicherungsdiensten 106, Sicherheitsrollen und Verwaltungszugang durch eine oder mehrere Peer-Vorrichtungen über den Identitäts- und Zugangsverwaltungsdienst (IAM) 114 bestimmen, kryptografische Schlüssel von einem Schlüsselverwaltungssystem (KMS) 112 anfordern, erhalten und verwalten, sich mit einem Flottenverwaltungsdienst 134 koordinieren, um eine Reihe von Vorrichtungen, wie beispielsweise Peer-Vorrichtungen 118, 120, 122, und Dienste zu verwalten, und mit Peer-Vorrichtungen 118, 120, 122 auf verschiedenen Routen 116 kommunizieren, damit die Peers 118, 120, 122 sicher miteinander kommunizieren können, wie weiter unten noch näher beschrieben wird.
  • In einigen Beispielen kann der Rechenressourcendienstanbieter 102 eine Datenspeicherung über einen Datenspeicherdienst 106 bereitstellen, um große Datenmengen, einschließlich Bild- und anderer Mediendaten, zu speichern und zu verwalten. Der Datenspeicherungsdienst 106 kann verschiedene Informationen für verschiedene Routen speichern, die hier als Vertrauensspeicher bezeichnet werden, wie beispielsweise die Vertrauensspeicher 108 und 110. In einigen Fällen kann der Datenspeicherungsdienst 106 mit dem IA-Dienst 104 interagieren, um verschiedene Informationen, die in den Vertrauensspeichern 108, 110 gespeichert sind, für verschiedene Routen zu speichern und den Zugang dazu bereitzustellen. In einigen Fällen können die Routeninformationen 108, 110 eine Reihe von Zertifikaten oder RKPs beinhalten, die von der entsprechenden Route, wie beispielsweise der Route 116, verwendet werden können. Die Sammlung verschiedener Zertifikate/RKPs, die für eine bestimmte Route gespeichert sind, kann als Vertrauensspeicher bezeichnet werden, wobei jedes Zertifikat/RKP als ein Vertrauensanker bezeichnet werden kann. Jedes RKP weist ein zugehöriges selbstsigniertes Routenzertifikat auf, das den öffentlichen Routenschlüssel enthält.
  • Bei dem Datenspeicherungsdienst 106 kann es sich um einen On-Demand-Datenspeicherungsdienst handeln, wie beispielsweise einen objektbasierten Datenspeicherungsdienst, der API-Anfragen zum synchronen Speichern und Abrufen von Datenobjekten bedient und so konfiguriert sein kann, dass er verschiedene Formen von Medien speichert. Der Datenspeicherungsdienst 106 kann auf einem Computersystem oder einer Abstraktion davon (wie beispielsweise einer oder mehreren virtuellen Maschinen, Software-Containern oder anderen Abstraktionen von Rechenressourcen) implementiert werden, die unter Verwendung von Hardware und Software implementiert werden, und kann einen oder mehrere Prozessoren und einen Speicher umfassen, der ausführbare Anweisungen speichert, deren Ausführung durch den einen oder die mehreren Prozessoren bewirkt, dass das Computersystem die hierin beschriebenen Operationen durchführt. In einigen Beispielen können die im Datenspeicherungsdienst 106 gespeicherten Daten in Datenobjekten in einem oder mehreren logischen Behältern organisiert sein. Der Datenspeicherungsdienst 106 und/oder die Vertrauensspeicher 108, 110 können ein oder mehrere Objekte beinhalten, die beliebige Größen haben können und in einigen Fällen Größenbeschränkungen aufweisen können. So kann der Datenspeicherungsdienst 106 zahlreiche Objekte unterschiedlicher Größe speichern. Der Datenspeicherungsdienst 106 kann als Schlüsselwertspeicher fungieren, der Datenobjekten Identifikatoren der Datenobjekte zuordnet, die vom IA-Dienst 104 und/oder den Peer-Vorrichtungen 118, 120, 122 verwendet werden können, um andere Operationen in Verbindung mit den vom Datenspeicherungsdienst 106 gespeicherten Datenobjekten abzurufen oder durchzuführen. Der Zugang zum objektbasierten Datenspeicherungsdienst 106 kann über Anwendungsprogrammierschnittstellen (API)-Aufrufe zum Dienst oder über eine Schnittstelle, wie beispielsweise eine grafische Benutzeroberfläche (GUI), erfolgen. Der Zugang zum Datenspeicherungsdienst 106 kann über Anwendungsprogrammierschnittstellen(API)-Aufrufe erfolgen, zum Beispiel direkt vom IA-Dienst 104 und den Peers 118, 120, 122 oder über den Rechenressourcendienstanbieter 102. Es sollte beachtet werden, dass der Datenspeicherungsdienst 106 zusätzlich oder alternativ eine nicht objektbasierte Datenspeicherung bereitstellen kann, wie beispielsweise Blockdatenspeicherung, tabellenorientierte Datenspeicherung, relationale Datenbanken, dateibasierte Speicherung und dergleichen. Der Datenspeicherungsdienst 106 kann auch ein Archivierungssystem oder einen Prozess implementieren, der bestimmte Objekte an verschiedenen Standorten, Vorrichtungen usw. speichert, zum Beispiel basierend auf dem Zugang zu diesen Datenobjekten oder anderen Faktoren. Zum Beispiel können einige Objekte, auf die über einen bestimmten Zeitraum hinweg nicht zugegriffen wurde, von einer Vorrichtung oder einem Standort (z. B. hier allgemein als Speicherklasse bezeichnet), die einen sofortigen Zugang, wenn auch zu höheren Kosten, bereitstellen, in eine kostengünstigere Speicherklasse verschoben werden, die den Zugang mit einer gewissen Verzögerung, einer anderen Redundanz oder anderen Attributen bereitstellt.
  • Der Rechenressourcendienstanbieter 102 kann auch ein Schlüsselverwaltungssystem (KMS) 112 bereitstellen. Bei KMS 112 kann es sich um eine Sammlung von Berechungsressourcen handeln, die so konfiguriert sind, dass sie kryptografische Schlüssel zur Verwendung durch Peer-Vorrichtungen und andere Dienste erzeugen, austauschen, speichern, verwenden, zerstören, ersetzen und bereitstellen, wie es in der Technik bekannt ist. Der IA-Dienst 104 kann über die Anfrage 130 einen oder mehrere kryptografische Schlüssel vom KMS 112 erhalten, um verschiedene Vertrauensspeicher 108, 110 für verschiedene Routen zu erstellen und zu aktualisieren. In einigen Fällen kann der lA-Dienst 104 in regelmäßigen oder periodischen Abständen neue RKPs vom KMS 112 erhalten, um die verschiedenen Vertrauensspeicher 108, 110 regelmäßig zu aktualisieren, z. B. durch Hinzufügen von RKPs. In einigen Fällen kann der IA-Dienst 104 ein oder mehrere kryptografische Schlüsselpaare täglich, alle 12 Stunden, alle paar Tage, jede Woche usw. zu einem Vertrauensspeicher 108, 110 aktualisieren oder hinzufügen. Der Zeitraum für die Aktualisierung oder das Hinzufügen von Schlüsseln zu den Vertrauensspeichern 108, 110 kann basierend auf der Häufigkeit der Peer-Kommunikation, dem für die Peer-Kommunikation benötigten Level an Sicherheit, der Sensibilität der von den Peer-Vorrichtungen übermittelten Daten usw. bestimmt oder ausgewählt werden.
  • In einigen Fällen kann das KMS 112 verschiedene kryptografische Schlüssel aufrechterhalten und speichern, die vom IA-Dienst 104 und von den Peers 118, 120, 122 verwendet werden. In einigen Fällen verwendet der IA-Dienst 104 KMS-Kunden-Hauptschlüssel (CMKs) für Routenschlüsselpaare. Darüber hinaus kann der Träger für kundenverwaltete CMKs in anderen Implementierungen leicht gehalten werden. In einigen Fällen kann ein KMS CMK verwendet werden. In einigen Aspekten kann der IA-Dienst asymmetrische KMS-CMKs für Routenschlüsselpaare verwenden oder auch nicht. Der Vorteil des Verzichts auf asymmetrische KMS-CMKs ist, dass der private Routenschlüssel niemals KMS 112 verlassen muss, was die Sicherheit erhöht. Andererseits führt die Verwendung asymmetrischer KMS-CMKs zu einer direkten Abhängigkeit der Datenebene von KMS 112, was für die Nutzer des IA-Dienstes 104 unerwünscht sein kann. Während die Routenschlüssel das KMS 112 nicht verlassen würden, hätte der IA-Dienst 104 weiterhin die volle Kontrolle darüber, welche Zertifikate ausgestellt werden. Ein Angreifer, der den IA-Dienst 104 kompromittiert hat, hätte keinen Zugang zu den Routenschlüsseln, könnte sich aber alle benötigten Peer-Zertifikate ausstellen.
  • Der Rechenressourcendienstanbieter 102 kann auch einen Identitäts- und Zugangsverwaltungsdienst (IAM) 114 bereitstellen. Der IAM-Dienst 114 kann eine Sammlung von Rechenressourcen sein, einschließlich physischer Ressourcen, virtueller Ressourcen oder Kombinationen davon, die so konfiguriert sind, dass sie den Zugang zu den vom Rechenressourcendienstanbieter 102 bereitgestellten Ressourcen kontrollieren. In einigen Implementierungen kann der IA-Dienst 104 vorhandene, vom IAM-Dienst 114 bereitgestellte und verwaltete Zugangssysteme nutzen, um den Zugang zu den vom IA-Dienst 104 verwalteten Zertifikaten zu kontrollieren. In einigen Fällen kann sich jeder Peer 118, 120, 122 mit Hilfe von Anmeldedaten oder einer Identität authentifizieren, die beim Rechenressourcendienstanbieter 102 durch eine über den IAM-Dienst 114 bereitgestellte Authentifizierung mit Hilfe von in der Technik bekannten Techniken eingerichtet wurde. In anderen Fällen können die Peers 118, 120, 122 eine getrennte Identität mit dem IA-Dienst 104 einrichten, um einer Route 116 beizutreten und eine sichere Kommunikation mit anderen Peers in dieser Route 116 aufzubauen.
  • Der Rechenressourcendienstanbieter 102 kann auch einen Flottenverwaltungsdienst 134 bereitstellen. Der Flottenverwaltungsdienst 134 kann eine Sammlung von Rechenressourcen sein, die so konfiguriert sind, dass sie Flotten von Rechenvorrichtungen, wie beispielsweise physische und virtuelle Server, verwalten. Der Flottenverwaltungsdienst kann eine oder mehrere Benutzeroberflächen bereitstellen, über die Kunden Betriebsdaten verschiedener vom Rechenressourcendienstanbieter 102 bereitgestellter Dienste einsehen können. In einigen Implementierungen kann der Flottenverwaltungsdienst 134 den Zugang zu Peer-Vorrichtungen und die RKP-Rotation für verschiedene Routen verwalten. In einigen Fällen können RKP's über Anfragen oder Anweisungen, die vom Flottenverwaltungsdienst 134 empfangen werden, gelöscht werden. In einigen Fällen können andere Entitäten, wie beispielsweise vertrauenswürdige oder autorisierte Entitäten, beantragen, dass eine RKP aus einem Vertrauensspeicher für eine bestimmte Route entfernt wird. Durch die Einschränkung der Autorität, RKPs aus einem Vertrauensspeicher zu löschen oder zu entfernen, kann in einigen Fällen der Zugang zu Zertifikaten innerhalb einer Route aufrechterhalten werden und die Fähigkeit von Peers, mit anderen Peers in der Route zu kommunizieren.
  • In einigen Aspekten kann der IA-Dienst 104 Informationen etwa über verschiedene Routen 108, 110 speichern und über die Kommunikation 128 mit einem Datenspeicherungsdienst 106 darauf zugreifen. Der IA-Dienst 104 kann zu verschiedenen Zeitpunkten die für eine bestimmte Route gespeicherten Zertifikate oder RKPs wechseln oder verändern, indem er den verschiedenen RKPs verschiedene Zustände oder Status zuweist. Der IA-Dienst 104 kann Zugang zum KMS 112 erhalten, um sichere kryptografische Schlüssel zum Erzeugen und Aktualisieren von Vertrauensspeichern für verschiedene Routen, zum Ausstellen und Signieren von Zertifikaten für Peer-Vorrichtungen usw. zu erhalten. Der IA-Dienst 104 kann den Zugang verschiedener Peer-Vorrichtungen 118, 120, 122 zu bestimmten Routen überprüfen und sicherstellen, dass die Peers vertrauenswürdig sind, indem er die Peer-Vorrichtung mit dem IAM-Dienst 114 authentifiziert. In einigen Fällen kann der IA-Dienst 104 RKPs aus einem Vertrauensspeicher für eine Route entfernen, wenn er eine Anweisung vom Flottenmanagementdienst 134 oder einer anderen autorisierten Stelle empfängt. In einigen Fällen kann der IA-Dienst selbst daran gehindert werden, RKPs aus einem Vertrauensspeicher zu entfernen.
  • In einigen Fällen kann der IA-Dienst 104 zusätzlich zum KMS 112 funktionieren, um Zertifikate für Peer-Vorrichtungen 118, 120, 122 bereitzustellen. Der IA-Dienst 104 kann mit dem IAM-Dienst 114 oder einem anderen Authentifizierungsdienst überprüfen, ob eine Anfrage von einem Peer, ein Peer-Zertifikat zu erhalten, zulässig ist. In einigen Fällen kann dies die Form annehmen, dass überprüft wird, ob die Identität des Peers 118, 120, 122 den Anmeldeinformationen des IAM-Dienstes 114 zugeordnet ist, die auf einer bestimmten Route 116 erlaubt sind. Wenn der Peer so verifiziert wird, dass die Anfrage zulässig ist, kann der IA-Dienst 104 mit dem KMS 112 kommunizieren, um ein Schlüsselpaar zu erhalten, mit dem eingehende öffentliche Schlüssel von Peer-Vorrichtungen auf der Route 116 signiert werden. Der IA-Dienst kann dann den eingehenden öffentlichen Schlüssel signieren (z. B. durch Signieren eines Zertifikats, das den öffentlichen Schlüssel umfasst, unter Verwendung eines privaten Schlüssels der aktuell ausstellenden RKP) und ein Zertifikat erzeugen, wie z. B. ein X.509v3-Zertifikat, und das Zertifikat der anfordernden Peer-Vorrichtung 118, 120, 122 bereitstellen. Der IA-Dienst 104 kann auch den öffentlichen Signierschlüssel zur Verfügung stellen, so dass Peer-Vorrichtungen 118, 120, 122 in Zukunft Signaturen überprüfen können, ohne den öffentlichen Signierschlüssel beim IA-Dienst 104 anzufordern.
  • In einigen Fällen kann jede Route 116 vollständig durch ihren Routenkennzeichner, Ressourcennamen (RN) oder einen anderen Kennzeichner identifiziert werden, der einen Routennamen beinhaltet. Routennamen sind innerhalb eines bestimmten Kontos eindeutig, aber möglicherweise nicht kontenübergreifend. In einigen Aspekten können die Routennamen Partition, Region und Zelle beinhalten. Der Routenname kann ausgewählt werden, um die Route eindeutig zu identifizieren, und nicht ein zufällig erzeugter Name, um die Nutzung der Routen für die Benutzer intuitiver zu machen. In einigen Fällen kann der Routenidentifikator bei der gesamten Kommunikation, einschließlich API-Aufrufen, mit dem IA-Dienst 104 verwendet werden. Ein Beispiel für eine Route RN lautet wie folgt: RN: identityauthority:uswest-2:111122223333:route/FooBar-aws-us-west-1-cell-123, wobei „FooBar..." die Route RN und „42" die RKP SN ist. Jedes Routenschlüsselpaar (RKP) auf einer Route wird durch seine monoton ansteigende ganzzahlige Seriennummer (RKP SN) identifiziert. In einigen Implementierungen kann die RKP SN bei 232+1 beginnen, um sicherzustellen, dass sie nicht in einem Ganzzahltyp mit 32 Bit gespeichert werden kann und somit das Überschreiten der Ganzzahlüberlaufgrenze in der Zukunft erspart. Die Seriennummer stellt die Gesamtanordnung der RKPs bereit, die eine bestimmte Route betreffen. Ein Schlüsselpaar für eine Route wird vollständig durch seine RKP RN identifiziert, die sowohl den Routennamen als auch die SN beinhaltet. Ein Schlüsselpaar für eine Route kann zu genau einer Route gehören, um die Identifizierung der Route nicht zu verwirren.
  • In einigen Aspekten kann der IA-Dienst 104 verschiedene Informationen, die Peer-Vorrichtungen in Routen betreffen, in einer oder mehreren Tabellen oder anderen Strukturen speichern, wie beispielsweise in Abstimmung mit dem Datenspeicherungsdienst 106. In manchen Fällen werden vom Datenspeicherungsdienst 106 keine oder nur minimale geheime Informationen in unverschlüsselter Form gespeichert. Die Integrität wird mit verschiedenen Mechanismen sichergestellt, die für die Daten in der Tabelle geeignet sind, und zwar mit Techniken, die dem Kenner der Technik bekannt sind.
  • Eine Tabelle mit Routenschlüsselpaaren kann Routenschlüsselpaare und ihre Chiffretext-Blobs erfassen. Elemente in der Tabelle stellen eine 1:N-Zuordnung zwischen einer Route und ihren Schlüsselpaaren bereit, wobei N eine positive ganze Zahl ist. In einigen Implementierungen speichert die Tabelle der Routenschlüsselpaare einen Partitionsschlüssel ( „Primärschlüssel”), der ein Routenidentifikator oder RN sein kann, und einen Sortierschlüssel, der die Seriennummer der RKP sein kann. Dieses Schema ermöglicht Abfragen, um benachbarte RKPs zu finden, die zur gleichen Route gehören, und stellt außerdem sicher, dass es keine doppelten Seriennummern gibt. Die Item-Attribute können Route RN, RKP SN, RKP-Status (ausstehend, ausgestellt, veraltet, deaktiviert), Ciphertext-Blob, Signieralgorithmus, Erstellungszeitstempel, Zeitstempel der letzten berichteten Verwendung und Zertifikat beinhalten. Die Elemente in der RKP-Tabelle sind nicht geheim und die Integrität wird sichergestellt, indem das gesamte Element als Teil des Verschlüsselungskontextes für den RKP-Datenschlüssel enthalten ist. Wenn ein Angreifer eines der Felder in der Tabelle verändert, wird der KMS-Chiffretext-Blob selbst ungültig. In manchen Fällen ist zu einem bestimmten Zeitpunkt genau ein RKP auf den ausstellenden RKP für eine Route gesetzt. In diesem Fall wird der Status für verschiedene RKP's in einer Routentabelle gleichzeitig verändert.
  • Eine Routentabelle kann selbst Routen erfassen. Jeder Eintrag in der Tabelle entspricht einer Route. Eine Routentabelle beinhaltet in der Regel einen Partitionsschlüssel, bei dem es sich um den Routenkennzeichner oder RN handelt. Die Elementattribute können Routen-RN, KMS CMK RN, Zeitstempel der Routenerstellung, Prüfsumme der Routenzertifikate, Signieralgorithmus des Zertifikats und Signatur der Veränderung der Route beinhalten (siehe unten). Die Elemente in der Routentabelle müssen nicht geheim gehalten werden, aber die Integrität muss gewährleistet sein. Zum Beispiel kann ein asymmetrischer KMS-Kunden-Hauptschlüssel (CMK) verwendet werden, der einen Hash des Elements signiert („Signatur der Veränderung der Route”). Der Vorteil des asymmetrischen CMK ist, dass der Signierschlüssel den KMS 112 nie verlässt, wobei jede gültige Veränderung der Route im I Log des KMS CMK landet.
  • Eine Peer-Tabelle kann Informationen etwa über Peers enthalten. Ein Peer beginnt sein Leben in dieser Tabelle, wenn er sein erstes Zertifikat erhält, und beendet es, wenn er ignoriert wird. Die Felder, die die Route und die Peer-Zertifikate betreffen, können durch Berichte der Peers aktualisiert werden. Elemente in dieser Tabelle werden fehlerfrei bereinigt, wenn den höchsten SN im Vertrauensspeicher auf eine RKP verweist, die bereits gelöscht wurde (nicht nur deaktiviert). In der Peer-Tabelle ist der Partitionsschlüssel der Nickname des Peers und der Sortierschlüssel die Abstammungs-ID. Der globale sekundäre Index kann nach [Abstammungs-ID] gespeichert werden, um bestimmte Peers anhand ihrer Abstammungs-ID zu finden. Der globale sekundäre Index kann von [Route RN, höchste SN im Vertrauensspeicher] gespeichert werden. Dies ist nützlich, um effizient Peers zu finden, die berichtet haben, dass sie alte Vertrauensspeicher auf ihren Routen aufweisen. Die Elementattribute können Abstammungs-ID, Peer-Nickname, Gruppenname, Route RN, Peer-Status (aktiv oder ignoriert), höchste RKP-SN im Vertrauensspeicher des Peers, älteste aktive Peer-Zertifikat-SN beinhalten.
  • Eine Tabelle mit Peer-Zertifikaten kann alle von RKPs ausgestellten Peer-Zertifikate enthalten, die noch nicht gelöscht wurden. Der Partitionsschlüssel für eine Peer-Zertifikatstabelle kann der Identifikator des Subjektschlüssels sein, wie beispielsweise ein SHA-256-Hash des öffentlichen Schlüssels des Peers. Dies kann sicherstellen, dass Peers ihre öffentlichen Schlüssel nicht wiederverwenden und gezwungen sind, sie zu rotieren. Praktischerweise werden die Zertifikate auch auf die Shards des Datenspeicherungsdienstes verteilt, so dass bei einer großen Anzahl von Peer-Zertifikaten für eine Route die Schreibvorgänge gleichmäßig auf die Shards verteilt werden. Der globale sekundäre Index kann nach [Route RN, Seriennummer des Zertifikats] gespeichert werden, um bestimmte Peer-Zertifikate zu finden. Der globale sekundäre Index, der durch [Route RN, [RKP SN, Zertifikatsstatus]] gespeichert wird, ermöglicht das Auffinden von Zertifikaten, die von einer bestimmten RKP mit einem bestimmten Status ausgestellt wurden, wie beispielsweise die Auflistung aller aktiven Zertifikate für eine RKP, die wir entfernen möchten. Die Elementattribute können Folgendes beinhalten: Route RN, RKP SN, die das Zertifikat ausgestellt hat, Peer-Zertifikat SN, Zertifikat, Status (aktiv oder veraltet), Abstammungs-ID, Zeitstempel der Ausstellung, Zeitstempel der letzten Statusänderung und Shard ID (siehe „Anhang: Peer-Zertifikatswarteschlange”).
  • Wie hier beschrieben, können Routen zwei Signieralgorithmen verwenden: Ein Routensignieralgorithmus wird verwendet, um Peer-Zertifikate mit dem privaten Routenschlüssel zu signieren, und ein Peer-Signieralgorithmus wird von Peers während des Handshakes verwendet, um Zertifikatsanforderungen (CertificateVerify) mit ihren privaten Peer-Schlüsseln zu signieren. In beiden Fällen können ECDSA auf der NIST P-256-Kurve mit SHA-256 Message Digest oder andere Signieralgorithmen, wie beispielsweise die in der Technik bekannten, verwendet werden.
  • In einigen Fällen kann es wichtig sein, dass ein Zertifikat erst dann nicht mehr vertrauenswürdig ist, wenn ein oder mehrere Mechanismen aktiv überprüfen, ob das Zertifikat wirklich nicht mehr verwendet wird. Eine unterlassene Maßnahme (z. B. das Versäumnis, ein Zertifikat zu erneuern) kann einen Alarm auslösen, aber nicht dazu führen, dass das Zertifikat beschädigt wird oder dass ihm nicht vertraut wird. Typische PKI-Systeme verletzen diese Bedingung, weil sie Zertifikate mit zeitabhängigem Ablauf verwenden. Wenn der Mechanismus, der ablaufende Zertifikate erneuern soll, lange genug unbemerkt ausfällt, hören die Peers im System auf, sich gegenseitig zu vertrauen. Die beschriebenen Systeme und Verfahren verfolgen einen anderen, betrieblich sichereren Ansatz, während sie eine hohe Sicherheitsbar aufrechterhalten.
  • In einigen Implementierungen kann der IA-Dienst 104 darauf verzichten, von sich aus Maßnahmen gegen RKPs zu ergreifen. Eine externe Komponente kann dem IA-Dienst 104 signalisieren, RKPs zu erstellen, zu aktivieren, abzulehnen, zu entfernen und zu löschen. Die externe Komponente, die den Rotationsplan steuert, kann so einfach sein wie eine Funktion, die durch Ereignisse ausgelöst wird, die vom IA-Dienst 104, dem Flottenverwaltungssystem 134 oder dem Rechenressourcendienstanbieter 102 überwacht werden. Wenn ein neues Routenschlüsselpaar erstellt wird, beginnt der IA-Dienst 104 sofort damit, das Routenzertifikat der neuen RKP als Teil des Vertrauensspeichers der Route zusammen mit allen anderen gültigen Routenzertifikaten aus dem Vertrauensspeicher zurückzugeben. Peers, die mit dem IA-Dienst 104 kommuniziert haben, nachdem die neue RKP und ihr Zertifikat hinzugefügt wurden, werden nun dem neuen Routenzertifikat ebenso vertrauen wie allen früheren Routenzertifikaten, die sich noch in ihrem Vertrauensspeicher befinden. In einigen Fällen wird eine RKP, wenn sie zum ersten Mal auf einer Route erstellt wird, als schwebend betrachtet. Zertifikate, die unter dem neu hinzugefügten Schlüsselpaar ausgestellt wurden, werden in der Regel von den meisten Peers auf der Route noch nicht als vertrauenswürdig eingestuft, wie beispielsweise aufgrund von Kommunikationsverzögerungen. In großen Flotten oder Peer-Vorrichtungen kann es mindestens ein paar Stunden dauern, bis alle Hosts oder Peers mit dem IA-Dienst 104 kommunizieren und das Routenzertifikat der neuen RKP zu ihren Vertrauensspeichern für Routen hinzufügen. Wenn der IA-Dienst 104 also ein Peer-Zertifikat ausstellt, tut er dies mit dem Schlüsselpaar der ausstellenden Route. Eine RKP wird zu einer ausstellenden RKP, nachdem sie eine Weile im Umlauf war und eine externe Komponente, wie der Flottenverwaltungsdienst 134, den IA-Dienst 104 aufruft, um die älteste ausstehende RKP zur ausstellenden RKP zu machen (wie beispielsweise über den oben beschriebenen API-Aufruf AdvancelssuingRouteKeyPair).
  • Zur zusätzlichen Sicherheit kann die IA 104 in einigen Implementierungen die Peers daran hindern, die ausstellende RKP zu verändern, wenn es auf der Route einen Peer gibt, der ein Peer-Zertifikat erhalten hat, aber entweder nicht berichtet hat, wie sein Vertrauensspeicher aussieht, oder er hat es und verfügt nicht über das Routenzertifikat der ältesten ausstehenden RKP, die die ausstellende RKP für die Route werden würde. Ein solcher Peer wäre von Peers abgeschnitten, die versuchen, sich mit Peer-Zertifikaten zu authentifizieren, die von der neuen RKP ausgestellt wurden. Um die Rotation freizugeben, kann der Peer selbst das Flottenverwaltungssystem 134 anweisen, den IA-Dienst 104 zu vergessen.
  • In einigen Implementierungen kann der IA-Dienst 104 so bereitgestellt werden, dass er zusätzlich zu oder in Verbindung mit einem bestehenden Flottenverwaltungsdienst 134 oder einem anderen ähnlichen Dienst oder System arbeitet. In einigen Fällen steuert der IA-Dienst 104 die Schlüsselrotation und ignoriert automatisch einen konfigurierbaren Prozentsatz von Peers innerhalb eines 24-Stunden-Zeitraums, um die Abnutzung der Flotte zu berücksichtigen. Es können auch Tools für die manuelle Verwaltung von Peers bereitgestellt werden. In einigen Aspekten kann der IA-Dienst 104 den Lebenszyklus von Zertifikaten und Peers verwalten, ist aber von einzelnen Peers oder Hosts und deren Verfolgung abstrahiert. Der IA-Dienst 104 kann IAM-Entitäten sehen, die Zertifikate und ihre selbst ausgewählten Identifikatoren wünschen.
  • In einigen Beispielen können symmetrische kryptographische Verfahren zusätzlich zu den oben beschriebenen asymmetrischen kryptographischen Verfahren oder an deren Stelle verwendet werden. In diesen Fällen kann ein gemeinsames Geheimnis zwischen den Peers 118, 120, 122 und dem IA-Dienst 104 implementiert werden. In einigen Fällen können Hashbasierte Message Authentication Code oder Keyed-Hash Message Authentication Code (HMAC) Techniken verwendet werden, um den Austausch von Geheimnissen zwischen verschiedenen Entitäten zu erleichtern. In anderen Fällen können eine oder mehrere andere symmetrische Verschlüsselungstechniken mit ähnlichem Effekt eingesetzt werden.
  • 2 veranschaulicht eine beispielhafte Kommunikation zwischen Peer-Vorrichtungen 118, 120 und einem Identitätsautoritätsdienst 104, um einen sicheren Kommunikationskanal zwischen den Peer-Vorrichtungen einzurichten, gemäß mindestens einer Ausführungsform;
  • Bevor ein Peer 118, 120 Zugang zu einer Route erhält, erhält er sein Peer-Zertifikat, indem er eine IssuePeerCertificate API aufruft, wie beispielsweise in den Operationen 208 und 210 an den IA-Dienst 104 veranschaulicht. Der Peer 118, 120 kann die Anfrage 208, 210 zum Beispiel mit einer IAM-Identität signieren, die die Berechtigung für die Anfrage aufweist. Der IA-Dienst 104 kann jede Peer-Vorrichtung 118, 120 bei Operation 212 authentifizieren und autorisieren. In einigen Fällen kann die Operation 212 die Überprüfung mit einem anderen Dienst beinhalten, wie beispielsweise dem oben unter Bezugnahme auf 1 beschriebenen IAM-Dienst 134, dass der Peer 118, 120 berechtigt ist, ein Peer-Zertifikat anzufordern und auf den IA-Dienst 104 zuzugreifen. Der IA-Dienst 104 kann bei der Authentifizierung der Peers 118, 120 ein Peer-Zertifikat für jeden Peer 118, 120 basierend auf einem für die Route identifizierten RKP erzeugen, und zwar bei Operation 214, wie oben unter Bezugnahme auf 1 beschrieben. Operation 214 kann den Zugang zum RKP von der Datenspeicherung108 beinhalten und die Entschlüsselung des RKP durch das KMS 112 aufweisen. Der IA-Dienst 104 kann dann die Peer-Zertifikate in den Operationen 216 bzw. 218 an die Peers 118 und 120 ausstellen. Die Zertifikate ermöglichen es den Peers 118, 120, anderen Peers auf der Route unabhängig zu beweisen, dass der IA-Dienst 104 dem Inhaber des mit dem Peer zugewiesenen privaten Schlüssels den Zugang zu dieser Route erlaubt hat. In einigen Fällen rufen die Peers 118, 120 IssuePeerCertificate mit einem neuen öffentlichen Schlüssel auf. In einigen Fällen stellt der IA-Dienst 104 möglicherweise kein Peer-Zertifikat für einen öffentlichen Schlüssel aus, der bereits verwendet wurde. Dies kann es dem IA-Dienst 104 und die Peers 118, 120, die Schlüsselpaare zu wechseln. Dies kann auch Fälle verhindern, in denen ein Kunde ein Schlüsselpaar auf unbestimmte Zeit weiterverwendet.
  • Sobald ein Peer 118, 120 ein neues Peer-Zertifikat aufweist, kann er es sofort verwenden. Wie weiter unten näher beschrieben wird, kann jeder Peer eine Liste von RKPs aufrechterhalten, denen unterschiedliche Status zugewiesen sind. Ein RPK, der wie bei den Operationen 214 und 216 zur Ausgabe verändert wird, wurde bereits von den Peers 118, 120 der Route empfangen und bestätigt und auf den Status ausstehend gesetzt. Der Peer 118, 120 hält jegliches frühere Peer-Zertifikat aufrecht und greift auf dieses zurück, wenn zu viele fehlgeschlagene Verbindungen bei der Verwendung des neuen Peer-Zertifikats auftreten. In einigen Fällen berichtet jeder Peer in regelmäßigen Abständen über aktiv verwendete Peer-Zertifikate, wie beispielsweise bei Operationen 222, 224. In einigen Beispielen können die Peers 118, 120 die Zertifikatsnutzung in einer beliebigen konfigurierbaren Zeitspanne berichten, wie beispielsweise stündlich, alle 6 oder 12 Stunden, alle 24 Stunden usw., je nachdem, wie oft die Schlüssel rotiert werden, und je nach Anzahl der Peers in der Route (z. B. je größer die Anzahl, desto häufiger kann jeder Peer seine Zertifikatsnutzung berichten). Infolgedessen weiß der IA-Dienst104, dass das alte Peer-Zertifikat noch aktiv verwendet wird, und kann die Entfernung der RKP, die es ausgestellt hat, aus dem Vertrauensspeicher der Route nicht zulassen. In einigen Fällen kann die Operation 222, 224 anzeigen, (a) welche seiner Peer-Zertifikate er aktiv verwendet, (b) welchen Routenzertifikaten er vertraut und (c) wie oft jedes Routenzertifikat seit dem letzten Bericht verwendet wurde, um Vertrauen mit entfernten Peers aufzubauen.
  • Das Berichten von aktiv genutzten Peer-Zertifikaten (a) ermöglicht die Rückgewinnung von Fällen, in denen der Flottenverwaltungsdienst 134 oder der Peer selbst ein Zertifikat fälschlicherweise als veraltet markiert, es sich aber herausstellt, dass es genutzt wird. Das Berichten von vertrauenswürdigen Routenzertifikaten (b) ist wichtig, um sicherzustellen, dass der IA-Dienst 104 erst dann mit der Ausstellung von Peer-Zertifikaten von einem RKP beginnt, wenn er überprüfen kann, dass jeder aktive Peer diesem RKP vertraut. Das Berichten von Beobachtungen etwa über Routenzertifikate, auf die sich entfernte Peers verlassen (c), um sich mit dem Reporter zu verbinden, hilft dabei, Fehler zu finden, bei denen ein Peer berichtet, ein neueres Zertifikat zu verwenden, in Wirklichkeit aber ein älteres benutzt. Um den Umfang der Berichte an den IA-Dienst 104 klein und die Belastung für die Peers gering zu halten, können die Peers 118, 120 ihre Beobachtungen zusammenfassen, anstatt genau zu berichten, welcher Remote-Peer welches Peer-Zertifikat verwendet hat. Die Peers können diese Informationen zusätzlich oder alternativ zu Fehlersuchzwecken protokollieren.
  • In Fällen, in denen ein Peer 118, 120 den IA-Dienst 104 nicht kontaktieren kann, kann der Peer 118, 120 einfach das Zertifikat weiter verwenden, das er beim letzten Mal, als er mit dem IA-Dienst 104 kommunizieren konnte, empfangen hat. Das Zertifikat bleibt für den Rest der Flotte vertrauenswürdig, bis die ausstellende RKP deaktiviert wird. Wie bereits beschrieben, wird die Entfernung erst dann ausgelöst, wenn der IA-Dienst 104 von jedem aktiven Peer in der Route eine positive Bestätigung empfängt, dass der alte RKP nicht verwendet wird.
  • Um sicherzustellen, dass die Verwendung von Zertifikaten und der Vertrauensspeicher von Peers in einer Route auf dem neuesten Stand sind, aktualisiert in manchen Fällen jeder Peer 118, 120 auf einer Route seinen Zustand, indem er GetRouteState bei Operation 226 aufruft, wie beispielsweise mindestens einmal pro Stunde. Es handelt sich um einen schnellen Freshness-Check, mit dem Peers feststellen können, ob sich etwas auf der Route verändert hat. Er liefert zwei Daten, wie sie beispielsweise in einer Antwort auf den aktuellen Zustand der Route 228 enthalten sein können. Zunächst gibt GetRouteState die aktuelle Prüfsumme der Routenzertifikate zurück, die den Peers anzeigt, ob sie ihren Vertrauensspeicher für die Route mit ListRouteCertificates aktualisieren sollten. Zweitens gibt GetRouteState die ausstellende Routenzertifikat SN zurück, wobei den Peers angezeigt wird, ob sie den IA-Dienst 104 um ein neues Peer-Zertifikat bitten sollten (das unter dem neuen Routenzertifikat ausgestellt wird).
  • In einigen Aspekten kann ein Peer, wie beispielsweise Peer 118, bei Operation 230 bestimmen, dass sein Vertrauensspeicher aktualisiert werden muss. Dies kann eine Reaktion auf den aktuellen Zustand der Route 228 sein, der ein neues Zertifikat/RKP beinhaltet, das für die Route identifiziert wurde, und/oder eine Veränderung des Status eines RKP, das sich bereits im Vertrauensspeicher für die Route befindet. Wie oben beschrieben, wird jeder Peer 118 Informationen aufrechterhalten, die anzeigen, welche Zertifikate/RKPs für die Route aktiv sind und welchen Status sie haben. In einer beispielhaften Implementierung kann der Status eines Zertifikats/RKP ausgestellt, ausstehend, veraltet und deaktiviert (oder entfernt) beinhalten. Einzelheiten zu diesen Zuständen werden weiter unten unter Bezugnahme auf die 3 und 4 näher beschrieben. Es sollte beachtet werden, dass auch andere Zustände verwendet werden können, und in einigen Fällen kann eine andere Anzahl von Zuständen verwendet werden, um ähnliche Vorteile zu erzielen.
  • Nachdem er bestimmt hat, dass sein Vertrauensspeicher aktualisiert werden muss, kann der Peer 118 bei Operation 230 die aktuelle Version des Vertrauensspeichers für die Route vom IA-Dienst anfordern (Operation 232). Der IA-Dienst 104 kann daraufhin auf die aktuellen Routeninformationen zugreifen, wie beispielsweise aus einer von einem Datenspeicherungsdienst gespeicherten Routentabelle, und den aktualisierten Vertrauensspeicher einschließlich der an den RKPs vorgenommenen Veränderungen bei Operation 234 zurückgeben. In einigen Fällen kann dies Informationen beinhalten, die alle RKPs oder Zertifikate im Vertrauensspeicher identifizieren, oder auch nur Veränderungen an der bestehenden Version des Vertrauensspeichers, über den der Peer 118 verfügt. Der Peer kann dann seinen Vertrauensspeicher bei Operation 236 aktualisieren. Wie oben beschrieben, kann jeder Peer weiterhin in regelmäßigen Abständen über seine Zertifikatsnutzung berichten, wie beispielsweise durch die Operationen 238 und 240 dargestellt. In manchen Fällen kann ein Peer eine Route verlassen, indem er bei Operation 242 eine Ignorieren-Nachricht an den IA-Dienst 104 sendet. In einigen Fällen kann ein Peer nur dann aus einer Route entfernt werden, wenn er entweder eine Ignorieren-Nachricht sendet oder wenn der IA-Dienst eine Anweisung zum Ignorieren eines Peers, wie beispielsweise Peer 120, von einem Flottenverwaltungsdienst, wie dem Dienst 134, oder von einer anderen autorisierten Stelle empfängt. In diesem Beispiel kann die Mitgliedschaft in einer Route leichter kontrolliert werden.
  • Um die Nutzung von Zertifikaten effektiv zu verfolgen, reicht es für den IA-Dienst 104 möglicherweise nicht aus, nur einzelne, für eine IAM-Entität ausgestellte Zertifikate zu verfolgen, da die IAM-Entität von einer potenziell großen Anzahl von Peers gemeinsam genutzt wird. Der IA-Dienst 104 braucht nicht zwischen einzelnen Peers zu unterscheiden, um ihren Zugang zu autorisieren. Ihr Zugang wird durch die IAM-Einheit bestimmt, die sie verwenden dürfen. Wenn der IA-Dienst 104 jedoch ein Zertifikat ausstellt, hat er das Bedürfnis zu wissen, an welchen spezifischen Peer es ging, damit er verfolgen kann, wie das Zertifikat verwendet wird. Und wenn ein neuer Peer ein Zertifikat beantragt, hat er das Bedürfnis zu wissen, dass es sich um eine andere „Einheit" handelt, damit er sie verfolgen kann. Zu diesem Zweck kann der IA-Dienst 104 Zertifikatsabstammungen verfolgen, wobei jeder Peer 118, 120 unter normalen Umständen eine Abstammung aufweist. Eine Abstammung beginnt mit dem ersten Zertifikat, das für einen bestimmten Peer ausgestellt wurde, und endet damit, dass der Peer selbst oder ein Flottenverwaltungsdienst, wie beispielsweise der Dienst 134, den IA-Dienst 104 anweist, den Peer von nun an zu ignorieren.
  • Eine Zertifikatsabstammung kann durch eine Abstammungs-ID identifiziert werden, wie beispielsweise eine eindeutige 256-Bit-Nummer, die vom IA-Dienst 104 zugewiesen wird. Der IssuePeerCertificate-API-Aufruf kann die Abstammungs-ID als optionalen Parameter akzeptieren. Wenn ein neuer Peer IssuePeerCertificate ohne Abstammungs-ID aufruft, kann IA-Dienst104 eine neue Abstammungs-ID zuweisen, die in das ausgestellte Peer-Zertifikat eingebettet wird und zusammen mit dem Zertifikat an den Peer zurückgegeben wird (um dem Peer das Parsen des Zertifikats zu ersparen). Wenn derselbe Peer in Zukunft ein neues Zertifikat anfordert, beinhaltet er die Abstammungs-ID und signiert die IssuePeerCertificate-Anforderung mit einem Peer-Zertifikat aus derselben Abstammung, die er anfordert.
  • Der ReportCertificateUsage API-Aufruf und der IgnoreMe API-Aufruf werden mit einem Peer-Zertifikat von der gleichen Abstammung signiert wie der Nutzungsbericht oder die Ignorieranfrage. Auf diese Weise können verschiedene Peers nicht den Status eines anderen berichten oder den IA-Dienst 104 anweisen, andere zu ignorieren, weil sie den privaten Schlüssel eines Zertifikats aus der erforderlichen Abstammung zum Signieren der Anfrage nicht erhalten können. Ein Angreifer, der Zugang zu einer Route hat, kann ein neues Peer-Zertifikat erhalten und die Route nutzen, aber sein Peer-Zertifikat weist eine eigene neue Abstammung auf und der Angreifer kann nur über den Status dieser Abstammung berichten. In ähnlicher Weise kann der Gegner dem IA-Dienst 104 nur sagen, dass er seinen eigenen Status ignorieren soll, wenn er überlegt, ob er RKPs rotieren soll oder nicht. Eine Teilmenge der Berichtszertifikatsverwendung, ReportPeerCertificateDeprecated, kann von genau demselben Zertifikat signiert sein, das veraltet ist.
  • In einigen Implementierungen, die Flottenverwaltungssystemen und Betreibern dabei helfen, zu identifizieren, welche Abstammung zu einem bestimmten physischen Host gehört (zum Beispiel), erlaubt der IA-Dienst 104 den Peers, selbst gewählte Peer-Nicknamen und Gruppennamen anzugeben. Diese beiden Attribute gibt es nur, damit Flottenverwaltungssysteme oder Betreiber leicht erkennen können, welche Abstammungen zu welchen „physischen" Peers gehören (z. B. Hostname) und nicht zu undurchsichtigen, vom IA-Dienst 104 gewählten Bezeichnungen. In manchen Fällen ist keines der beiden Attribute Teil der vom IA-Dienst 104 ausgestellten Zertifikate, da der IA-Dienst 104 deren Authentizität nicht überprüfen kann. Da Flottenverwaltungssysteme Peers in erster Linie anhand ihrer selbst ausgewählten Nicknames (z. B. Hostnamen) identifizieren, besteht hier Verwechslungsgefahr. Wenn ein Peer gelöscht wird, aber seinen Peer-Nickname behält (z. B. aufgrund von Repurpose-in-Place), wird eine neue Abstammung erstellt und der Peer weist zwei auf. In einigen Fällen wird der IA-Dienst 104 keine Nutzungsberichte für die alte Abstammung mehr aufnehmen und die Rotation darauf blockieren. Aber ein umgewidmeter Host ist ein Ereignis in der Flottenverwaltung, von dem der Flottenmanagement-Dienst 134 wissen sollte. Da der Flottenverwaltungsdienst 134 weiß, dass der Host neu aufgesetzt wurde, weiß der Flottenverwaltungsdienst 134, welche Abstammung gesund sein sollte und welche ignoriert werden sollte und kann dies dem IA-Dienst 104 anordnen.
  • In manchen Fällen ist es für den IA-Dienst 104 und den Flottenverwaltungsdienst 134 sinnvoll, auf übereinstimmende Abstammungen zu achten und Alarm zu schlagen. Übereinstimmende Abstammungen sind solche, bei denen der IA-Dienst 104 einen Nutzungsbericht oder eine Zertifikatsausstellung von Abstammung A, dann von Abstammung B und dann wieder von Abstammung A sieht (alle mit demselben Peer-Nickname und Gruppennamen). Zum Beispiel würde dies passieren, wenn die Flotte zwei Hosts aufweist, die denken, sie hätten denselben Hostnamen. Es ist möglich, dass ein Angreifer, der über Anmeldeinformationen mit der Berechtigung IssuePeerCertificate verfügt, eine neue Zertifikatsabstammung für einen anderen Peer erstellt. Aber wenn es dem Angreifer nicht gelingt, den ursprünglichen Peer zu isolieren oder zu töten, hat er zwei schlechte Optionen: Er kann entweder den Status berichten und einen gleichzeitigen Abstammungsalarm auslösen, weil der ursprüngliche Peer weiterhin den Status berichtet und Zertifikate von seiner Abstammung erhält. Oder der Angreifer berichtet nichts und lädt zur Überprüfung ein, weil seine Abstammung die Rotation blockiert. Wenn ein Angreifer einen unbenutzten Peer-Nickname wählt, kann der Flottenverwaltungsdienst 134 ihn möglicherweise nicht in seiner Infrastrukturdatenbank finden, was ebenfalls einen Alarm auslösen sollte („unbekannter Peer X in der Flotte auf Route Y”).
  • In einigen Fällen ist jeder Peer 118, 120, den der IA-Dienst 104 verfolgt, entweder aktiv oder wird ignoriert und jedes vom IA-Dienst 104 ausgestellte Peer-Zertifikat ist entweder aktiv oder veraltet. Neu ausgestellte Peer-Zertifikate werden sofort als aktiv betrachtet. Der Peer, der das neue Peer-Zertifikat erhalten hat, gilt nun ebenfalls als aktiv, unabhängig von seinem vorherigen Zustand, falls vorhanden. Solange ein RKP jegliches aktive Peer-Zertifikat aufweist, kann der RKP nicht aus dem Vertrauensspeicher der Route entfernt (deaktiviert) werden. Wenn wir zulassen würden, dass die RKP deaktiviert wird, würden die von der RKP ausgestellten Peer-Zertifikate nicht mehr vertrauenswürdig sein.
  • Im Folgenden werden einige Beispiele für die verschiedenen oben genannten API-Aufrufe näher beschrieben, die in einigen Ausführungsformen verwendet werden können. Ein Peer 118, 120 verwendet IssuePeerCertificate, um sein eigenes Zertifikat zu erhalten, und ListRouteCertificates, um die Liste der CA-Zertifikate zu erhalten, denen er auf einer Route vertrauen soll. GetRouteState, wie beispielsweise bei Operation 226, kann von Peers verwendet werden, um zu sehen, ob sie ein neues Peer-Zertifikat benötigen oder ihre Routenzertifikate aktualisieren müssen. In einigen Implementierungen werden alle drei Operationen benötigt, um neue Peers 118, 120 zu einer Flotte hinzuzufügen, wie beispielsweise, dass der IA-Dienst 104 so ausgelegt ist, dass er die Wahrscheinlichkeit maximiert, dass er diese Anfragen bedienen kann, selbst wenn seine Abhängigkeiten nicht verfügbar sind.
  • IssuePeerCertificate, wie es in den Operationen 208, 210 aufgerufen werden kann, kann als Eingaben beinhalten: eine eindeutige Kennung der Route, der der Peer zugeordnet ist, wie beispielsweise die Routenkennung oder RN; eine Zertifizierungsanfrage einschließlich jeglicher Abstammungsinformationen (wie weiter unten näher beschrieben), einen öffentlichen Schlüssel des Peers und eine Signatur unter Verwendung des privaten Schlüssels des Peers; sowie einen Spitznamen des Peers und einen Gruppennamen. Die Ausgabe des Aufrufs kann das Peer-Zertifikat und eine Anzeige der Abstammung der Peer-ID beinhalten, falls verfügbar. In einigen Fällen, in denen verschiedenen Peers Server-/Kunden-Rollen in einer bestimmten Route zugewiesen sind, können die ausgestellten Zertifikate eine oder mehrere Einschränkungen aufweisen, wie beispielsweise, dass Kunden als Initiatoren von Kommunikationssitzungen auftreten können, während Server als Responder fungieren können.
  • GetRouteState, wie beispielsweise bei Operation 226, kann als Eingabe den Routenidentifikator oder RN beinhalten. Die Ausgabe kann eine Prüfsumme der Routenzertifikate beinhalten, die die vertrauenswürdigen (ausstehenden, ausstellenden und veralteten) Routenzertifikate der angegebenen Route beinhalten kann. In einigen Fällen kann sich die Prüfsumme verändern, wenn ein neues ausstehendes Routenzertifikat hinzugefügt oder ein veraltetes Routenzertifikat deaktiviert (aus dem Vertrauensspeicher entfernt) wird, aber nicht, wenn sich die ausstellende RKP ändert. Die Ausgabe kann auch eine Seriennummer des ausstellenden Routenzertifikats beinhalten, die verwendet werden kann, um den Peers zu signalisieren, dass sie beim IA-Dienst 104 ein neues Peer-Zertifikat anfordern sollen. Wenn ein Peer 118, 12 feststellt, dass das ausstellende Zertifikat SN eine Veränderung aufweist, muss er IssuePeerCertificate zu einem zufälligen Zeitpunkt innerhalb der Rotationsperiode aufrufen, um ein neues Peer-Zertifikat von der neuen ausstellenden RKP zu erhalten. Dies soll eine „donnernde Herde" unterbinden, die auftreten würde, wenn die gesamte Flotte auf einmal bemerken würde, dass sich der Zustand verändert hat.
  • ListRouteCertificate, wie beispielsweise bei Operation 226, stellt den Peers 118, 120 Routenzertifikate bereit, die sie in den Vertrauensspeicher einschließen müssen, den sie verwenden, wenn sie eingehende Zertifikate für die gegebene Route validieren. GetRouteState wird verwendet, um den Peers zu signalisieren, wann sie ihre Liste der Routenzertifikate und aktiven Peer-Zertifikate aktualisieren sollten. ListRouteCertificate kann als Eingaben den Routenidentifikator oder RN aufweisen. Es kann eine Seite mit Routenzertifikaten (ausstehend, ausgestellt und veraltet) ausgeben, die zu der angegebenen Route gehören.
  • In einigen Fällen können einige oder alle Peers, wie beispielsweise die Peers 118, 120, auf einer Route aktualisierte Routeninformationen von anderen Peers 118, 120 erhalten. In diesem Beispiel können ein oder mehrere Peers, die für eine Route bestimmt sind oder eine Kommunikationsverbindung mit dem IA-Dienst 104 aufweisen, die Operationen 226 und 228 durchführen, um aktualisierte Routeninformationen anzufordern und zu erhalten, einschließlich jeglicher neuer RKPs oder Zertifikate oder deren Zustände, die dem Vertrauensspeicher hinzugefügt wurden. Andere Peers, die keine zuverlässigen oder verfügbaren Kommunikationsverbindungen mit dem IA-Dienst 104 aufweisen, können dann aktualisierte Routeninformationen von diesen anderen Peers anfordern und erhalten. In einigen Beispielen kann eine Teilmenge der Peers in der Route Aktualisierungen des Zustands der Route vom IA-Dienst 104 erhalten, und über eine Implementierung des Mesh-Netzwerks können andere Peers in der Route die aktualisierten Routeninformationen von diesen Peers erhalten. In einigen Aspekten kann ein zentrales Aktualisierungsschema mit einer Mesh-Netzwerk-Implementierung für Routeninformationsaktualisierungen kombiniert werden, wie beispielsweise basierend auf verfügbaren/zuverlässigen Kommunikationsverbindungen zwischen den Peers 118, 120 und dem IA-Dienst 104, um die Flexibilität aufrechtzuerhalten, den Bandbreitenverbrauch des Netzwerks zu verringern und aus anderen Gründen des Designs.
  • 3 veranschaulicht einen beispielhaften Prozess 300 zum Aktualisieren eines individuellen Schlüssels eines Vertrauensspeichers, gemäß mindestens einer Ausführungsform. Der Prozess 300 kann von dem IA-Dienst 104 in Koordination mit dem Datenspeicherungsdienst 106 und dem KMS 112, wie oben beschrieben, durchgeführt werden. Der Prozess 300 kann den Lebenszyklus eines bestimmten Routenschlüsselpaars (RKP)/Zertifikats veranschaulichen, während es verschiedene Zustände oder Status durchläuft. Wie veranschaulicht, wird einem RKP in den Zuständen ausstehend 306, ausgestellt 310 und veraltet 316 vertraut und nur in den deaktivierten Zuständen 320 nicht vertraut. Dies dient in erster Linie dazu, eine Unterbrechung der Kommunikation zwischen den Peers zu unterbinden, wie weiter unten noch näher beschrieben wird.
  • Der Prozess kann an Punkt 302 beginnen, wo ein RKP bei Operation 304 zum Vertrauensspeicher für eine Route hinzugefügt werden kann. Die Operation 304 kann vom IA-Dienst 104 durchgeführt werden, indem er ein Schlüsselpaar vom KMS 112 anfordert. Nach dem Hinzufügen wird die RKP dem Status „Ausstehend" 306 zugeordnet. Ausstehende RKPs sind vertrauenswürdig, werden aber noch nicht für die Ausstellung neuer Zertifikate verwendet.
  • Bei Vorliegen eines auslösenden Ereignisses wird das RKP bei Operation 308 durch den IA-Dienst 104 in den Ausgabestatus 310 fortgeschritten. Das auslösende Ereignis kann den Ablauf eines konfigurierbaren Zeitraums beinhalten, wie beispielsweise 1 Tag oder 24 Stunden. In anderen Fällen kann der Zeitraum basierend auf verschiedenen Bedürfnissen und Sicherheitsbedenken mit den Peers auf einer bestimmten Route bestimmt werden, einschließlich der Anzahl der Peers in der Gruppe, der Art der Daten, die die Route kommuniziert, des Overheads in Bezug auf die Ressourcennutzung, der Kosten und so weiter. Ausstellende RKPs sind vertrauenswürdig und werden für die Ausstellung neuer Zertifikate verwendet. In einigen Implementierungen weist eine Route zu einem beliebigen Zeitpunkt genau eine ausstellende RKP auf. In anderen Aspekten kann das auslösende Ereignis das Erkennen eines Notfalls beinhalten. Das Notfallereignis kann die Detektion einer Verletzung oder einer potenziellen Verletzung der Sicherheit eines oder mehrerer Peers oder des IA-Dienstes, den Verlust des Vertrauens in einen oder mehrere Peers, das Ausbleiben der Kommunikation oder der erwarteten Kommunikation von einem oder mehreren Peers oder ein anderes Ereignis beinhalten, das darauf hinweisen kann, dass das Vertrauen innerhalb der Route auf irgendeine Weise beeinträchtigt wurde. In anderen Aspekten kann das auslösende Ereignis auch ein anderes Ereignis beinhalten, das eine Maßnahme zum Drehen der RKPs auslöst. In einigen Fällen kann ein RKP, sobald er auf „Ausstellen" gesetzt wurde, dazu verwendet werden, bei Operation 312 eine Route zu erstellen.
  • Als nächstes kann das RKP bei Operation 314, wie beispielsweise durch den IA-Dienst 104, in einen veralteten Status 316 fortgeschritten werden. Veraltete RKPs sind vertrauenswürdig, aber sie werden nicht mehr für die Ausstellung neuer Zertifikate verwendet. Für den Fall, dass ein neu ausgestelltes Zertifikat fehlschlägt oder von keinem Peer in der Route empfangen wird, kann ein veraltetes RKP jedoch weiterhin zur Ausstellung von Zertifikaten verwendet werden. Da eine veraltete RKP bereits von Peers in der Route als vertrauenswürdig eingestuft wurde, kann sie weiterhin zur sicheren Kommunikation mit anderen Peers in der Route verwendet werden. Bei Operation 318 kann ein veraltetes RKP in einen deaktivierten Zustand 320 fortgeschritten werden. Deaktivierte RKPs sind nicht mehr vertrauenswürdig, werden aber aufrechterhalten, damit sie wiederbelebt werden können, falls ihre Deaktivierung operative Auswirkungen verursacht, wie beispielsweise das Verhindern der Kommunikation eines oder mehrerer Peers mit anderen Peers in der Route. Ein RKP kann in einen deaktivierten Zustand versetzt werden, wenn einige oder alle (z. B. eine bestimmte Anzahl oder ein bestimmter Prozentsatz) der Peers in einer Route bestätigen, dass das RKP nicht mehr zur Ausstellung von Zertifikaten verwendet wird. Damit soll sichergestellt werden, dass ein RKP, das gerade von einem oder mehreren Peers in der Gruppe verwendet wird, nicht deaktiviert wird und damit verhindert, dass dieser Peer mit dem Rest der Route kommuniziert.
  • Nach Erkennen eines auslösenden Ereignisses, wie beispielsweise einer Anweisung von einem Flottenverwaltungsdienst 134, kann ein RKP bei Operation 322 gelöscht werden, woraufhin der Lebenszyklus eines RKP bei Punkt 324 endet. In einigen Implementierungen verändert der IA-Dienst 104 den Zustand eines RKP nicht, ohne von einem externen System dazu aufgefordert zu werden. Jede Route weist zwangsläufig nicht reagierende Peers auf und es muss entschieden werden, ob die Rotation blockiert werden soll oder nicht. In einigen Fällen kann ein Flottenverwaltungsdienst 134 dafür verantwortlich sein, die Entscheidung zu treffen, ob ein Peer ignoriert wird oder nicht. In der Praxis kann ein Flottenverwaltungsdienst 134 tatsächlich eine Sammlung von Systemen sein, die verschiedene Gruppen von Peers auf der Route verwalten (z. B. eine für die Server und eine für jede Kundenflotte).
  • In einigen Aspekten können neue RKPs in einem bestimmten Zeitintervall zu einem Vertrauensspeicher hinzugefügt werden. Wenn ein neues RKP zum Vertrauensspeicher hinzugefügt wird, kann jedes RKP im Vertrauensspeicher in den nächsten Status oder Zustand versetzt werden, wie beispielsweise die Operationen 304, 308, 314, 318 und in einigen Fällen die Operation 322 gleichzeitig oder koordiniert durchgeführt werden können. Zum Beispiel kann die Rotationsperiode auf 24 Stunden festgelegt werden. Das Mindestalter des ältesten anhängigen RKP für den Beginn der Ausgabe: kann auf das Vierfache des Rotationszeitraums oder vier Tage festgelegt werden. In ähnlicher Weise kann die Mindestdauer des RKP bei der Entfernung auch auf das Vierfache des Rotationszeitraums, also vier Tage, festgelegt werden. Das Mindestalter eines deaktivierten RKP bei der Löschung kann auf das Vierzehnfache des Rotationszeitraums oder vierzehn Tage festgelegt werden. In einigen Fällen kann die Anzahl (z. B. die maximale Anzahl) der ausstehenden RKPs auf das Siebenfache des Rotationszeitraums oder sieben Tage festgelegt werden. Die Anzahl der ausstehenden RKPs kann auf sieben festgelegt werden, so dass eine Route eine Woche lang ausstehende Schlüsselpaare aufweist und jeden Tag zum nächsten wechselt. Der Vorteil, mehrere RKPs im Voraus aufzuweisen, besteht darin, dass der Prozess jeden Tag durchgeführt werden kann und die Peers sieben Tage im Voraus wissen, wie das Routenzertifikat in sieben Tagen aussehen wird. Dadurch haben die Peers, wie beispielsweise eine große Anzahl von Peers, ausreichend Zeit, sich zu synchronisieren. In einigen Fällen kann die Mindestanzahl der veralteten RKPs auf das Sechsfache des Rotationszeitraums oder sechs Tage festgelegt werden. Es ist zu beachten, dass die oben beschriebenen Zeitperioden und Beziehungen zwischen Zeitperioden nur beispielhaft sind und dass auch andere Zeitperioden und Beziehungen zwischen Zeitperioden in Betracht gezogen werden können.
  • 4 veranschaulicht einen beispielhaften Prozess 400 zum Drehen von Schlüsseln in einem Vertrauensspeicher 402 gemäß mindestens einer Ausführungsform. In einigen Fällen kann der Prozess 400 vom IA-Dienst 104 in Abstimmung mit dem Datenspeicherungsdienst 104, dem KMS 112 und/oder dem Flottenverwaltungsdienst 134, wie oben beschrieben, durchgeführt werden. In einigen Ausführungsformen kann jeder Peer, wie beispielsweise die Peers 118, 120, 122, einige oder alle Informationen des Vertrauensspeichers 402 aufrechterhalten und den Vertrauensspeicher in Abstimmung mit dem IA-Dienst 104 aktualisieren. In manchen Fällen aktualisieren die Peers 118, 120, 122 den Vertrauensspeicher 402 mit einer gewissen zeitlichen Verzögerung gegenüber dem IA-Dienst 104, wie beispielsweise zur Berücksichtigung von Kommunikationsverzögerungen. In einigen Fällen, wie oben unter Bezugnahme auf 2 beschrieben, kann sich jeder Peer regelmäßig beim IA-Dienst 104 melden, um den aktuellen Zustand des Vertrauensspeichers 402 zu bestimmen und seine eigene Version des Vertrauensspeichers entsprechend zu aktualisieren. In einigen Aspekten kann die individuelle Schlüsselrotation dem oben beschriebenen Prozess 300 folgen, wie beispielsweise das Hinzufügen neuer Schlüssel und das Rotieren der Zustände von Schlüsseln innerhalb des Vertrauensspeichers 402 in bestimmten Abständen.
  • In dem veranschaulichten Beispiel kann der Vertrauensspeicher 402 in einem ersten Zustand 412 eine Reihe von RKPs 306, 308 bis 310 beinhalten, wobei RKP 406 auf ausstellend und RKPs 408 bis 410 auf ausstehend gesetzt sind. Der Vertrauensspeicher 402 kann so konfiguriert werden, dass er zu einem bestimmten Zeitpunkt eine beliebige Anzahl von RKPs enthält. Der Zustand 412 des Vertrauensspeichers 402 kann einen Zeitpunkt mit einer bestimmten Anzahl von Rotationen aufweisen, wie beispielsweise zu Beginn der Einrichtung der Route, bei der keine RKPs in den veralteten Zustand versetzt wurden.
  • Nach Ablauf eines Zeitintervalls, wie beispielsweise 24 Stunden, oder nach einer Anfrage oder einem anderen auslösenden Ereignis, kann der IA-Dienst 104 bei Operation 414 überprüfen, ob die Flotte/der Peer in der Route bestätigt, dass RKP 406 gedreht oder sein Status verändert werden soll. Dies kann das Empfangen von Nachrichten oder Check-Ins von dem Peer in der Route beinhalten, die den aktuellen Status der RKPs anzeigen, die sie gerade verwenden/ in ihren Vertrauensspeichern sind. Als Nächstes kann der IA-Dienst 104 ausstehendes RKP 408 auf den Ausstellungsstatus setzen, so dass RKP in einigen Fällen sofort zur Ausstellung von Zertifikaten verwendet werden kann, die von Peers in der Route verwendet werden. Der IA-Dienst 104 kann bei Operation 418 auch das letzte oder älteste ausstehende RKP (z. B. dasjenige, das die längste Dauer oder Anzahl von Rotationsperioden im ausstehenden Zustand aufweist) in den veralteten Zustand versetzen.
  • Die Operationen 414, 416 und 418 können zu einem neuen Zustand 420 des Vertrauensspeichers 402 führen, der RKP 406 im veralteten Zustand, RKP 408 im ausstellenden Zustand und RKP 410 im ausstehenden Zustand beinhaltet. Nach Ablauf einer konfigurierbaren Zeitspanne (z. B. 24 Stunden in den oben beschriebenen Beispielen) kann eine ähnliche Reihe von Operationen wie die Operationen 4141, 416 und 418 durchgeführt werden, um einen neuen Zustand 426 des Vertrauensspeichers 402 zu erhalten, der RKP 406 und RKP 408 in einem abgelehnten Zustand, RKP 410 in einem ausgestellten Zustand und RKP 424, bei dem es sich um ein neu hinzugefügtes RKP handeln kann, in einem ausstehenden Zustand beinhaltet.
  • Zum Beispiel kann der IA-Dienst 104 bei Ablauf der nächsten Rotationsperiode bei Operation 428 überprüfen, dass das RKP 406 von den Peers der Route nicht verwendet wird. In manchen Fällen kann dies die Bestimmung beinhalten, dass eine bestimmte Anzahl von Peers in der Route kein RKP 406 verwendet. In einigen Fällen kann der Schwellenwert für alle Peers gelten, wie beispielsweise, um sicherzustellen, dass kein Peer mit einer deaktivierten Zertifizierung festsitzt, was ihn daran hindern würde, mit anderen Peers in der Route zu kommunizieren. Dieser Zyklus kann mehrmals fortgesetzt werden, bis eine Art Ablaufereignis eintritt oder die Route nicht mehr benötigt wird usw. Nachdem überprüft wurde, dass eine bestimmte Anzahl von Peers kein RKP 406 verwendet, kann der IA-Dienst 430 das RKP 406 bei Operation 430 deaktivieren. Operation 430 kann zu einem neuen Zustand 432 des Vertrauensspeichers 402 führen, der RKP 408 und RKP 410 im veralteten Zustand, RKP 424 im ausstellenden Zustand und RKP 432 im ausstehenden Zustand beinhaltet. RKP 406 kann deaktiviert und aus dem Vertrauensspeicher 402 entfernt werden. In einigen Fällen kann der RKP 406 vom IA-Dienst 104 und/oder einem oder mehreren der Peers in der Route aufrechterhalten werden, falls der RKP 406 reaktiviert werden muss, wie beispielsweise, um einem Peer, der seinen Vertrauensspeicher nicht aktualisiert hat, die Kommunikation mit anderen Peers zu ermöglichen.
  • 5 veranschaulicht ein Diagramm 500 der Eigentümerrollen für eine Route, gemäß mindestens einer Ausführungsform. In einigen Aspekten können die verschiedenen Rollen, die im Folgenden unter Bezugnahme auf Diagramm 500 beschrieben werden, von einem IAM-Dienst verwaltet werden, wie beispielsweise dem oben unter Bezugnahme auf 1 beschriebenen IAM-Dienst 134.
  • In einigen Fällen kann eine Route durch ein IAM-Konto oder eine andere bestehende Infrastruktur zur Kontoverwaltung eingerichtet, kontrolliert und verwaltet werden, wie beispielsweise durch einen IAM-Dienst 114 eines Rechenressourcendienstanbieters 102 bereitgestellt. In Beispielen, in denen Peer-Vorrichtungen einer Route in Kunden-Server-Rollen aufgeteilt sind, würde ein Serviceteam oder eine Einrichtung, die den Server steuert, die Route kontrollieren, da sie den Zugang zum Server kontrolliert. Das Eigentümerkonto kontrolliert den Zugang zur Route, indem es die Strategien für die Berechtigungen der IAM-Entitäten (Benutzer, Gruppen, Rollen) innerhalb des Eigentümerkontos steuert. Das Konto, das eine Route verwaltet, wird als des Routenkontoeigentümer 502 bezeichnet. Ein Routenkontoeigentümer kann mehrere Routen 508, 510, 512 besitzen und verschiedene Rollen 504, 506 konfigurieren und kontrollieren, die unterschiedliche Levels des Zugangs zu den Routen 508, 510, 512 erlauben.
  • Eine Möglichkeit, von einem anderen Konto aus Zugang zu einer Route zu erhalten, sind die über den IAM-Dienst 114 eingerichteten Rollen 504, 506. Die IAM-Einheit im Kunden-Konto übernimmt eine Rolle für den Zugang zu dem Konto, dem die Route gehört, und verwendet die angenommene Rolle, um mit dem IA-Dienst 104 zu sprechen. Darüber hinaus können die Routeneigentümer die Authentifizierung und Autorisierung jeglicher Art organisieren. Der lA-Dienst 104 prüft in der Regel nur, ob eine IAM-Identität die angeforderte Operation auf einer Route durchführen darf und verlangt, dass beide im selben Konto sind.
  • Eine Möglichkeit, IAM-Konten zu identifizieren, die die Rolle des Zugangs zur Route übernehmen dürfen, sind die internen Dienstprinzipien. Der Routeneigentümer 502 erstellt die Rolle 504, 506 für den Zugang zur Route in seinem Konto. Die Strategie für die Berechtigungen der Rolle (was die Rolle tun kann) erlaubt den Zugang zu einer Route. In dem veranschaulichten Beispiel hat die Rolle 504 Zugang zu den Routen 508 und 510, während die Rolle 506 Zugang zu den Routen 510 und 512 hat. Die Strategie für die Rollenübernahme (welche Entität die Rolle übernehmen kann) erlaubt es den verschiedenen Kontodienstentitäten 514, 516, 18, die Rolle zu übernehmen. Diese Rolle (und ihre Geschwister, eine Route kann mehrere Rollen aufweisen) ist für die Kontrolle des Zugangs zu der Route verantwortlich. Kundenvorrichtungen/Konten 520 haben die Freiheit, Berechtigungen in ihren Konten zu organisieren. Der Routeneigentümer 502 braucht nur die Kontodienststelle zu kennen, um einem Unternehmen den Zugang zu einer Route zu ermöglichen. In diesem Szenario müssen Sie keine Listen mit Konto-IDs, IAM-Entity-IDs, Rollennamen usw. verwalten.
  • Kundenkonten 520 verwenden in der Regel eine Art Identitäts-/Infrastrukturrolle 522 auf ihrer Seite, um den Zugang zu Routen zu kontrollieren, zu denen ihr Konto über seine Kontodienststelle 518 Zugang erhalten hat. Die Infrastrukturrolle 522 kann in ein kurzfristiges System zur Verwaltung von Berechtigungsnachweisen integriert werden, um automatisch den richtigen Hosts oder Menschen zu erlauben, die Rolle zu übernehmen.
  • 6 veranschaulicht einen beispielhaften Prozess 600 zur Verwaltung eines Vertrauensspeichers, der es Peer-Vorrichtungen einer Route ermöglicht, sicher miteinander zu kommunizieren. Der Prozess 600 kann von einem oder mehreren des IA-Dienstes 104, des Datenspeicherungsdienstes 106, des KMS 112, des Flottenverwaltungssystems 134 und/oder des IAM-Dienstes 114 der bereitgestellten Rechenressourcendienstanbieter 102 durchgeführt werden, wie oben ausführlicher beschrieben. Der Prozess 600 kann das oben unter Bezugnahme auf 2 beschriebene Kommunikationsschema 200 und/oder die Struktur oder den Prozess der rotierenden RKP/Zertifikate verwenden, wie oben unter Bezugnahme auf 3 und 4 beschrieben. Prozess 600 kann zusätzlich oder alternativ eine Rollenstruktur implementieren, wie beispielsweise die oben unter Bezugnahme auf 5 beschriebene Rollenstruktur 500.
  • Der Prozess 600 beginnt mit Operation 602, wobei ein IA-Dienst, wie beispielsweise Dienst 104, eine Anfrage zum Erzeugen eines Peer-Zertifikats von einem Peer empfängt, der einer Route zugeordnet oder Teil einer Route ist, wie beispielsweise ein Peer 118, 120, 122 oder eine Route 116. Operation 602 und die Anfrage selbst können einen oder mehrere Aspekte der oben unter Bezugnahme auf 2 beschriebenen IssuePeerCertifcate API beinhalten. Der IA-Dienst 104 kann als Antwort auf die Anfrage bei Operation 604 ein Peer-Zertifikat erzeugen, das auf dem der Route zugeordneten Ausstellungszertifikat basiert. Die Erzeugung des Peer-Zertifikats kann auf einem RKP basieren, das im Vertrauensspeicher gespeichert ist und/oder auf das über das KMS 112 zugegriffen wird. Wie in 6 beschrieben, kann ein Verweis auf ein Zertifikat, das unter Verwendung eines zugrundeliegenden RKP ausgestellt wurde, zusätzlich oder alternativ auch das zugrundeliegende RKP betreffen.
  • Der IA-Dienst 104 kann bei Operation 606 eine Anzeige empfangen, die einen Satz von Zertifikaten angibt, denen verschiedene Peers auf der Route vertrauen. Wie oben beschrieben, können Peers den Status ihres Vertrauensspeichers in regelmäßigen Abständen, wie beispielsweise stündlich, an den IA-Dienst 104 berichten, um die Trust Scores über eine Route hinweg zu synchronisieren. Operation 606 kann das Erhalten, wie beispielsweise durch den IA-Dienst 104, erster Daten von einem Peer-Rechensystem beinhalten, die einen Satz von Zertifikaten anzeigen, denen das Peer-Rechensystem vertraut.
  • Der IA-Dienst 104 kann bei Operation 608 den Vertrauensspeicher aktualisieren, der die von den Peers auf der Route vertrauenswürdigen Zertifikate verfolgt, wie oben beschrieben. Operation 608 kann das Aktualisieren von zweiten Daten durch den IA-Dienst 104 basierend auf den ersten Daten beinhalten, die Zertifikate verfolgen, denen eine Vielzahl von Peer-Rechensystemen vertraut, zu denen das Peer-Rechensystem gehört.
  • Der IA-Dienst 104 kann bei Operation 609 bestimmen, ob eine oder mehrere Bedingungen für die Zertifikatsrotation erfüllt sind (z. B. eine Reihe von Bedingungen). Die eine oder mehrere Bedingungen können das Verstreichen einer Regelmäßigkeit beinhalten, die eine aktive Schlüsselrotation auslöst, eine spezielle Anforderung zur Schlüsselrotation oder andere Ereignisse, die eine Rotation der von den Peers in der Route verwendeten Zertifikate sinnvoll machen. In einigen Fällen kann die Operation 609 beinhalten, dass der IA-Dienst 104 eine Bestimmung bestimmt, dass eine Gruppe von Peers, die individuell mindestens einem öffentlichen Schlüssel aus einer Vielzahl von öffentlichen Schlüsseln vertrauen, eine Reihe von Bedingungen erfüllt, wie beispielsweise basierend auf den bei Operation 606 empfangenen Berichten.
  • Ein Zertifikat kann in den Operationen 610 und 612 entfernt werden, wenn - und in manchen Fällen nur dann - wenn bestimmte Bedingungen für die Entfernung erfüllt sind. In einigen Beispielen kann ein Zertifikat nach Erhalt einer Anweisung zum Entfernen des Zertifikats von einer autorisierten Stelle, wie beispielsweise einem Flottenverwaltungssystem 134, entfernt werden. Wenn die Bedingung(en) erfüllt sind, kann das Zertifikat bei Operation 610 aus dem vom IA-Dienst aufrechterhaltenen Vertrauensspeicher entfernt werden, und zwar bei Operation 612. Wenn die Bedingungen nicht erfüllt sind oder nach dem Durchführen von Operation 612, kann ein ausstehendes Zertifikat dem Vertrauensspeicher hinzugefügt werden (Operation 614).
  • Das zuvor als ausgestellt angezeigte Zertifikat kann bei Operation 616 auf den Status „veraltet" geändert werden, und ein ausstehendes Zertifikat (z. B. das älteste ausstehende Zertifikat) kann bei Operation 618 auf den Status „ausgestellt" geändert werden. Der Ausstellungsstatus kann einen Status beinhalten, der es erlaubt, dass das Zertifikat von den Peers in der Route für die Peer-to-Peer-Kommunikation verwendet werden kann (z. B. zum Signieren/Verschlüsseln und Entschlüsseln von Nachrichten). Der aktualisierte Vertrauensspeicher, der die Zertifikate und ihren entsprechenden Status beinhaltet, kann dann bei Operation 620 an mindestens einen der Peers in der Route kommuniziert werden. Wie oben beschrieben, können die Operationen 606, 608, 609, 610, 612, 614, 616 und 618 einen oder mehrere Aspekte der oben beschriebenen Prozesse 300 und 400 beinhalten, wie beispielsweise das Drehen des RKP/Zertifikats zwischen den Zuständen „ausstehend ,,, „ausgestellt ,,, „veraltet" und „deaktiviert".
  • 7 veranschaulicht Aspekte eines beispielhaften Systems 700 zur Implementierung von Aspekten gemäß einer Ausführungsform. Obwohl zu Zwecken der Erläuterung ein webbasiertes System verwendet wird, versteht es sich, dass gegebenenfalls andere Systeme verwendet werden können, um verschiedene Ausführungsformen umzusetzen. In einer Ausführungsform beinhaltet das System eine oder mehrere Kunden- oder Peer-Vorrichtungen 118, 120, wobei jede geeignete Vorrichtung betrieben werden kann, um Anfragen, Nachrichten oder Informationen über ein geeignetes Netzwerk 704 zu senden und/oder zu empfangen und Informationen an einen Benutzer der Vorrichtung zurück zu übermitteln. Zu Beispielen für derartige Kundenvorrichtungen gehören PCs, Handys oder andere Mobiltelefone, tragbare Messaging-Vorrichtungen, Laptop-Computer, Tablet-Computer, Set-Top-Boxen, Personal Data Assistants, eingebettete Computersysteme, E-Book-Reader und dergleichen. In einer Ausführungsform beinhaltet das Netzwerk jedes geeignete Netzwerk, einschließlich eines Intranets, des Internets, eines zellularen Netzwerks, eines lokalen Netzwerks, eines Satellitennetzwerks oder eines anderen derartigen Netzwerks und/oder einer Kombination davon, und die für ein solches System verwendeten Komponenten hängen zumindest teilweise von der Art des ausgewählten Netzwerks und/oder Systems ab. Viele Protokolle und Komponenten zum Kommunizieren über ein derartiges Netzwerk sind hinlänglich bekannt und werden hier nicht ausführlich erörtert. In einer Ausführungsform wird die Kommunikation über das Netzwerk durch drahtgebundene und/oder drahtlose Verbindungen und deren Kombinationen ermöglicht. In einer Ausführungsform beinhaltet das Netzwerk das Internet und/oder andere öffentlich zugängliche Kommunikationsnetze, da das System einen Webserver 706 zum Empfangen von Aufforderungen und Darbieten von Inhalt als Reaktion darauf beinhaltet, wobei für andere Netzwerke eine alternative Vorrichtung, die einen ähnlichen Zweck erfüllt, verwendet werden könnte, wie es für den Durchschnittsfachmann ersichtlich ist.
  • Wie veranschaulicht, kann jede Kunden- oder Peer-Vorrichtung 118, 120 einen Vertrauensspeicher 402 aufrechterhalten, wie er beispielsweise von einem oder mehreren Anwendungsservern 708 verwaltet wird. Der Vertrauensspeicher kann verschiedene RKPs/Zertifikate speichern, wie beispielsweise das Zertifikat 124, das die Peers 118, 120 verwenden können, um über die oben beschriebenen Techniken sicher miteinander zu kommunizieren.
  • In einer Ausführungsform beinhaltet das dargestellte System mindestens einen Anwendungsserver 708 und einen Datenspeicher 710, und es versteht sich, dass mehrere Anwendungsserver, Schichten oder andere Elemente, Prozesse oder Komponenten vorliegen können, die verkettet oder anderweitig konfiguriert sein können und die interagieren können, um Aufgaben durchzuführen, wie etwa Erhalten von Daten von einem zweckmäßigen Datenspeicher. In einer Ausführungsform sind Server als Hardwarevorrichtungen, virtuelle Computersysteme, Programmiermodule, die auf einem Computersystem ausgeführt werden, und/oder andere Vorrichtungen implementiert, die mit Hardware und/oder Software so konfiguriert sind, dass sie Kommunikationen (z. B. Web Service Application Programming Interface (API) Anfragen) über ein Netzwerk empfangen und beantworten. Es sei denn, etwas anderes ist angegeben oder ergibt sich aus dem Kontext, bezieht sich der Ausdruck „Datenspeicher" im hier verwendeten Sinne auf eine beliebige Vorrichtung oder Kombination aus Vorrichtungen, die dazu in der Lage ist, Daten zu speichern, darauf zuzugreifen und diese abzurufen, was eine beliebige Kombination und Anzahl von Datenservern, Datenbanken, Datenspeichervorrichtungen und Datenspeichermedien in einem beliebigen standardmäßigen, verteilten, virtuellen oder geclusterten System einschließen kann. In einer Ausführungsform kommunizieren die Datenspeicher mit Schnittstellen auf Block- und/oder Objekt-Ebene. Der Anwendungsserver kann bei Bedarf eine beliebige zweckmäßige Hardware, Software und Firmware zum Integrieren in den Datenspeicher beinhalten, um Aspekte von einer oder mehreren Anwendungen für die Kundenvorrichtung auszuführen und einen Teil des Datenzugriffs und der Geschäftslogik oder den gesamten Datenzugriff und die gesamte Geschäftslogik für eine Anwendung zu handhaben.
  • In einer Ausführungsform stellt der Anwendungsserver in Zusammenarbeit mit dem Datenspeicher Zugangskontrolldienste bereit und erzeugt Inhalte, einschließlich, aber nicht beschränkt auf Text, Grafiken, Audio, Video und/oder andere Inhalte, die einem mit der Vorrichtung verbundenen Benutzer vom Webserver in Form von HyperText Markup Language („HTML"), Extensible Markup Language („XML”), JavaScript, Cascading Style Sheets ( „CSS"), JavaScript Object Notation (JSON) und/oder einer anderen geeigneten kundenseitigen oder anderen strukturierten Sprache bereitgestellt werden. Inhalte, die an eine Kundenvorrichtung übertragen werden, werden in einer Ausführungsform durch die Kundenvorrichtung verarbeitet, um die Inhalte in einer oder mehreren Formen bereitzustellen, darunter unter anderem Formen, die akustisch, visuell und/oder mithilfe anderer Sinne für den Benutzer wahrnehmbar sind. Die Handhabung aller Anforderungen und Reaktionen sowie die Zuführung von Inhalten zwischen der Kundenvorrichtung und dem Anwendungsserver 708 werden in einer Ausführungsform durch den Webserver unter Verwendung von PHP: Hypertext Preprocessor („PHP”), Python, Ruby, Perl, Java, HTML, XML, JSON und/oder in diesem Beispiel eine andere zweckmäßige serverseitige strukturierte Sprache gehandhabt. In einer Ausführungsform werden die hierin beschriebenen Operationen, die von einer einzelnen Vorrichtung durchgeführt werden, gemeinsam von mehreren Vorrichtungen durchgeführt, die ein verteiltes und/oder virtuelles System bilden.
  • Der Datenspeicher 710 beinhaltet in einer Ausführungsform mehrere separate Datentabellen, Datenbanken, Datendokumente, dynamische Datenspeicherschemata und/oder andere Datenspeichermechanismen und Medien zum Speichern von Daten in Bezug auf einen bestimmten Aspekt der vorliegenden Offenbarung. In einer Ausführungsform beinhaltet der veranschaulichte Datenspeicher Mechanismen zum Speichern von Produktionsdaten 712 und Benutzerinformationen 716, die zur Bereitstellung von Inhalten für die Produktionsseite verwendet werden. Der Datenspeicher beinhaltet auch einen Mechanismus zum Speichern von Logdaten 714, wobei diese in einer Ausführungsform für Berichte, die Verwaltung von Rechenressourcen, Analysen oder andere derartige Zwecke verwendet werden. In einer Ausführungsform werden andere Aspekte wie Bilddaten und Informationen über Zugriffsrechte (z. B. Strategien zur Kontrolle des Zugriffs oder andere Kodierungen von Berechtigungen) im Datenspeicher in einem der oben aufgeführten Mechanismen oder in zusätzlichen Mechanismen im Datenspeicher 710 gespeichert.
  • In einer Ausführungsform ist der Datenspeicher 710 über eine ihm zugeordnete Logik in der Lage, Anweisungen vom Anwendungsserver 708 aufzunehmen und als Reaktion darauf Daten zu erhalten, zu aktualisieren oder anderweitig zu verarbeiten, und der Anwendungsserver 708 stellt als Reaktion auf die empfangenen Anweisungen statische, dynamische oder eine Kombination aus statischen und dynamischen Daten bereit. In einer Ausführungsform werden dynamische Daten, wie etwa Daten, die in Weblogs (Blogs), Shopping-Anwendungen, Nachrichtendiensten und anderen solchen Anwendungen verwendet werden, durch serverseitige strukturierte Sprachen generiert, wie hierin beschrieben, oder durch ein Content Management System („CMS") bereitgestellt, das auf dem oder gesteuert von dem Anwendungsserver betrieben wird. In einer Ausführungsform übermittelt ein Benutzer durch eine durch den Benutzer betriebene Vorrichtung eine Suchanfrage nach einer gewissen Art von Element. In diesem Beispiel greift der Datenspeicher auf die Benutzerinformationen zu, um die Identität des Benutzers zu überprüfen, greift auf die Katalogdetailinformationen zu, um Informationen über Artikel dieses Typs zu erhalten, und gibt die Informationen an den Benutzer zurück, wie beispielsweise in einer Ergebnisliste auf einer Webseite, die der Benutzer über einen Browser auf der Benutzervorrichtung 118, 120 betrachtet. Um bei diesem Beispiel zu bleiben: Informationen für ein spezielles Element von Interesse können auf einer dedizierten Seite oder in einem dedizierten Fenster des Browsers betrachtet werden. Es ist jedoch anzumerken, dass Ausführungsformen der vorliegenden Offenbarung nicht notwendigerweise auf den Kontext von Webseiten beschränkt sind, sondern allgemeiner auf die Verarbeitung von Anforderungen im Allgemeinen anwendbar sind, wobei es sich bei den Anforderungen nicht notwendigerweise um Inhaltsanforderungen handelt. Beispielanfragen beinhalten Anfragen zum Verwalten und/oder Interagieren mit Rechenressourcen, die von dem System 700 und/oder einem anderen System gehostet werden, wie beispielsweise zum Starten, Beenden, Löschen, Ändern, Lesen und/oder anderweitigen Zugriff auf solche Rechenressourcen.
  • In einer Ausführungsform beinhaltet jeder Server typischerweise ein Betriebssystem, das ausführbare Programmanweisungen für die allgemeine Verwaltung und den Betrieb dieses Servers bereitstellt und ein computerlesbares Speichermedium (z. B. eine Festplatte, einen Direktzugriffsspeicher, einen Nur-Lese-Speicher usw.) enthält, auf dem Anweisungen gespeichert sind, die, wenn sie von einem Prozessor des Servers ausgeführt werden, bewirken oder anderweitig ermöglichen, dass der Server seine beabsichtigten Funktionen ausführt (z. B. werden die Funktionen ausgeführt, wenn ein oder mehrere Prozessoren des Servers Anweisungen ausführen, die auf einem computerlesbaren Speichermedium gespeichert sind).
  • Bei dem System 700 handelt es sich in einer Ausführungsform um ein verteiltes und/oder virtuelles Rechensystem, das mehrere Computersysteme und Komponenten verwendet, die über Kommunikationsverbindungen (z. B. TCP-Verbindungen und/oder TLS- oder andere kryptografisch geschützte Kommunikationssitzungen) miteinander verbunden sind, wobei ein oder mehrere Computernetzwerke oder Direktverbindungen verwendet werden. Fachleute werden jedoch beachten, dass ein solches System auch in einem System mit weniger oder einer größeren Anzahl von Komponenten als in 7 veranschaulicht arbeiten könnte. Daher ist die Darstellung des Systems 700 in 7 als veranschaulichend und nicht als einschränkend für den Umfang der Offenbarung zu verstehen. In einigen Beispielen kann der Datenspeicher einen Vertrauensspeicher 402 speichern und aufrechterhalten, wie beispielsweise durch das Rotieren von Schlüsseln durch den Vertrauensspeicher, um den Peer-Vorrichtungen 118, 120 eine sichere Kommunikation miteinander zu ermöglichen, und zwar über die oben beschriebenen Techniken.
  • Die verschiedenen Ausführungsformen können ferner in einer breiten Vielfalt von Betriebsumgebungen umgesetzt sein, zu denen in einigen Fällen ein oder mehrere Benutzercomputer, Rechenvorrichtungen oder Verarbeitungsvorrichtung gehören können, die dazu verwendet werden können, eine beliebige Anzahl von Anwendungen zu betreiben. In einer Ausführungsform beinhalten die Benutzer- oder Kundenvorrichtungen eine beliebige Anzahl von Computern, wie z. B. Desktop-, Laptop- oder Tablet-Computer, auf denen ein Standard-Betriebssystem läuft, sowie zellulare (mobile), drahtlose und Handheld-Vorrichtungen, auf denen mobile Software läuft und die in der Lage sind, eine Reihe von Netzwerk- und Nachrichtenprotokollen zu unterstützen. Ein solches System beinhaltet auch eine Reihe von Workstations, auf denen eine beliebige Anzahl von im Handel erhältlichen Betriebssystemen und anderen bekannten Anwendungen für Zwecke wie Entwicklung und Datenbankverwaltung laufen. In einer Ausführungsform beinhalten diese Vorrichtungen auch andere elektronische Vorrichtung, wie beispielsweise Dummy-Terminals, Thin-Clients, Spielsysteme und andere Vorrichtungen, die in der Lage sind, über ein Netzwerk zu kommunizieren, sowie virtuelle Vorrichtungen wie virtuelle Maschinen, Hypervisoren, Software-Container, die Virtualisierung auf Betriebssystemebene nutzen, und andere virtuelle Vorrichtungen oder nicht-virtuelle Vorrichtungen, die Virtualisierung unterstützen und in der Lage sind, über ein Netzwerk zu kommunizieren.
  • In einer Ausführungsform nutzt ein System zumindest ein Netzwerk, das einem Fachmann bekannt ist, um Kommunikation unter Verwendung von einem beliebigen einer Vielzahl von handelsüblichen Protokollen zu unterstützen, wie etwa dem Transmission Control Protocol/Internet Protocol („TCP/IP”), dem User Datagram Protocol („UDP”), von Protokollen, die in verschiedenen Schichten des Open-System-Interconnection-Modells („OSI ”-Modells) arbeiten, dem File Transfer Protocol („FTP"), Universal Plug and Play („UpnP ”), dem Network File System („NFS"), dem Common Internet File System („CIFS") und AppleTalk. Das Netzwerk ist in einer Ausführungsform ein lokales Netzwerk, ein Weitbereichsnetzwerk, ein virtuelles privates Netzwerk, das Internet, ein Intranet, ein Extranet, ein öffentliches Fernsprechwählnetz, ein Infrarot-Netzwerk, ein Drahtlosnetzwerk, ein Satellitennetzwerk und eine beliebige Kombination daraus. In einer Ausführungsform wird ein verbindungsorientiertes Protokoll für die Kommunikation zwischen Netzwerk-Endpunkten verwendet, so dass das verbindungsorientierte Protokoll (manchmal auch als verbindungsbasiertes Protokoll bezeichnet) in der Lage ist, Daten in einem geordneten Strom zu übertragen. In einer Ausführungsform können verbindungsorientierte Protokolle zuverlässig oder unzuverlässig sein. Zum Beispiel handelt es sich bei dem TCP-Protokoll um ein zuverlässiges verbindungsorientiertes Protokoll. Bei dem Asynchronous Transfer Mode ( „ATM”) und Frame Relay handelt es sich um unzuverlässige verbindungsorientierte Protokolle. Verbindungsorientierte Protokolle stehen im Gegensatz zu paketorientierten Protokollen, wie etwa UDP, die Pakete ohne eine garantierte Ordnung übertragen.
  • In einer Ausführungsform verwendet das System einen Webserver, auf dem eine oder mehrere einer Vielzahl von Server- oder Mid-Tier-Anwendungen laufen, einschließlich Hypertext Transfer Protocol(„HTTP”)-Server, FTP-Server, Common Gateway Interface( „CGI”)-Server, Datenserver, Java-Server, Apache-Server und Server für Geschäftsanwendungen. Der bzw. die Server ist bzw. sind in einer Ausführungsform zudem dazu in der Lage, Programme oder Skripte als Reaktion auf Anforderungen von Benutzervorrichtungen auszuführen, wie etwa durch Ausführen von einer oder mehreren Webanwendungen, die als ein oder mehrere Skripte oder Programme implementiert sind, die in einer beliebigen Programmiersprache geschrieben sind, wie etwa Java®, C, C# oder C++ oder einer beliebigen Skriptsprache wie etwa Ruby, PHP, Perl, Python oder TCL sowie Kombinationen daraus. Der bzw. die Server beinhaltet bzw. beinhalten in einer Ausführungsform zudem Datenbankserver, zu denen unter anderem diejenigen gehören, die von Oracle®, Microsoft®, Sybase® und IBM® im Handel erhältlich sind, sowie Open-Source-Server, wie etwa MySQL, Postgres, SQLite, MongoDB und beliebige andere Server, die in der Lage sind, strukturierte oder unstrukturierte Daten zu speichern, abzurufen und darauf zuzugreifen. In einer Ausführungsform gehören zu Datenbankservern tabellenbasierte Server, dokumentbasierte Server, unstrukturierte Server, relationelle Server, nicht-relationelle Server oder Kombinationen davon und/oder von anderen Datenbankservern.
  • In einer Ausführungsform beinhaltet das System eine Vielzahl von Datenspeichern und anderen Speicher- und Speichermedien, wie oben beschrieben, die an vielfältigen Stellen angeordnet sein können, wie etwa auf einem Speichermedium, das zu einem oder mehreren der Computer lokal (und/oder darin angeordnet) ist oder von beliebigen oder allen der Computer über das Netzwerk hinweg entfernt ist. In einer Ausführungsform befinden sich die Informationen in einem Speichervorrichtungs-Netzwerk („SAN”), das dem Fachmann bekannt ist, und gleichermaßen sind beliebige erforderliche Dateien zum Durchführen der Funktionen, die den Computern, Servern oder anderen Netzwerkvorrichtungen zugeschrieben sind, gegebenenfalls lokal und/oder entfernt gespeichert. In einer Ausführungsform, wenn ein System computergestützte Vorrichtungen beinhaltet, beinhaltet jede derartige Vorrichtung Hardwareelemente, die über einen Bus elektrisch gekoppelt sein können, wobei die Elemente zum Beispiel zumindest eine zentrale Verarbeitungseinheit („CPU” oder „Prozessor"), zumindest eine Eingabevorrichtung (z. B. eine Maus, eine Tastatur, einen Controller, einen Touchscreen oder ein Tastenfeld) und zumindest eine Ausgabevorrichtung (z. B. eine Anzeigevorrichtung, einen Drucker oder einen Lautsprecher), mindestens eine Speichervorrichtung wie Festplattenlaufwerke, optische Zustände und Speichervorrichtungen wie Direktzugriffsspeicher („RAM“) oder Nur-Lese-Speicher („ROM”) sowie austauschbare Medienvorrichtungen, Speicherkarten, Flash-Karten usw. und verschiedene Kombinationen davon.
  • In einer Ausführungsform beinhaltet eine solche Vorrichtung auch ein Lesegerät für computerlesbare Speichermedien, eine Kommunikationsvorrichtung (z. B. ein Modem, eine Netzwerkvorrichtung (drahtlos oder verdrahtet), eine Infrarot-Kommunikationsvorrichtung usw.) und einen Arbeitsspeicher wie oben beschrieben, wobei das Lesegerät für computerlesbare Speichermedien mit einem computerlesbaren Speichermedium verbunden oder so konfiguriert ist, dass es dieses empfängt, das entfernte, lokale, feste und/oder entfernbare Speichervorrichtungen sowie Speichermedien zum vorübergehenden und/oder dauerhaften Aufnehmen, Speichern, Übertragen und Abrufen computerlesbarer Informationen darstellt. In einer Ausführungsform beinhalten das System und die verschiedenen Vorrichtungen außerdem üblicherweise eine Reihe von Softwareanwendungen, Modulen, Diensten oder anderen Elementen, die innerhalb zumindest einer Arbeitsspeichervorrichtung angeordnet sind, einschließlich eines Betriebssystems und Anwendungsprogrammen, wie etwa einer Kundenanwendung oder eines Webbrowsers. In einer Ausführungsform wird kundenspezifische Hardware verwendet und/oder bestimmte Elemente werden in Hardware, Software (einschließlich tragbarer Software, wie beispielsweise Applets) oder beides implementiert. In einer Ausführungsform werden Verbindungen zu anderen Rechenvorrichtungen wie Netzwerkvorrichtungen für die Eingabe/Ausgabe verwendet.
  • In einer Ausführungsform beinhalten Speichermedien und computerlesbare Medien, die Code oder Teile von Code enthalten, beliebige zweckmäßige Medien, die auf dem Fachgebiet bekannt sind oder verwendet werden, einschließlich Speichermedien und Kommunikationsmedien, wie etwa unter anderem flüchtige und nichtflüchtige, entfernbare und nicht entfernbare Medien, die in einem beliebigen Verfahren oder einer beliebigen Technik zur Speicherung und/oder Übertragung von Informationen implementiert sind, wie etwa computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen oder anderen Daten, darunter RAM, ROM, elektrisch löschbarer programmierbarer Festwertspeicher („EEPROM "), Flash-Speicher oder eine andere Speichertechnik, Compact-Disc-Festwertspeicher („CD-ROM"), Digital Versatile Disk (DVD) oder ein anderer optischer Speicher, Magnetkassetten, ein Magnetband, ein Magnetplattenspeicher oder eine andere Magnetspeichervorrichtungen oder ein beliebiges anderes Medium, das dazu verwendet werden kann, die gewünschten Information zu speichern, und auf das durch eine Systemvorrichtung zugegriffen werden kann. Auf Grundlage der Offenbarung und der hier bereitgestellten Lehren versteht der Durchschnittsfachmann, dass andere Möglichkeiten und/oder Verfahren vorhanden sind, um die verschiedenen Ausführungsformen zu implementieren.
  • Die Beschreibung und die Zeichnungen sind dementsprechend in einem veranschaulichenden und nicht einschränkenden Sinne zu verstehen. Es versteht sich jedoch, dass verschiedene Modifikationen und Änderungen daran vorgenommen werden können, ohne vom weiteren Geist und Umfang der Erfindung abzuweichen, die in den Patentansprüchen dargelegt sind.
  • Andere Variationen liegen innerhalb des Umfangs der vorliegenden Offenbarung. Somit können zwar bezüglich der offenbarten Techniken diverse Modifikationen und alternative Konstruktionen vorgenommen werden, bestimmte veranschaulichte Ausführungsformen davon werden jedoch in den Zeichnungen gezeigt und wurden vorangehend ausführlich beschrieben. Allerdings versteht es sich, dass nicht die Absicht verfolgt wird, die Erfindung auf die konkrete(n) offenbarte(n) Form oder Formen einzuschränken, sondern die Absicht ganz im Gegenteil darin besteht, sämtliche Modifikationen, alternativen Konstruktionen und Äquivalente abzudecken, die in den Geist und Umfang der wie in den beigefügten Ansprüchen definierten Erfindung abzudecken.
  • Die Verwendung der Begriffe „ein" und „eine” und „der/die/das” und ähnlicher Referenten im Zusammenhang der Beschreibung der offenbaren Ausführungsformen (besonders im Zusammenhang der folgenden Patentansprüche) soll so ausgelegt werden, dass sie sowohl den Singular als auch den Plural abdeckt, sofern hierin nicht anderweitig angegeben oder im eindeutigen Widerspruch zum Kontext. Ebenso ist die Verwendung des Begriffs „oder „im Sinne von „und/oder” zu verstehen, sofern nicht ausdrücklich oder durch den Kontext widersprochen wird. Die Begriffe „umfassend ,,, „aufweisend ,,, „beinhaltend" und „enthaltend" sind als offene Begriffe auszulegen (d. h. in der Bedeutung „einschließlich, jedoch nicht darauf beschränkt”), es sei denn, es ist etwas anderes angegeben. Der Begriff „verbunden" ist als teilweise oder vollständig ineinander enthalten, aneinander befestigt oder aneinander angefügt auszulegen, wenn er unmodifiziert vorliegt und sich auf physische Verbindungen bezieht, selbst, wenn ein Element dazwischen eingefügt ist. Die Nennung von Wertebereichen hierin soll lediglich als schnelles Verfahren des einzelnen Bezugnehmens auf jeden separaten Wert dienen, der in den Bereich fällt, es sei denn, hierin ist etwas anderes angegeben, und jeder separate Wert ist in die Beschreibung eingeschlossen, als ob er einzeln hierin wiedergegeben wäre. Die Verwendung des Begriffs „Satz" (z. B. „ein Satz von Objekten") oder „Teilsatz" ist als eine nicht leere Zusammenstellung auszulegen, die ein oder mehrere Elemente umfasst, es sei denn, es ist etwas anderes angemerkt oder dies widerspricht dem Kontext. Ferner bezeichnet der Begriff „Teilsatz” eines entsprechenden Satzes nicht notwendigerweise einen tatsächlichen Teilsatz des entsprechenden Satzes; vielmehr können der Teilsatz und der entsprechende Satz gleich sein, es sei denn, es ist etwas anderes angemerkt oder dies widerspricht dem Kontext. Die Verwendung der Formulierung „basierend auf” bedeutet, sofern nicht ausdrücklich anders angegeben oder aus dem Kontext ersichtlich, „zumindest teilweise basierend auf” und ist nicht beschränkt auf „ausschließlich basierend auf".
  • Konjunktionale Sprache, wie beispielsweise Sätze der Form „mindestens eines von A, B und C" oder „mindestens eines von A, B und C" (d. h. derselbe Satz mit oder ohne Oxford-Komma) wird, sofern nicht ausdrücklich anders angegeben oder anderweitig eindeutig durch den Kontext widersprochen, im Rahmen des Kontexts so verstanden, wie sie im Allgemeinen verwendet wird, um darzulegen, dass ein Element, Begriff usw. entweder A oder B oder C, eine beliebige nicht leere Teilmenge der Menge von A und B und C oder eine beliebige, nicht durch den Kontext widerlegte oder anderweitig ausgeschlossene Menge sein kann, die mindestens ein A, mindestens ein B oder mindestens ein C enthält. Zum Beispiel betreffen in dem veranschaulichenden Beispiel einer Menge mit drei Elementen die konjunktiven Ausdrücke „mindestens eines von A, B und C” und „mindestens eines von A, B und C” jede der folgenden Mengen: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}, und, falls nicht explizit oder durch den Kontext widersprochen wird, jede Menge, die {A}, {B} und/oder {C} als Teilmenge aufweist (z. B. Mengen mit mehreren „A”). Somit soll solche verbindende Sprache im Allgemeinen nicht ausdrücken, dass bestimmte Ausführungen erforderlich machen, dass zumindest eines von A, zumindest eines von B und zumindest eines von C vorhanden ist. In ähnlicher Weise betreffen Ausdrücke wie „mindestens eines von A, B oder C” und „mindestens eines von A, B oder C" dasselbe wie „mindestens eines von A, B und C" und „mindestens eines von A, B und C" eine der folgenden Mengen: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}, es sei denn, eine andere Bedeutung ist ausdrücklich angegeben oder geht aus dem Kontext hervor. Außerdem zeigt der Begriff „Vielzahl" einen Zustand der Mehrzahl an (z. B. „eine Vielzahl von Elementen" bedeutet mehrere Elemente), sofern nicht anders angegeben oder durch den Kontext widerlegt. Die Anzahl der Elemente in einer Vielzahl beträgt mindestens zwei, kann aber auch höher sein, wenn dies entweder ausdrücklich oder durch den Kontext angezeigt wird.
  • Hierin beschriebene Vorgänge von Prozessen können in einer beliebigen geeigneten Reihenfolge durchgeführt werden, sofern es hier nicht anders angegeben ist oder der Kontext dem anderweitig eindeutig widerspricht. In einer Ausführungsform wird ein Prozess, wie beispielsweise die hierin beschriebenen Prozesse (oder Variationen und/oder Kombinationen davon) unter der Steuerung von einem oder mehreren Computersystemen ausgeführt, die mit ausführbaren Anweisungen konfiguriert sind, und können als Code (z. B. ausführbare Anweisungen, ein oder mehrere Computerprogramme oder eine oder mehrere Anwendungen), die zusammen einen oder mehrere Prozessoren ausführen, durch Hardware oder Kombinationen davon implementiert sein. In einer Ausführungsform ist der Code auf einem computerlesbaren Speichermedium gespeichert, zum Beispiel in Form eines Computerprogramms, das eine Vielzahl von Anweisungen umfasst, die durch einen oder mehrere Prozessoren ausgeführt werden können. In einer Ausführungsform ist ein computerlesbares Speichermedium ein nichtflüchtiges computerlesbares Speichermedium, das transitorische Signale (z. B. eine sich ausbreitende transiente elektrische oder elektromagnetische Übertragung) ausschließt, aber nichtflüchtige Datenspeicherungsschaltungen (z. B. Puffer, Cache und Warteschlangen) innerhalb der Transceiver von transitorischen Signalen beinhaltet. In einer Ausführungsform ist Code (z. B. ausführbarer Code oder Quellcode) auf einem oder mehreren nichtflüchtigen computerlesbaren Speichermedien gespeichert, die ausführbare Anweisungen aufweisen, die, wenn sie von einem oder mehreren Prozessoren eines Computersystems ausgeführt werden (d. h. als Ergebnis der Ausführung), das Computersystem veranlassen, die hierin beschriebenen Operationen durchzuführen. Der Satz von nichtflüchtigen computerlesbaren Speichermedien umfasst in einer ausführungsform mehrere nichtflüchtige computerlesbare Speichermedien und eines oder mehrere einzelne nichtflüchtige Speichermedien der mehreren nichtflüchtigen computerlesbaren Speichermedien verfügt unter Umständen nicht über den gesamten Code, während insgesamt der gesamte Code auf den mehreren nichtflüchtigen computerlesbaren Speichermedien gespeichert ist. In einer Ausführungsform werden die ausführbaren Anweisungen so ausgeführt, dass verschiedene Anweisungen von verschiedenen Prozessoren ausgeführt werden - zum Beispiel speichert in einer Ausführungsform ein nichtflüchtiges computerlesbares Speichermedium Anweisungen und eine Haupt-CPU führt einige der Anweisungen aus, während eine Grafikprozessoreinheit andere Anweisungen ausführt. In einer weiteren Ausführungsform weisen verschiedene Komponenten eines Rechensystems getrennte Prozessoren auf und verschiedene Prozessoren führen verschiedene Teilmengen der Anweisungen aus.
  • Dementsprechend sind gemäß der Ausführungsform Computersysteme so konfiguriert, dass sie einen oder mehrere Dienste implementieren, die einzeln oder gemeinsam Operationen der hierin beschriebenen Prozesse verarbeiten, und solche Computersysteme sind mit entsprechender Hardware und/oder Software konfiguriert, die die Durchführung der Operationen ermöglichen. Ferner handelt es sich bei einem Computersystem in einer Ausführungsform der vorliegenden Offenbarung um ein einzelnes Gerät und in einer weiteren Ausführungsform um ein verteiltes Computersystem, das mehrere unterschiedlich arbeitende Vorrichtungen umfasst, so dass das verteilte Computersystem die hierin beschriebenen Operationen durchführt und eine einzelne Vorrichtung nicht alle Operationen durchführt.
  • Die Verwendung jeglicher Beispiele oder beispielhafter Wortwahl (z. B. „wie etwa "), die hier bereitgestellt sind, soll lediglich die Ausführungsformen der Erfindung besser veranschaulichen und stellt keine Einschränkung des Umfangs der Erfindung dar, es sei denn, es ist etwas anderes beansprucht. Keinerlei Formulierung in der Beschreibung sollte so ausgelegt werden, dass sie ein beliebiges nichtbeanspruchtes Element als für die Implementierung der Erfindung wesentlich angibt.
  • Hier sind Ausführungsformen dieser Offenbarung einschließlich der besten den Erfindern bekannten Art und Weise zum Ausführen der Erfindung beschrieben. Der Fachmann kann bei der Lektüre der vorstehenden Beschreibung Variationen dieser beschriebenen Ausführungsformen erkennen. Die Erfinder gehen davon aus, dass der Fachmann derlei Variationen im geeigneten Fall anwendet, und die Erfinder sehen vor, dass die Ausführungsformen der vorliegenden Offenbarung anders als hier konkret beschrieben implementiert werden können. Dementsprechend beinhaltet der Umfang der vorliegenden Offenbarung alle Modifikationen und Äquivalente des in den beigefügten Patentansprüchen dargelegten Gegenstands, wie es durch das jeweils geltende Recht zulässig ist. Darüber hinaus ist jede beliebige Kombination der vorstehend beschriebenen Elemente in allen möglichen Variationen davon durch den Umfang der vorliegenden Offenbarung abgedeckt, sofern es hier nicht anders angegeben ist oder der Kontext dem anderweitig eindeutig widerspricht.
  • Mindestens eine Ausführungsform der Offenbarung kann im Hinblick auf die folgenden Klauseln beschrieben werden:
    • Klausel 1. Computerimplementiertes Verfahren, umfassend:
      • Erhalten von ersten Daten von einem Peer-Rechensystem, die einen Satz von Zertifikaten anzeigen, denen das Peer-Rechensystem vertraut;
      • Aktualisieren, basierend auf den ersten Daten, zweiter Daten, die Zertifikate verfolgen, denen eine Vielzahl von Peer-Rechensystemen vertraut, die das Peer-Rechensystem beinhalten;
      • Erzeugen, basierend auf den zweiten Daten, einer Bestimmung, dass eine Reihe von Bedingungen für das Aktualisieren einer Vielzahl von Zertifikaten erfüllt ist;
      • als Ergebnis des Bestimmens, Aktualisieren der Vielzahl von Zertifikaten, um zu einer aktualisierten Vielzahl von Zertifikaten zu gelangen, durch:
        • Hinzufügen eines ersten Zertifikats zu der Vielzahl von Zertifikaten;
        • Entfernen eines zweiten Zertifikats aus der Vielzahl von Zertifikaten; und
        • Verändern eines Status von mindestens einem dritten Zertifikat, damit das mindestens eine dritte Zertifikat von der Vielzahl der Peer-Rechensysteme verwendet werden kann, um Peer-Zertifikate zu verifizieren, die zur Authentifizierung für die Peer-to-Peer-Kommunikation verwendet werden; und
      • Kommunizieren von dritten Daten, die Zertifikate in der aktualisierten Vielzahl von Zertifikaten anzeigen, an mindestens eines der Vielzahl von Peer-Rechensystemen.
    • Klausel 2. Verfahren nach Klausel 1, wobei das Erzeugen der Bestimmung, dass der Satz von Bedingungen zum Aktualisieren mehrerer Zertifikate erfüllt ist, Folgendes umfasst:
      • Bestimmen, dass eine bestimmte Anzahl von Peer-Rechensystemen die Nutzung des zweiten Zertifikats eingestellt hat.
    • Klausel 3. Verfahren nach Klausel 1 oder 2, ferner umfassend:
      • Verändern eines Status eines vierten Zertifikats der Vielzahl von Zertifikaten auf veraltet, wobei das erste Zertifikat, das dritte Zertifikat und das vierte Zertifikat von der Vielzahl von Peers betrieben werden können, um mindestens einen sicheren Kommunikationskanal zwischen einzelnen Peers der Vielzahl von Peers zu bilden.
    • Klausel 4. Verfahren nach einer der Klauseln 1-3, wobei das Hinzufügen des ersten Zertifikats zu der Vielzahl von Zertifikaten das Versehen des ersten Zertifikats mit einem Status umfasst, der dazu führt, dass verhindert wird, dass das erste Zertifikat zur Ausstellung eines Zertifikats verwendet wird, der jedoch eine Änderung des Status ermöglicht, damit das erste Zertifikat weitere Zertifikate ausstellen kann.
    • Klausel 5. System, umfassend:
      • mindestens einen Prozessor;
      • Speicher, der computerausführbare Anweisungen speichert, die als Ergebnis der Ausführung durch den einen oder die mehreren Prozessoren das System zu Folgendem veranlassen:
        • Erzeugen einer Bestimmung, dass eine Gruppe von Peers eine Reihe von Bedingungen erfüllt, wobei die Gruppe von Peers individuell mindestens einem öffentlichen Schlüssel aus einer Vielzahl von öffentlichen Schlüsseln vertraut;
        • als Ergebnis der Bestimmung, die anzeigt, dass die Menge der Bedingungen erfüllt ist:
          • Aktualisieren der Vielzahl von öffentlichen Schlüsseln durch Entfernen von mindestens einem öffentlichen Schlüssel aus der Vielzahl von öffentlichen Schlüsseln;
          • Anzeigen der aktualisierten Vielzahl von öffentlichen Schlüsseln an mindestens einen der Peers.
    • Klausel 6. System nach Klausel 5, wobei die computerausführbaren Anweisungen, die das System veranlassen, die Bestimmung zu erzeugen, dass der Satz von Peers den Satz von Bedingungen erfüllt, ferner Anweisungen umfassen, die das System ferner zu Folgendem veranlassen:
      • Erzeugen der Bestimmung, dass der Satz von Peers den Satz von Bedingungen erfüllt, durch Bestimmen, dass weniger als eine Schwellenanzahl von einzelnen Peers der Vielzahl von Peers den mindestens einen öffentlichen Schlüssel verwenden, um Zertifikate bei der Kommunikation mit anderen Peers der Vielzahl von Peers zu erzeugen, oder Bestimmen, dass ein Notfall eingetreten ist.
    • Klausel 7. System nach Klausel 6, wobei die Bestimmung, dass weniger als die Schwellenanzahl der einzelnen Peers der Vielzahl von Peers den mindestens einen öffentlichen Schlüssel zum Erzeugen von Zertifikaten verwenden, auf einer Anzeige basiert, die von mindestens einer Teilmenge der Vielzahl von Peers erhalten wird, welche Zertifikate von mindestens der Teilmenge der Vielzahl von Peers verwendet werden.
    • Klausel 8. System nach Klausel 6 oder 7, wobei die Schwellenanzahl einzelner Peers eine Gesamtzahl der Vielzahl von Peers umfasst.
    • Klausel 9. System nach einer der Klauseln 5-8, wobei die computerausführbaren Anweisungen, die als Ergebnis der Bestimmung, die bestimmt, dass die Menge der Bedingungen erfüllt ist, ferner das System dazu veranlassen, die Vielzahl der öffentlichen Schlüssel zu aktualisieren, indem mindestens ein öffentlicher Schlüssel zu der Vielzahl der öffentlichen Schlüssel hinzugefügt wird.
    • Klausel 10. System nach Klausel 9, wobei die computerausführbaren Anweisungen, die als Ergebnis der Bestimmung, die bestimmt, dass der Satz von Bedingungen erfüllt ist, ferner das System veranlassen, die Vielzahl von öffentlichen Schlüsseln periodisch zu aktualisieren, indem mindestens ein zweiter öffentlicher Schlüssel zu der Vielzahl von öffentlichen Schlüsseln hinzugefügt wird, wobei der mindestens eine zweite öffentliche Schlüssel einen temporären Status hat, der es ermöglicht, den Status zu ändern, um es dem mindestens einen zweiten öffentlichen Schlüssel zu ermöglichen, andere Zertifikate zu erzeugen.
    • Klausel11. System nach einer der Klauseln 5-10, wobei die computerausführbaren Anweisungen ferner Anweisungen umfassen, die als Ergebnis der Ausführung einer Anweisung durch den einen oder die mehreren Prozessoren das System ferner zu Folgendem veranlassen:
      • als Reaktion auf den Erhalt einer Anfrage von einem einzelnen Peer aus der Vielzahl von Peers, die aktualisierte Vielzahl von vertrauenswürdigen öffentlichen Schlüsseln zu aktualisieren, Senden einer Anzeige einer modifizierten Vielzahl von öffentlichen Schlüsseln an den einzelnen Peer.
    • Klausel 12. System nach einer der Klauseln 5-11, wobei die computerausführbaren Anweisungen ferner Anweisungen umfassen, die als Ergebnis der Ausführung einer Anweisung durch den einen oder die mehreren Prozessoren das System ferner zu Folgendem veranlassen:
      • Erhalten einer Anfrage zur Deaktivierung eines ersten öffentlichen Schlüssels aus der Vielzahl der vertrauenswürdigen Schlüssel von einer autorisierten Quelle;
      • als Reaktion auf den Erhalt der Anfrage zur Deaktivierung des ersten öffentlichen Schlüssels der Vielzahl von vertrauenswürdigen Schlüsseln von der autorisierten Quelle, Verändern eines Zustands des ersten öffentlichen Schlüssels von einem inaktiven Zustand in einen deaktivierten Zustand.
    • Klausel 13. Nichtflüchtiges computerlesbares Speichermedium, das ausführbare Anweisungen speichert, die infolge ihrer Ausführung durch einen oder mehrere Prozessoren eines Computersystems das Computersystem wenigstens zu Folgendem veranlassen:
      • Bestimmen, dass eine Schwellenanzahl einer Menge von Peers, die individuell mindestens einem öffentlichen Schlüssel aus einer Vielzahl von öffentlichen Schlüsseln vertrauen, einen ersten öffentlichen Schlüssel aus der Vielzahl von öffentlichen Schlüsseln nicht mehr verwendet, um Zertifikate zu erzeugen;
      • als Ergebnis der Bestimmung, dass die Schwellenanzahl der Menge der Peers den ersten öffentlichen Schlüssel nicht mehr verwendet:
        • Aktualisieren der Vielzahl von öffentlichen Schlüsseln, indem mindestens der erste öffentliche Schlüssel aus der Vielzahl von öffentlichen Schlüsseln entfernt wird;
        • Anzeigen der aktualisierten Vielzahl von öffentlichen Schlüsseln an mindestens einen der Peers.
    • Klausel 14. Nichtflüchtiges, computerlesbares Speichermedium nach Klausel 13, wobei einzelne Peers aus der Menge der Peers mindestens einen öffentlichen Schlüssel aus der Vielzahl der öffentlichen Schlüssel verwenden, um ein Zertifikat zu erzeugen, wobei das Zertifikat verwendbar ist, bis ein entsprechender öffentlicher Schlüssel aus der Vielzahl der öffentlichen Schlüssel aus der Vielzahl der öffentlichen Schlüssel oder der aktualisierten Vielzahl der Schlüssel entfernt wird.
    • Klausel 15. Nichtflüchtiges computerlesbares Speichermedium nach Klausel 13 oder 14, wobei die Anweisungen ferner Anweisungen umfassen, die infolge ihrer Ausführung durch den einen oder die mehreren Prozessoren das Computersystem zu Folgendem veranlassen:
      • als Ergebnis der Bestimmung, dass die Schwellenanzahl der Menge der Peers den ersten öffentlichen Schlüssel nicht mehr verwendet, Aktualisieren der Vielzahl der öffentlichen Schlüssel durch Hinzufügen von mindestens einem öffentlichen Schlüssel zu der Vielzahl der öffentlichen Schlüssel.
    • Klausel 16. Nichtflüchtiges computerlesbares Speichermedium nach einer der Klauseln 13-15, wobei die Anweisungen ferner Anweisungen umfassen, die infolge ihrer Ausführung durch den einen oder die mehreren Prozessoren das Computersystem zu Folgendem veranlassen:
      • periodisches Aktualisieren der Vielzahl von öffentlichen Schlüsseln durch Hinzufügen von mindestens einem öffentlichen Schlüssel zu der Vielzahl von öffentlichen Schlüsseln, wobei der mindestens eine öffentliche Schlüssel bei Auftreten eines auslösenden Ereignisses Zertifikate erzeugen darf.
    • Klausel 17. Nichtflüchtiges computerlesbares Speichermedium nach einer der Klauseln 13-16, wobei die Anweisungen ferner Anweisungen umfassen, die infolge ihrer Ausführung durch den einen oder die mehreren Prozessoren das Computersystem zu Folgendem veranlassen:
      • periodisches Aktualisieren der Vielzahl von öffentlichen Schlüsseln durch mindestens die Veränderung des Status von mindestens einem öffentlichen Schlüssel der Vielzahl von öffentlichen Schlüsseln auf veraltet, wobei dem mindestens einen öffentlichen Schlüssel mit dem Status veraltet von der Gruppe von Peers vertraut wird, aber verhindert wird, neue Zertifikate zu erzeugen.
    • Klausel 18. Nichtflüchtiges computerlesbares Speichermedium nach einer der Klauseln 13-17, wobei die Anweisungen ferner Anweisungen umfassen, die infolge ihrer Ausführung durch den einen oder die mehreren Prozessoren das Computersystem zu Folgendem veranlassen:
      • als Reaktion auf das Bestimmen, dass ein Zertifikat, das einem öffentlichen Schlüssel der Vielzahl öffentlicher Schlüssel entspricht, von mindestens einem Peer der Vielzahl von Peers während eines Zeitraums nicht verwendet wurde, Auslösen einer zu sendenden Benachrichtigung, ohne den öffentlichen Schlüssel aus der aktualisierten Vielzahl öffentlicher Schlüssel zu entfernen.
    • Klausel 19. Nichtflüchtiges, computerlesbares Speichermedium nach einer der Klauseln 13-18, wobei das Bestimmen, dass die Schwellenanzahl der Gruppe von Peers nicht mehr den ersten öffentlichen Schlüssel zum Erzeugen von Zertifikaten verwendet, auf dem Erhalten einer Anzeige von mindestens einer Teilmenge von Peers der Gruppe von Peers basiert, die öffentliche Schlüssel der Vielzahl von öffentlichen Schlüsseln anzeigt, die von mindestens der Teilmenge von Peers verwendet werden.
    • Klausel 20. Nichtflüchtiges computerlesbares Speichermedium nach einer der Klauseln 13-19, wobei die computerausführbaren Anweisungen ferner Anweisungen umfassen, die als Ergebnis der Ausführung einer Anweisung durch den einen oder die mehreren Prozessoren das System zu Folgendem veranlassen:
      • als Reaktion auf den Erhalt einer Anfrage zur Deaktivierung des ersten öffentlichen Schlüssels der Vielzahl von öffentlichen Schlüsseln, Deaktivieren des ersten öffentlichen Schlüssels, wobei nach dem Deaktivieren des ersten öffentlichen Schlüssels die Vielzahl von öffentlichen Schlüsseln mindestens einen zweiten öffentlichen Schlüssel mit dem Status „ausstehend ,,, mindestens einen dritten öffentlichen Schlüssel mit dem Status „ausgestellt" und mindestens einen vierten öffentlichen Schlüssel mit dem Status „veraltet” umfasst.
  • Jegliche Referenzen, einschließlich Veröffentlichungen, Patentanmeldungen und Patenten, die hierin erwähnt werden, sind hiermit durch Bezugnahme in demselben Maße aufgenommen, als wäre jede Referenz einzeln und spezifisch als durch Referenz eingeschlossen angegeben und in ihrer Gesamtheit hierin ausgeführt.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 17362899 [0001]

Claims (15)

  1. Computerimplementiertes Verfahren, umfassend: Erhalten von ersten Daten von einem Peer-Rechensystem, die einen Satz von Zertifikaten anzeigen, denen das Peer-Rechensystem vertraut; Aktualisieren, basierend auf den ersten Daten, zweiter Daten, die Zertifikate verfolgen, denen eine Vielzahl von Peer-Rechensystemen vertraut, die das Peer-Rechensystem beinhalten; Erzeugen, basierend auf den zweiten Daten, einer Bestimmung, dass eine Reihe von Bedingungen für die Aktualisierung einer Vielzahl von Zertifikaten erfüllt ist; als Ergebnis des Bestimmens, Aktualisieren der Vielzahl von Zertifikaten, um zu einer aktualisierten Vielzahl von Zertifikaten zu gelangen, durch: Hinzufügen eines ersten Zertifikats zur Vielzahl von Zertifikaten; Entfernen eines zweiten Zertifikats aus der Vielzahl von Zertifikaten; und Verändern eines Status von mindestens einem dritten Zertifikat, damit das mindestens eine dritte Zertifikat von der Vielzahl der Peer-Rechensysteme verwendet werden kann, um Peer-Zertifikate zu verifizieren, die zur Authentifizierung für die Peer-to-Peer-Kommunikation verwendet werden; und Kommunizieren von dritten Daten, die Zertifikate in der aktualisierten Vielzahl von Zertifikaten anzeigen, an mindestens eines der Vielzahl von Peer-Rechensystemen.
  2. Verfahren nach Anspruch 1, wobei das Erzeugen der Bestimmung, dass der Satz von Bedingungen zum Aktualisieren mehrerer Zertifikate erfüllt ist, Folgendes umfasst: Bestimmen, dass eine bestimmte Anzahl von Peer-Rechensystemen die Nutzung des zweiten Zertifikats eingestellt hat.
  3. Verfahren nach Anspruch 1, ferner umfassend: Verändern eines Status eines vierten Zertifikats der Vielzahl von Zertifikaten auf veraltet, wobei das erste Zertifikat, das dritte Zertifikat und das vierte Zertifikat von der Vielzahl von Peers betrieben werden können, um mindestens einen sicheren Kommunikationskanal zwischen einzelnen Peers der Vielzahl von Peers zu bilden.
  4. Verfahren nach Anspruch 1, wobei das Hinzufügen des ersten Zertifikats zu der Vielzahl von Zertifikaten das Versehen des ersten Zertifikats mit einem Status umfasst, der dazu führt, dass verhindert wird, dass das erste Zertifikat zur Ausstellung eines Zertifikats verwendet wird, der jedoch eine Änderung des Status ermöglicht, damit das erste Zertifikat weitere Zertifikate ausstellen kann.
  5. System, umfassend: mindestens einen Prozessor; Speicher, der computerausführbare Anweisungen speichert, die als Ergebnis der Ausführung durch den einen oder die mehreren Prozessoren das System zu Folgendem veranlassen: Erzeugen einer Bestimmung, dass eine Gruppe von Peers eine Reihe von Bedingungen erfüllt, wobei die Gruppe von Peers individuell mindestens einem öffentlichen Schlüssel aus einer Vielzahl von öffentlichen Schlüsseln vertraut; als Ergebnis der Bestimmung, die anzeigt, dass die Menge der Bedingungen erfüllt ist: Aktualisieren der Vielzahl von öffentlichen Schlüsseln durch Entfernen von mindestens einem öffentlichen Schlüssel aus der Vielzahl von öffentlichen Schlüsseln; Anzeigen der aktualisierten Vielzahl von öffentlichen Schlüsseln an mindestens einen der Peers.
  6. System nach Anspruch 5, wobei die computerausführbaren Anweisungen, die das System veranlassen, die Bestimmung zu erzeugen, dass der Satz von Peers den Satz von Bedingungen erfüllt, ferner Anweisungen umfassen, die das System ferner zu Folgendem veranlassen: Erzeugen der Bestimmung, dass der Satz von Peers den Satz von Bedingungen erfüllt, durch Bestimmen, dass weniger als eine Schwellenanzahl von einzelnen Peers der Vielzahl von Peers den mindestens einen öffentlichen Schlüssel verwenden, um Zertifikate bei der Kommunikation mit anderen Peers der Vielzahl von Peers zu erzeugen, oder Bestimmen, dass ein Notfall eingetreten ist.
  7. System nach Anspruch 6, wobei die Bestimmung, dass weniger als die Schwellenanzahl der einzelnen Peers der Vielzahl von Peers den mindestens einen öffentlichen Schlüssel zum Erzeugen von Zertifikaten verwenden, auf einer Anzeige basiert, die von mindestens einer Teilmenge der Vielzahl von Peers erhalten wird, welche Zertifikate von mindestens der Teilmenge der Vielzahl von Peers verwendet werden.
  8. System nach Anspruch 5, wobei die computerausführbaren Anweisungen, die als Ergebnis der Bestimmung, die bestimmt, dass die Menge der Bedingungen erfüllt ist, ferner das System dazu veranlassen, die Vielzahl der öffentlichen Schlüssel zu aktualisieren, indem mindestens ein öffentlicher Schlüssel zu der Vielzahl der öffentlichen Schlüssel hinzugefügt wird.
  9. System nach Anspruch 8, wobei die computerausführbaren Anweisungen, die als Ergebnis der Bestimmung, die bestimmt, dass der Satz von Bedingungen erfüllt ist, ferner das System veranlassen, die Vielzahl von öffentlichen Schlüsseln periodisch zu aktualisieren, indem mindestens ein zweiter öffentlicher Schlüssel zu der Vielzahl von öffentlichen Schlüsseln hinzugefügt wird, wobei der mindestens eine zweite öffentliche Schlüssel einen temporären Status hat, der es ermöglicht, den Status zu ändern, um es dem mindestens einen zweiten öffentlichen Schlüssel zu ermöglichen, andere Zertifikate zu erzeugen.
  10. System nach Anspruch 5, wobei die computerausführbaren Anweisungen ferner Anweisungen umfassen, die als Ergebnis der Ausführung einer Anweisung durch den einen oder die mehreren Prozessoren das System ferner zu Folgendem veranlassen: als Reaktion auf den Erhalt einer Anfrage von einem einzelnen Peer aus der Vielzahl von Peers, die aktualisierte Vielzahl von vertrauenswürdigen öffentlichen Schlüsseln zu aktualisieren, Senden einer Anzeige einer modifizierten Vielzahl von öffentlichen Schlüsseln an den einzelnen Peer.
  11. System, umfassend: mindestens einen Prozessor; Speicher, der computerausführbare Anweisungen speichert, die als Ergebnis der Ausführung durch den einen oder die mehreren Prozessoren das System zu Folgendem veranlassen: Bestimmen, dass eine Schwellenanzahl einer Menge von Peers, die individuell mindestens einem öffentlichen Schlüssel aus einer Vielzahl von öffentlichen Schlüsseln vertrauen, einen ersten öffentlichen Schlüssel aus der Vielzahl von öffentlichen Schlüsseln nicht mehr verwendet, um Zertifikate zu erzeugen; als Ergebnis der Bestimmung, dass die Schwellenanzahl der Menge der Peers den ersten öffentlichen Schlüssel nicht mehr verwendet: Aktualisieren der Vielzahl von öffentlichen Schlüsseln, indem mindestens der erste öffentliche Schlüssel aus der Vielzahl von öffentlichen Schlüsseln entfernt wird; Anzeigen der aktualisierten Vielzahl von öffentlichen Schlüsseln an mindestens einen der Peers.
  12. System nach Anspruch 11, wobei einzelne Peers aus der Menge der Peers mindestens einen öffentlichen Schlüssel aus der Vielzahl der öffentlichen Schlüssel verwenden, um ein Zertifikat zu erzeugen, wobei das Zertifikat verwendbar ist, bis ein entsprechender öffentlicher Schlüssel aus der Vielzahl der öffentlichen Schlüssel aus der Vielzahl der öffentlichen Schlüssel oder der aktualisierten Vielzahl der Schlüssel entfernt wird.
  13. System nach Anspruch 11, wobei die computerausführbaren Anweisungen ferner Anweisungen umfassen, die als Ergebnis der Ausführung einer Anweisung durch den einen oder die mehreren Prozessoren das System ferner zu Folgendem veranlassen: als Ergebnis der Bestimmung, dass die Schwellenanzahl der Menge der Peers den ersten öffentlichen Schlüssel nicht mehr verwendet, Aktualisieren der Vielzahl der öffentlichen Schlüssel durch Hinzufügen von mindestens einem öffentlichen Schlüssel zu der Vielzahl der öffentlichen Schlüssel.
  14. System nach Anspruch 11, wobei die computerausführbaren Anweisungen ferner Anweisungen umfassen, die als Ergebnis der Ausführung einer Anweisung durch den einen oder die mehreren Prozessoren das System ferner zu Folgendem veranlassen: periodisches Aktualisieren der Vielzahl von öffentlichen Schlüsseln durch Hinzufügen von mindestens einem öffentlichen Schlüssel zu der Vielzahl von öffentlichen Schlüsseln, wobei der mindestens eine öffentliche Schlüssel bei Auftreten eines auslösenden Ereignisses Zertifikate erzeugen darf.
  15. System nach Anspruch 11, wobei die computerausführbaren Anweisungen ferner Anweisungen umfassen, die als Ergebnis der Ausführung einer Anweisung durch den einen oder die mehreren Prozessoren das System ferner zu Folgendem veranlassen: als Reaktion auf das Bestimmen, dass ein Zertifikat, das einem öffentlichen Schlüssel der Vielzahl öffentlicher Schlüssel entspricht, von mindestens einem Peer der Vielzahl von Peers während eines Zeitraums nicht verwendet wurde, Auslösen einer zu sendenden Benachrichtigung, ohne den öffentlichen Schlüssel aus der aktualisierten Vielzahl öffentlicher Schlüssel zu entfernen.
DE112022000280.8T 2021-06-29 2022-06-10 Identitätsautorität Pending DE112022000280T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US17/362,899 2021-06-29
US17/362,899 US20220417036A1 (en) 2021-06-29 2021-06-29 Identity authority
PCT/US2022/033074 WO2023278128A1 (en) 2021-06-29 2022-06-10 Identity authority

Publications (1)

Publication Number Publication Date
DE112022000280T5 true DE112022000280T5 (de) 2023-11-02

Family

ID=82403846

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112022000280.8T Pending DE112022000280T5 (de) 2021-06-29 2022-06-10 Identitätsautorität

Country Status (5)

Country Link
US (1) US20220417036A1 (de)
CN (1) CN116636181A (de)
DE (1) DE112022000280T5 (de)
GB (1) GB2616813A (de)
WO (1) WO2023278128A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220393883A1 (en) * 2021-06-03 2022-12-08 Unisys Corporation Machine-to machine authentication through trusted chain of ownership
US20230078179A1 (en) * 2021-09-10 2023-03-16 Arista Networks, Inc. High frequency rotation of cryptographic data

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE602005002652T2 (de) * 2005-08-05 2008-07-10 Sap Ag System und Verfahren für das Erneuern von Schlüsseln, welche in Public-Key Kryptographie genutzt werden
US10771261B1 (en) * 2016-09-29 2020-09-08 EMC IP Holding Company LLC Extensible unified multi-service certificate and certificate revocation list management
US11100232B1 (en) * 2017-02-23 2021-08-24 Ivanti, Inc. Systems and methods to automate networked device security response priority by user role detection
US11563567B2 (en) * 2017-09-27 2023-01-24 Visa International Service Association Secure shared key establishment for peer to peer communications
US11206142B2 (en) * 2018-08-17 2021-12-21 Cable Television Laboratories, Inc. Systems and methods for automated certificate renewal management
JP7174237B2 (ja) * 2018-11-29 2022-11-17 富士通株式会社 鍵生成装置、鍵更新方法および鍵更新プログラム

Also Published As

Publication number Publication date
WO2023278128A1 (en) 2023-01-05
CN116636181A (zh) 2023-08-22
GB2616813A (en) 2023-09-20
US20220417036A1 (en) 2022-12-29

Similar Documents

Publication Publication Date Title
DE112015004699B4 (de) Über mehrere Sites verteiltes Sicherheitssystem
DE112022000280T5 (de) Identitätsautorität
DE102014113582B4 (de) Vorrichtung, Verfahren und System für die kontextbewusste Sicherheitssteuerung in einer Cloud-Umgebung
DE112017002827T5 (de) Verfahren, server und kommunikationsvorrichtung zur aktualisierung identitätsbasierter kryptographischer privater schlüssel von beeinträchtigten kommunikationsvorrichtungen
DE112018000779T5 (de) Tokenbereitstellung für Daten
DE112017007393T5 (de) System und verfahren für netzwerkvorrichtungssicherheits- und vertrauenswertbestimmung
DE102011013469A1 (de) Trusted group einer mehrzahl von einrichtungen mit einer sicheren authentisierung mit single sign-on
DE102011077218B4 (de) Zugriff auf in einer Cloud gespeicherte Daten
DE112019001441T5 (de) Vergessliche pseudozufallsfunktion in einem schlüsselverwaltungssystem
DE112016002392T5 (de) Autorisierung in einem verteilten System unter Verwendung von Zugriffssteuerungslisten und Gruppen
DE112021000224T5 (de) Verschlüsselung von message queues
DE102016115193A1 (de) Verfahren zur sicheren Datenhaltung in einem Computernetzwerk
US20150156193A1 (en) Creating and managing certificates in a role-based certificate store
DE102014107793B9 (de) Verfahren zur Weiterleitung von Daten zwischen Computersystemen, Computernetz-Infrastruktur sowie Computerprogramm-Produkt
DE10146361B4 (de) Verteiltes System
DE102011077513A1 (de) Verfahren zur sicheren Verarbeitung von Daten
US10951605B2 (en) Centrally managing data for distributed identity-based firewalling
DE112021005837T5 (de) Dezentrale sendeverschlüsselung und schlüsselerzeugungseinrichtung
EP3152660A1 (de) Verfahren zur verteilung von tasks zwischen computersystemen, computernetz-infrastruktur sowie computerprogramm-produkt
DE202023103214U1 (de) Web-Anwendung als Datenbankobjekt erster Klasse
DE112012000780T5 (de) Verarbeiten von Berechtigungsprüfungsdaten
DE112021005026T5 (de) Persistente quellwerte für angenommene alternative identitäten
DE112022000963T5 (de) Verbindungsbeständige mehrfaktorauthentifizierung
DE102020113257A1 (de) Policy management system zur bereitstellung von autorisierungsinformationen über den distributed data store
LU500837B1 (de) Verfahren und zugehörige Computersysteme zur Sicherung der Integrität von Daten

Legal Events

Date Code Title Description
R012 Request for examination validly filed