DE112021003656T5 - Rollendelegierung bei attestierungsverifizierern - Google Patents

Rollendelegierung bei attestierungsverifizierern Download PDF

Info

Publication number
DE112021003656T5
DE112021003656T5 DE112021003656.4T DE112021003656T DE112021003656T5 DE 112021003656 T5 DE112021003656 T5 DE 112021003656T5 DE 112021003656 T DE112021003656 T DE 112021003656T DE 112021003656 T5 DE112021003656 T5 DE 112021003656T5
Authority
DE
Germany
Prior art keywords
attestation
entity
verification
delegation
computing device
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
DE112021003656.4T
Other languages
English (en)
Inventor
Ned M. Smith
Junyuan Wang
Kaijie Guo
Zijuan FAN
Weigang Li
Lihui Zhang
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.)
Intel Corp
Original Assignee
Intel Corp
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 Intel Corp filed Critical Intel Corp
Publication of DE112021003656T5 publication Critical patent/DE112021003656T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Es sind verschiedene Beispiele für Vorrichtungs- und Systemimplementierungen und Verfahren zum Durchführen von Attestierungsdelegierungsoperationen offenbart. In einem Beispiel werden Attestierungsdelegierungsoperationen von einem Verifizierer durchgeführt, einschließlich: Erhalten von Endorsement-Informationen zur Attestierung einer Entität; Erhalten einer Bewertungsrichtlinie zur Bewertung eines Attestierungsbeweises für die Attestierung der Entität; Bestimmen, basierend auf den Endorsement-Informationen und der Bewertungsrichtlinie, dass es einer Verifizierungsdelegierer-Entität gestattet ist, die Attestierung der Entität durchzuführen; und Bereitstellen, für die Verifizierungsdelegierer-Entität, eines Delegierungsbefehls zum Durchführen der Attestierung der Entität, wobei der Delegierungsbefehl die Verifizierungsdelegierer-Entität autorisiert, Attestierungsoperationen (z. B. Verifiziereroperationen) für eine Domäne von Entitäten einschließlich der Entität durchzuführen.

Description

  • PRIORITÄTSANSPRUCH
  • Diese Anmeldung beansprucht die Priorität: der vorläufigen US-Patentanmeldung Nr. 63/049.442 , eingereicht am 8. Juli 2020, und der vorläufige US-Patentanmeldung Nr. 63/050.988 , eingereicht am 13. Juli 2020, die beide hiermit in ihrer Gesamtheit durch Bezugnahme aufgenommen werden.
  • TECHNISCHES GEBIET
  • Hierin beschriebene Ausführungsformen betreffen allgemein Datenverarbeitungs-, Sicherheits- und Attestierungstechniken und Rechenhardwarekonfigurationen, um solche Techniken zu implementieren.
  • HINTERGRUND
  • Edge-Computing bezeichnet auf allgemeiner Ebene den Übergang von Rechen- und Speicherressourcen näher an Endpunktvorrichtungen (z. B. Konsumentenrechenvorrichtungen, Benutzergeräte usw.), um die Gesamtbetriebskosten zu optimieren, eine Anwendungslatenz zu reduzieren, Dienstfunktionalitäten zu verbessern und eine Einhaltung von Sicherheits- oder Datenschutzanforderungen zu verbessern. Edge-Computing kann in einigen Szenarien einen Cloud-ähnlichen verteilten Dienst bereitstellen, der Orchestrierung und Verwaltung von Anwendungen unter vielen Arten von Speicherungs- und Rechenressourcen bietet. Als Ergebnis wurden einige Implementierungen von Edge-Computing als die „Edge-Cloud“ oder der „Fog“ bezeichnet, wenn leistungsstarke Rechenressourcen, die vorher nur in großen entfernten Rechenzentren verfügbar waren, näher an Endpunkte bewegt werden und Endverbrauchern am „Rand“ des Netzwerks zur Verwendung zur Verfügung gestellt werden.
  • Anwendungsfälle von Edge-Computing in mobilen Netzwerkumgebungen wurden zur Integration mit Ansätzen für das Mehrfachzugriff-Edge-Computing (Multi-Access Edge Computing, MEC) entwickelt, die auch als „mobiles Edge-Computing“ bekannt sind. MEC-Ansätze sind entwickelt, um Anwendungsentwicklern und Inhaltsanbietern zu ermöglichen, auf Rechenfähigkeiten und eine Informatik- bzw. IT-Dienstumgebung in dynamischen mobilen Netzwerkumgebungen am Rand des Netzwerks zuzugreifen. Begrenzte Standards wurden von der Industry Specification Group (ISG) des European Telecommunications Standards Institute (ETSI) entwickelt, um gemeinsame Schnittstellen für den Betrieb von MEC-Systemen, Plattformen, Hosts, Diensten und Anwendungen zu definieren.
  • Edge-Computing, MEC und verwandte Technologien versuchen, reduzierte Latenz, erhöhte Ansprechempfindlichkeit und mehr verfügbare Rechenleistung bereitzustellen, als sie in herkömmlichen Cloud-Netzwerkdiensten und Weitverkehrsnetzwerkverbindungen angeboten werden. Die Integration von Mobilität und dynamisch gestarteten Diensten für eine mobile Verwendung und Vorrichtungsverarbeitungs-Anwendungsfälle hat jedoch zu Einschränkungen und Bedenken bei Orchestrierung, Funktionskoordinierung und Ressourcenverwaltung geführt, insbesondere in komplexen Mobilitätsszenarien, in die viele Teilnehmer (Vorrichtungen, Hosts, Mandanten, Dienstanbieter, Betreiber) einbezogen sind.
  • Auf ähnliche Weise sind Netzwerke und Vorrichtungen des Internets der Dinge (Internet of Things, IoT) konstruiert, eine verteilte Rechenanordnung von einer Vielfalt von Endpunkten zu bieten. IoT-Vorrichtungen sind physische oder virtualisierte Objekte, die in einem Netzwerk kommunizieren können, und können Sensoren, Stellglieder und andere Eingabe/Ausgabe-Komponenten enthalten, die verwendet werden können, um Daten zu sammeln oder Handlungen in einer realen Umgebung durchzuführen. IoT-Einrichtungen können zum Beispiel Endpunktvorrichtungen mit geringem Leistungsverbrauch umfassen, die in alltägliche Dinge, wie Gebäude, Fahrzeuge, Pakete usw. eingebettet oder daran angebracht sind, um eine zusätzliche Ebene der künstlichen sensorischen Wahrnehmung dieser Dinge bereitzustellen. In jüngster Zeit wurden IoT-Vorrichtungen immer beliebter, und deshalb haben sich Anwendungen, die diese Vorrichtungen verwenden, stark vermehrt.
  • Der Einsatz verschiedener Edge-, Fog-, MEC- und IoT-Netzwerke, - Einrichtungen und -Dienste hat eine Anzahl fortgeschrittener Verwendungsfälle und -szenarien eingeführt, die am und zum Rand des Netzwerks hin auftreten. Diese erweiterten Anwendungsfälle haben jedoch auch eine Anzahl entsprechender technischer Herausforderungen in Bezug auf Sicherheit, Verarbeitung und Netzwerkressourcen, Dienstverfügbarkeit und -effizienz, unter vielen anderen Problemen eingeführt, zumal mehr Arten von Rechensystemen und Konfigurationen eingesetzt werden. Eine solche Herausforderung bezieht sich auf Sicherheit und Vertrauen sowie die Verifizierung von Teilnehmern als eine vertrauenswürdige Entität oder als vertrauenswürdig oder autorisiert, um eine bestimmte Aktion durchzuführen. In diesem Zusammenhang wird eine Attestierung verwendet, um die Wahrscheinlichkeit einer bestimmten Behauptung oder Zusicherung zu bestätigen (zum Beispiel, dass eine bestimmte Entität Rechte hat, um auf bestimmte Daten zuzugreifen, um eine bestimmte Aktion durchzuführen usw.).
  • Figurenliste
  • In den Zeichnungen, die nicht notwendigerweise maßstabsgetreu gezeichnet sind, können gleiche Bezugszeichen ähnliche Komponenten in verschiedenen Ansichten beschreiben. Gleiche Zeichen mit unterschiedlichen Buchstabensuffixen können verschiedene Instanzen ähnlicher Komponenten darstellen. Einige Ausführungsformen werden in den Figuren der begleitenden Zeichnungen beispielhaft und nicht einschränkend dargestellt, in denen gilt:
    • 1 veranschaulicht eine Übersicht über eine Edge-Cloud-Konfiguration für Edge-Computing gemäß einem Beispiel;
    • 2 veranschaulicht Einsatz und Orchestrierung für virtuelle Edge-Konfigurationen über ein Edge-Rechensystem, das zwischen mehreren Edge-Knoten und mehreren Mandanten betrieben wird, gemäß einem Beispiel;
    • 3 veranschaulicht einen Rechen- und Kommunikationsanwendungsfall, der Mobilzugriff auf Anwendungen in einem Edge-Rechensystem involviert, gemäß einem Beispiel;
    • 4 veranschaulicht ein Blockdiagramm, das den Einsatz und die Kommunikationen unter einer Zahl von IoT-Vorrichtungen (Internet der Dinge) darstellt, gemäß einem Beispiel;
    • 5 veranschaulicht eine Übersicht über Schichten verteilten Rechnens, die in einem Edge-Rechensystem eingesetzt werden, gemäß einem Beispiel;
    • 6A veranschaulicht eine Übersicht über Beispielkomponenten, die in einem Rechensystem eingesetzt werden, das als ein Rechenknoten eingesetzt wird, gemäß einem Beispiel;
    • 6B veranschaulicht eine weitere Übersicht über Beispielkomponenten innerhalb eines Rechensystems, das als eine Rechenvorrichtung eingesetzt wird, gemäß einem Beispiel;
    • 6C veranschaulicht eine Softwareverteilungsplattform, die unter Rechensystemen bereitgestellt wird, gemäß einem Beispiel.
    • 7 stellt ein Attestierungsmodell dar, das nachgelagerte Entitäten in einem Edge-Rechennetzwerk zeigt, gemäß einem Beispiel;
    • 8 stellt eine Attestierungsdomänenisolation mit Verifiziererdelegierung gemäß einem Beispiel dar;
    • 9a bis 9E stellt Aspekte einer Attestierungsrollenarchitektur gemäß einem Beispiel dar;
    • 10 stellt einen Attestierungsprozess unter Verifiziererknoten gemäß einem Beispiel dar;
    • 11 stellt einen Attestierungsrollen-Delegierungsansatz gemäß einem Beispiel dar;
    • 12 stellt einen Ansatz für die Verifiziererdelegierung in einem komplexen Vorrichtungs-Mesh gemäß einem Beispiel dar;
    • 13 stellt eine Attestierungsrollenarchitektur mit einem Verifizierer, der einen Delegator zum Auslagern von Attestierungsbewertungsfunktionen enthält, gemäß einem Beispiel dar;
    • 14 stellt einen rekursiven Attestierungsprozess und damit verbundene Funktionen gemäß einem Beispiel dar; und
    • 15 veranschaulicht ein Flussdiagramm eines Verfahrens zum Durchführen von Attestierungsdelegierungsoperationen gemäß verschiedenen Beispielen.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Nachfolgend werden eine Beschreibung, Verfahren, Konfigurationen und verwandte Vorrichtungen für Entitätsattestierungstechniken offenbart. Die folgenden Beispiele erläutern spezifische Aspekte des Delegierens der Rollen von Verifizierern in komplexen Szenarien, wie etwa jene, die in komplexen Edge- oder IoT-Rechennetzwerken mit einer Vielfalt verteilter Rechenvorrichtungen zum Einsatz kommen.
  • Nachfolgend wird ein Delegierungsmechanismus vorgestellt und betrieben, der es einem bestehenden Verifizierer ermöglicht, eine andere Entität zu autorisieren, dynamisch eine Attestierungsrolle zu übernehmen. Insbesondere kann diese andere Entität autorisiert sein, die Attestierungsrolle eines Verifizierers, der hierin als „erweiterter Verifizierer“ bezeichnet wird, dynamisch zu übernehmen.
  • Bei einer Konfiguration zur Verwendung eines erweiterten Verifizierers attestiert und bewertet der bestehende Verifizierer den Attestierer, der eine Anforderung stellt, ein erweiterter Verifizierer zu sein. Falls die Bewertung des bestehenden Verifizierers erfolgreich ist, autorisiert der bestehende Verifizierer das Delegieren der Attestierungsverifiziererrolle an den Attestierer als erweiterten Verifizierer. Der erweiterte Verifizierer ist autorisiert, die Rolle des Attestierungsverifizierers für einige oder alle seiner nachgelagerten Vorrichtungen durchzuführen. Dieser erweiterte Verifizierer kann auch autorisiert sein, Berechtigungen für Attestierungsverifiziererrollen rekursiv an andere Attestierer weiterzudelegieren, die dem Netzwerk oder der vertrauenswürdigen Domäne beitreten, wieder beitreten oder bereits diesem beigetreten sind.
  • Neben anderen Vorteilen können die folgenden Attestierungstechniken verwendet werden, um (a) eine Verifiziererrolle in das Netzwerk dynamisch auszuskalieren, um die Arbeitslast auszugleichen, (b) die Datenschutzebene einer kundensensiblen Aktivität innerhalb des Teilnetzes von dem Dienstanbieter zu verbergen oder zu erhöhen, und (c) einen vertrauenswürdigen Interconnect zwischen verschiedenen Gruppen zu ermöglichen, beispielsweise zwischen vertrauenswürdigen Enklaven von verschiedenen CPU-Sockeln. Diese Attestierungstechniken können innerhalb softwaresteuerbarer Schnittstellen und einer Vielfalt von Software- und Netzwerkimplementierungen implementiert werden.
  • Insbesondere können die vorliegenden Techniken und Konfigurationen für die Attestierung in Verbindung mit vielen Aspekten der eingesetzten Vorrichtungen verwendet werden, einschließlich unter Bezugnahme auf Edge-Cloud-, IoT-, Mehrfachzugriff-Edge-Computing (MEC) und andere verteilte Recheneinsätze bereitgestellt. Die vorliegend offenbarten Techniken können sich jedoch auf andere Rechenkonfigurationen und Architekturen beziehen und sind nicht auf die Verwendung in einer verteilten Rechenumgebung beschränkt. Im Folgenden wird eine beispielhafte Einführung von Edge-Rechen- und IoT-Vorrichtungen bereitgestellt, gefolgt von einer ausführlichen Diskussion der vorliegenden Vorrichtungsattestierungsszenarien.
  • Beispielhafte Edge-Rechenarchitekturen
  • 1 ist ein Blockdiagramm 100, das einen Überblick über eine Konfiguration für Edge-Computing zeigt, die eine Verarbeitungsschicht beinhaltet, die in vielen der aktuellen Beispiele als eine „Edge-Cloud“ bezeichnet wird. Diese Netzwerktopologie, die eine Anzahl herkömmlicher Vernetzungsschichten (einschließlich der hier nicht gezeigten) beinhalten kann, kann durch die Verwendung der vorliegend erörterten Attestierungstechniken und Netzwerkkonfigurationen erweitert werden.
  • Wie gezeigt, befindet sich die Edge-Cloud 110 gemeinsam an einem Edge-Standort, wie etwa einem Zugangspunkt oder einer Basisstation 140, einem lokalen Verarbeitungs-Hub 150 oder einer Zentrale 120, und kann somit mehrere Entitäten, Vorrichtungen und Geräteinstanzen beinhalten. Die Edge-Cloud 110 befindet sich viel näher an den Endpunkt-Datenquellen 160 (Verbraucher und Erzeuger) (z. B. autonome Fahrzeuge 161, Endgerät 162, Geschäfts- und Industriegerät 163, Videoaufnahmevorrichtungen 164, Drohnen 165, Vorrichtungen für intelligente Städte und Gebäude 166, Sensoren und IoT-Vorrichtungen 167 usw.) als das Cloud-Rechenzentrum 130. Rechen-, Speicher- und Datenspeicherressourcen, die an den Rändern (Edges) in der Edge-Cloud 110 angeboten werden, sind kritisch für das Bereitstellen von Antwortzeiten mit ultraniedriger Latenz für Dienste und Funktionen, die durch die Endpunktdatenquellen 160 verwendet werden, sowie für das Reduzieren von Netzwerk-Backhaul-Verkehr von der Edge-Cloud 110 zum Cloud-Rechenzentrum 130, wodurch, neben anderen Vorteilen, der Energieverbrauch und Gesamtnetzwerknutzungen verbessert werden.
  • Rechenleistung, Speicher und Speicherung sind knappe Ressourcen und nehmen im Allgemeinen in Abhängigkeit vom Edge-Standort ab (z.B. sind weniger Verarbeitungsressourcen an Verbraucherendpunktvorrichtungen als an einer Basisstation oder an einer Zentralstelle verfügbar). Je näher jedoch der Edge-Standort am Endpunkt (z.B. UEs) liegt, desto mehr sind Platz und Leistung begrenzt. Somit versucht Edge-Computing als allgemeines Gestaltungsprinzip, die Anzahl der für Netzdienste benötigten Ressourcen durch die Verteilung von mehr Ressourcen zu minimieren, die sowohl geografisch als auch in bezüglich der Netzzugriffszeit näher liegen. Auf diese Weise versucht Edge-Computing, die Rechenressourcen gegebenenfalls zu den Arbeitslastdaten zu bringen oder die Arbeitslastdaten zu den Rechenressourcen zu bringen.
  • Das Folgende beschreibt Aspekte einer Edge-Cloud-Architektur, die mehrere potenzielle Einsätze abdeckt und Einschränkungen anspricht, die manche Netzwerkbetreiber oder Dienstanbieter in ihren eigenen Infrastrukturen aufweisen können. Diese beinhalten Variation von Konfigurationen basierend auf dem Edge-Ort (weil Edges auf einer Basisstationsebene zum Beispiel mehr eingeschränkte Leistungsfähigkeit und Fähigkeiten in einem Multi-Mandanten-Szenario aufweisen können); Konfigurationen basierend auf der Art von Berechnung, Speicher, Speicherung, Fabric, Beschleunigung oder ähnlichen Ressourcen, die Edge-Orten, Stufen von Orten oder Gruppen von Orten zur Verfügung stehen; die Dienst-, Sicherheits- und Verwaltungs- und Orchestrierungsfähigkeiten; und zugehörige Ziele zum Erreichen der Nutzbarkeit und Leistungsfähigkeit von Enddiensten. Diese Einsätze können die Verarbeitung in Netzwerkschichten bewerkstelligen, die in Abhängigkeit von Latenz-, Abstands- und Timing-Charakteristiken als „Near Edge“-, „Close Edge“-, „Local Edge“-, „Middle Edge“- oder „Far Edge“-Schichten betrachtet werden können.
  • Edge-Computing ist ein sich entwickelndes Paradigma, bei dem das Computing an oder näher am „Edge“ (Rand) eines Netzwerks durchgeführt wird, typischerweise durch die Verwendung einer Rechenplattform (z. B. x86-, AMD- oder ARM-Rechenhardwarearchitekturen), die an Basisstationen, Gateways, Netzwerkroutern oder anderen Vorrichtungen implementiert ist, die sich viel näher an Endpunktvorrichtungen befinden, die die Daten erzeugen und konsumieren. Beispielsweise können Edge-Gatewayserver mit Beständen von Speicher- und Datenspeicherressourcen ausgestattet sein, um eine Berechnung in Echtzeit für Anwendungsfälle mit niedriger Latenz (z. B. autonomes Fahren oder Videoüberwachung) für angebundene Client-Vorrichtungen durchzuführen. Oder als ein Beispiel können Basisstationen mit Rechen- und Beschleunigungsressourcen erweitert werden, um Dienstarbeitslasten für angebundene Endgeräte direkt zu verarbeiten, ohne weiter Daten über Backhaul-Netzwerke zu kommunizieren. Oder als anderes Beispiel kann die Zentralstellennetzverwaltungshardware durch Rechenhardware ersetzt werden, die virtualisierte Netzfunktionen durchführt und Rechenressourcen für die Ausführung von Diensten und Verbraucherfunktionen für verbundene Vorrichtungen anbietet. Innerhalb von Edge-Rechennetzwerken kann es Szenarien in Diensten geben, in denen die Rechenressource zu den Daten „verschoben“ wird, sowie Szenarien geben, in denen die Daten zur Rechenressource „verschoben“ werden. Oder als ein Beispiel können Rechen-, Beschleunigungs- und Netzwerkressourcen an der Basisstation Dienste bereitstellen, um die Arbeitslastanforderungen nach Bedarf zu skalieren, indem nicht genutzte Kapazität (Subskription, Capacity on Demand) aktiviert wird, um Eckfälle, Notfälle zu verwalten oder Langlebigkeit für eingesetzte Ressourcen über einen wesentlich längeren implementierten Lebenszyklus bereitzustellen. Diese und andere Szenarien können die Verwendung der Attestierung beinhalten, wie in der folgenden Diskussion bereitgestellt.
  • Im Gegensatz zur Netzarchitektur von 1 sind herkömmliche Endpunkt-Anwendungen (z.B. UE, Fahrzeug-zu-Fahrzeug (V2V), Fahrzeug-zu-Alles (V2X) usw.) auf lokale Vorrichtungs- oder Remote-Cloud-Datenspeicherung und -verarbeitung angewiesen, um Informationen auszutauschen und zu koordinieren. Eine Cloud-Datenanordnung ermöglicht eine langfristige Datensammlung und -speicherung, ist jedoch für stark zeitvariable Daten, wie eine Kollision, einen Ampelwechsel usw. nicht optimal und kann daran scheitern, Latenzherausforderungen zu erfüllen.
  • Abhängig von den Echtzeitanforderungen in einem Kommunikationskontext kann eine hierarchische Struktur von Datenverarbeitungs- und Speicherungsknoten in einer Edge-Computing-Bereitstellung definiert werden. Ein solcher Einsatz kann beispielsweise lokale Verarbeitung mit ultraniedriger Latenz, regionale Speicherung und Verarbeitung sowie auf einem entfernten Cloud-Rechenzentrum basierende Speicherung und Verarbeitung umfassen. Leistungskennzahlen (KPIs) können dafür verwendet werden, zu identifizieren, wohin Sensordaten am besten transferiert und wo sie verarbeitet oder gespeichert werden sollen. Dies hängt typischerweise von der ISO-Schicht-Abhängigkeit der Daten ab. Beispielsweise ändern sich Daten einer niedrigeren Schicht (PHY, MAC, Routing usw.) typischerweise schnell und werden besser lokal gehandhabt, um die Latenzanforderungen zu erfüllen. Daten höherer Schichten, wie Daten der Anwendungsschicht, sind typischerweise weniger zeitkritisch und können in einem entfernten Cloud-Rechenzentrum gespeichert und verarbeitet werden.
  • 2 veranschaulicht Einsatz und Orchestrierung für virtuelle Edge-Konfigurationen quer durch ein Edge-Rechensystem, das zwischen mehreren Edge-Knoten und mehreren Mandanten betrieben wird. Insbesondere stellt 2 eine Koordination eines ersten Edge-Knotens 222 und eines zweiten Edge-Knotens 224 in einem Edge-Rechensystem 200 dar, um Anforderungen und Antworten für verschiedene Client-Endpunkte 210 (z. B. intelligente Städte / Gebäudesysteme, Mobilvorrichtungen, Rechenvorrichtungen, Unternehmens-/Logistiksysteme, Industriesysteme etc.) zu erfüllen, die auf verschiedene virtuelle Edge-Instanzen zugreifen. Die virtuellen Edge-Instanzen 232, 234 (oder virtuellen Edges) stellen Edge-Rechenfähigkeiten und Verarbeitung in einer Edge-Cloud mit Zugriff auf eine Cloud/ein Rechenzentrum 240 für Anforderungen mit höherer Latenz für Websites, Anwendungen, Datenbankserver usw. bereit. Die Edge-Cloud ermöglicht jedoch eine Koordination der Verarbeitung zwischen mehreren Edge-Knoten für mehrere Mandanten oder Entitäten.
  • In dem Beispiel von 2 beinhalten diese virtuellen Edge-Instanzen: eine erste virtuelle Edge 232, die einem ersten Mandanten (Mandant 1) angeboten wird, der eine erste Kombination von Edge-Speicherung, Berechnung und Diensten anbietet; und eine zweite virtuelle Edge 234, die eine zweite Kombination von Edge-Speicherung, Berechnung und Diensten für einen zweiten Mandanten (Mandant 2) anbietet. Die virtuellen Edge-Instanzen 232, 234 sind unter den Edge-Knoten 222, 224 verteilt und können Szenarien beinhalten, in denen eine Anfrage und Antwort von demselben oder unterschiedlichen Edge-Knoten erfüllt werden. Die Konfiguration jedes Edge-Knotens 222, 224 zum Arbeiten auf eine verteilte, aber koordinierte Weise findet basierend auf Edge-Bereitstellungsfunktionen 250 statt. Die Funktionalität der Edge-Knoten 222, 224 zum Bereitstellen eines koordinierten Betriebs für Anwendungen und Dienste unter mehreren Mandanten findet basierend auf Orchestrierungsfunktionen 260 statt.
  • Es versteht sich, dass manche der Vorrichtungen in 210 Mehrmandanten-Vorrichtungen sind, wobei Mandant 1 innerhalb eines Mandant-1-„Slice“ funktionieren kann, während ein Mandant 2 innerhalb eines Mandant-2-Slice funktionieren kann (und in weiteren Beispielen können zusätzliche oder Unter-Mandanten existieren; und jeder Mandant kann sogar spezifisch berechtigt und transaktionell an einen spezifischen Satz von Merkmalen bis hinab zu spezifischen Hardwaremerkmalen gebunden sein). Eine vertrauenswürdige Multi-Mandanten-Vorrichtung kann ferner einen mandantenspezifischen kryptografischen Schlüssel enthalten, sodass die Kombination aus Schlüssel und Segment als ein „Vertrauensanker“ (Root of Trust, RoT) oder mandantenspezifischer RoT angesehen werden kann. Ein RoT kann ferner dynamisch unter Verwendung einer Sicherheitsarchitektur berechnet werden, wie etwa eine DICE (Device Identity Composition Engine)-Architektur, in der ein DICE-Hardwarebaustein verwendet wird, um geschichtete vertrauenswürdige Rechenbasiskontexte zur gesicherten und authentifizierten Schichtung von Vorrichtungsfähigkeiten (wie etwa bei Verwendung eines feldprogrammierbaren Gatearray (FPGA)) zu konstruieren. Der RoT kann auch für einen vertrauenswürdigen Rechenkontext verwendet werden, um jeweilige Mandantenoperationen zu unterstützen usw. Die Verwendung dieses RoT und der Sicherheitsarchitektur kann durch die hierin weiter erörterten Attestierungsoperationen verbessert werden.
  • Edge-Rechenknoten können Ressourcen (Speicher, Zentralverarbeitungseinheit (CPU), Grafikverarbeitungseinheit (GPU), Interrupt-Steuerung, Eingabe/Ausgabe(E/A)-Steuerung, Speichersteuerung, Bussteuerung usw.) partitionieren, wobei eine jeweilige Partitionierung eine RoT-Fähigkeit enthalten kann und wobei Fan-Out und Schichtbildung gemäß einem DICE-Modell ferner auf Edge-Knoten angewendet werden können. Cloud-Rechenknoten, die aus Containern, FaaS-Engines, Servlets, Servern oder einer anderen Berechnungsabstraktion bestehen, können gemäß einer DICE-Schichtungs- und Ausfächerungsstruktur partitioniert werden, um für jede der Abstraktionen einen RoT-Kontext zu unterstützen. Dementsprechend können die jeweiligen RoTs überspannenden Vorrichtungen in 210, 222 und 240 die Erstellung einer verteilten vertrauenswürdigen Rechenbasis (Distributed Trusted Computing Base, DCTB) koordinieren, sodass ein mandantenspezifischer virtueller vertrauenswürdiger sicherer Kanal, der alle Elemente durchgängig verknüpft, erstellt werden kann. Des Weiteren kann eine DTCB in einem Fan-in-Modell verwendet werden, bei dem mehrere Vertrauensanker in einer DICE-Schichtung ein eindeutiges Vorrichtungsgeheimnis (Unique Device Secret, UDS) beitragen können, um ein zusammengesetztes UDS zu konstruieren, das einen zusammengesetzten DTCB-Vertrauensanker beschreibt, auf dem eine traditionelle DICE-Schichtung von Fähigkeiten basieren kann.
  • Ferner versteht es sich, dass ein Container daten- oder arbeitslastspezifische Schlüssel aufweisen kann, die seinen Inhalt vor einem vorherigen Edge-Knoten schützen. Als Teil der Migration eines Containers kann eine Pod-Steuerung an einem Quell-Edge-Knoten einen Migrationsschlüssel von einer Ziel-Edge-Knoten-Pod-Steuerung erhalten, wobei der Migrationsschlüssel zum Wrappen der containerspezifischen Schlüssel verwendet wird. Wenn der Container/Pod zu dem Ziel-Edge-Knoten migriert wird, wird der Unwrapping-Schlüssel der Pod-Steuerung preisgegeben, die dann die gewrappten Schlüssel entschlüsselt. Die Schlüssel können nun zur Durchführung von Operationen an containerspezifischen Daten verwendet werden. Die Migrationsfunktionen können durch korrekt attestierte Edge-Knoten und Pod-Manager (wie oben beschrieben) angesteuert werden.
  • Zum Beispiel kann das Edge-Rechensystem erweitert werden, um Orchestrierung mehrerer Anwendungen durch die Verwendung von Containern (einer enthaltenen einsetzbaren Softwareeinheit, die Code und benötigte Abhängigkeiten bereitstellt) in einer Umgebung mit mehreren Eigentümern und mehreren Mandanten bereitzustellen. Ein mandantenfähiger Orchestrator kann verwendet werden, um Schlüsselverwaltung, Vertrauensanker-Verwaltung und andere Sicherheitsfunktionen in Bezug auf die Bereitstellung und den Lebenszyklus des vertrauenswürdigen „Slice‟-Konzepts in 2 durchzuführen. Ein Orchestrator kann eine DICE-Schichtbildungs- und Fan-Out-Konstruktion verwenden, um einen Root-of-Trust-Kontext zu erzeugen, der mandantenspezifisch ist. Somit können Orchestrierungsfunktionen, die durch einen Orchestrator bereitgestellt werden, als mandantenspezifischer Orchestrierungsanbieter beteiligt sein.
  • Dementsprechend kann ein Edge-Rechensystem konfiguriert sein, um Anfragen und Antworten für verschiedene Client-Endpunkte von mehreren virtuellen Edge-Instanzen (und von einer Cloud oder einem entfernten Rechenzentrum, nicht gezeigt) zu erfüllen. Die Verwendung dieser virtuellen Edge-Instanzen unterstützt mehrere Mandanten und mehrere Anwendungen (z. B. Augmented Reality (AR)/Virtual Reality (VR), Unternehmensanwendungen, Inhaltslieferung, Gaming, Rechen-Offload) gleichzeitig. Ferner kann es mehrere Arten von Anwendungen innerhalb der virtuellen Edge-Instanzen geben (z. B. normale Anwendungen, latenzempfindliche Anwendungen, latenzkritische Anwendungen, Benutzerebenenanwendungen, Netzwerkanwendungen usw.). Die virtuellen Edge-Instanzen können auch über Systeme mehrerer Eigentümer an unterschiedlichen geographischen Orten (oder jeweilige Rechensysteme und Ressourcen, den mehreren Eigentümern gemeinsam gehören oder gemeinsam von diesen verwaltet werden) gespannt sein.
  • Beispielsweise kann jeder Edge-Knoten 222, 224 die Verwendung von Containern implementieren, wie etwa unter Verwendung eines Container-„Pods“ 226, 228, der eine Gruppe von einem oder mehreren Containern bereitstellt. In einem Szenario, das eine oder mehrere Container-Pods verwendet, ist eine Pod-Steuerung oder ein Orchestrator für die lokale Steuerung und Orchestrierung der Container im Pod verantwortlich. Verschiedene Edge-Knotenressourcen (z. B. Speicherung, Berechnung, Dienste, dargestellt mit Hexagonen), die für die jeweiligen Edge-Slices der virtuellen Edges 232, 234 bereitgestellt werden, werden gemäß den Bedürfnissen jedes Containers partitioniert.
  • Bei der Verwendung von Container-Pods übersieht eine Pod-Steuerung die Partitionierung und Zuweisung von Containern und Ressourcen. Die Pod-Steuerung empfängt Anweisungen von einem Orchestrator (der z. B. die Orchestrierungsfunktionen 260 durchführt), die die Steuerung darüber anweisen, wie physische Ressourcen am besten zu partitionieren sind und für welche Dauer, wie etwa durch Empfangen von KPI (Key Performance Indicator)-Zielen basierend auf SLA-Verträgen. Die Pod-Steuerung bestimmt, welcher Container welche Ressourcen und für wie lange benötigt, um die Arbeitslast abzuschließen und das SLA zu erfüllen. Die Pod-Steuerung verwaltet auch Container-Lebenszyklusvorgänge, wie etwa: Erzeugen des Containers, Versehen desselben mit Ressourcen und Anwendungen, Koordinieren von Zwischenergebnissen zwischen mehreren Containern, die auf einer verteilten Anwendung zusammenarbeiten, Zerlegen von Containern, wenn die Arbeitslast abgeschlossen ist, und dergleichen. Zusätzlich dazu kann eine Pod-Steuerung eine Sicherheitsrolle spielen, die die Zuweisung von Ressourcen verhindert, bis sich der rechte Mandant authentifiziert, oder eine Bereitstellung von Daten oder einer Arbeitslast an einen Container verhindert, bis ein Attestierungsergebnis erfüllt ist.
  • Auch bei der Verwendung von Container-Pods können Mandantengrenzen weiterhin existieren, jedoch im Kontext jedes Pods von Containern. Falls jeder mandantenspezifische Pod eine mandantenspezifische Pod-Steuerung aufweist, wird es eine gemeinsam genutzte Pod-Steuerung geben, die Ressourcenzuweisungsanforderungen konsolidiert, um typische Ressourcenmangelsituationen zu vermeiden. Weitere Steuerungen können vorgesehen sein, um die Attestierung und Vertrauenswürdigkeit des Pods und der Pod-Steuerung zu gewährleisten. Beispielsweise kann der Orchestrator 260 lokalen Pod-Steuerungen, die eine Attestierungsverifizierung durchführen, eine Attestierungsverifizierungsrichtlinie bereitstellen. Falls eine Attestierung eine Richtlinie für eine erste Mandanten-Pod-Steuerung, aber nicht eine zweite Mandanten-Pod-Steuerung erfüllt, dann könnte der zweite Pod zu einem anderen Edge-Knoten migriert werden, der ihn erfüllt. Alternativ dazu kann dem ersten Pod erlaubt werden, ausgeführt zu werden, und eine andere gemeinsam genutzte Pod-Steuerung wird installiert und aufgerufen, bevor der zweite Pod ausgeführt wird.
  • In weiteren Beispielen können Edge-Rechensysteme Container in einem Edge-Rechensystem einsetzen. Als ein vereinfachtes Beispiel ist ein Container-Manager dazu vorgesehen, containerisierte Pods, Funktionen und Functions-as-a-Service-Instanzen durch Ausführung über Rechenknoten zu starten oder containerisierte virtualisierte Netzwerkfunktionen durch Ausführung über Rechenknoten separat auszuführen. Diese Anordnung kann zur Verwendung durch mehrere Mandanten in einer Systemanordnung angepasst sein, bei der containerisierte Pods, Funktionen und Functions-as-a-Service-Instanzen innerhalb virtueller Maschinen gestartet werden, die spezifisch für jeweilige Mandanten sind (abgesehen von der Ausführung virtualisierter Netzwerkfunktionen).
  • Innerhalb der Edge-Cloud können ein erster Edge-Knoten 222 (z. B. betrieben durch einen ersten Eigentümer) und ein zweiter Edge-Knoten 224 (z. B. betrieben durch einen zweiten Eigentümer) einen Container-Orchestrator betrieben oder diesem antworten, um die Ausführung verschiedener Anwendungen innerhalb der virtuellen Edge-Instanzen, die für jeweilige Mandanten angeboten werden, zu koordinieren. Zum Beispiel können die Edge-Knoten 222, 224 basierend auf Edge-Bereitstellungsfunktionen 250 koordiniert werden, während der Betrieb der verschiedenen Anwendungen mit Orchestrierungsfunktionen 260 koordiniert wird.
  • Verschiedene Systemanordnungen können eine Architektur bereitstellen, die VMs, Container und Funktionen hinsichtlich der Anwendungszusammensetzung gleich behandelt (und resultierende Anwendungen sind Kombinationen dieser drei Bestandteile). Jeder Bestandteil kann die Verwendung einer oder mehrerer Beschleuniger-Komponenten (z. B. FPGA, ASIC) als ein lokales Backend beinhalten. Auf diese Weise können Anwendungen über mehrere Edge-Eigentümer aufgeteilt werden, koordiniert durch einen Orchestrator.
  • Es versteht sich, dass die hierin erörterten Edge-Rechensysteme und -Anordnungen in verschiedenen Lösungen, Diensten und/oder Anwendungsfällen anwendbar sein können,. Als ein Beispiel zeigt 3 einen vereinfachten Fahrzeugberechnungs- und Kommunikationsanwendungsfall, der Mobilzugriff auf Anwendungen in einem Edge-Rechensystem 300 einbezieht, das eine Edge-Cloud 110 implementiert. In diesem Verwendungsfall kann jeder Client-Rechenknoten 310 als fahrzeuginterne Rechensysteme (z. B. fahrzeuginterne Navigations- und/oder Infotainment-Systeme) umgesetzt sein, die sich in entsprechenden Fahrzeugen befinden, die mit den Edge-Gateway-Knoten 320 während des Fahrens entlang einer Straße kommunizieren. Beispielsweise können sich Edge-Gateway-Knoten 320 in Schränken am Straßenrand befinden, die entlang der Straße, an Kreuzungen der Straße oder anderen Orten nahe der Straße platziert werden können. Während jedes Fahrzeug entlang der Straße fährt, kann die Verbindung zwischen seinem Client-Rechenknoten 310 und einem ermittelten Edge-Gateway-Knoten 320 propagieren, sodass eine konsistente Verbindung und ein konsistenter Kontext für den Client-Rechenknoten 310 aufrechterhalten werden. Jeder der Edge-Gateway-Knoten 320 beinhaltet eine gewisse Anzahl an Verarbeitungs- und Speicherungsfähigkeiten und daher kann eine gewisse Verarbeitung und/oder Speicherung von Daten für die Client-Rechenknoten 310 auf einem oder mehreren der Edge-Gateway-Knoten 320 durchgeführt werden.
  • Jeder der Edge-Gateway-Knoten 320 kann mit einem oder mehreren Edge-Ressourcenknoten 340 kommunizieren, die veranschaulichend als Rechenserver, -geräte oder -komponenten umgesetzt sind, die sich an oder in einer Kommunikationsbasisstation 342 (z. B. einer Basisstation eines zellularen Netzwerks) befinden. Wie vorstehend erörtert, beinhaltet jeder der Edge-Ressourcenknoten 340 eine gewisse Anzahl an Verarbeitungs- und Speicherungsfähigkeiten, sodass eine gewisse Verarbeitung und/oder Speicherung von Daten für die Client-Rechenknoten 310 an dem Edge-Ressourcenknoten 340 durchgeführt werden können. Zum Beispiel kann die Verarbeitung von Daten, die weniger dringend oder wichtig sind, durch den Edge-Ressourcenknoten 340 durchgeführt werden, während die Verarbeitung von Daten, die eine höhere Dringlichkeit oder Wichtigkeit aufweisen, durch die Edge-Gateway-Vorrichtungen oder die Client-Knoten selbst durchgeführt werden kann (in Abhängigkeit von zum Beispiel den Fähigkeiten jeder Komponente).
  • Der eine oder die mehreren Edge-Ressourcenknoten 340 kommunizieren auch mit dem Kernrechenzentrum 350, das Rechenserver, Geräte und/oder andere Komponenten beinhalten kann, die sich an einem zentralen Standort (z. B. einer Zentrale eines Mobilfunkkommunikationsnetzes) befinden. Das Kernrechenzentrum 350 kann ein Gateway zur globalen Netzwerk-Cloud 360 (z.B. dem Internet) für die Operationen der Edge-Cloud 110 bereitstellen, das durch den/die Edge-Ressourcenknoten 340 und die Edge-Gateway-Knoten 320 gebildet wird. Zusätzlich kann das Kernrechenzentrum 350 in manchen Beispielen eine Menge an Verarbeitungs- und Speicherungsfähigkeiten beinhalten und somit kann eine gewisse Verarbeitung und/oder Speicherung von Daten für die Client-Rechenvorrichtungen auf dem Kernrechenzentrum 350 durchgeführt werden (z. B. Verarbeitung mit niedriger Dringlichkeit oder Wichtigkeit oder hoher Komplexität). Die Edge-Gateway-Knoten 320 oder die Edge-Ressourcenknoten 340 können die Verwendung zustandsorientierter Anwendungen 332 und einen geografisch verteilten Datenspeicher 334 (z. B. Datenbank, Datenspeicher usw.) anbieten.
  • In weiteren Beispielen kann 3 verschiedene Arten von mobilen Edge-Knoten verwenden, wie z. B. ein Edge-Knoten, der in einem Fahrzeug (z. B. einem Auto, einem Lastwagen, einer Straßenbahn, einem Zug usw.) oder einer anderen mobilen Einheit untergebracht ist, da sich der Edge-Knoten entlang der Plattform, auf der er untergebracht ist, zu anderen geografischen Standorten bewegt. Bei Fahrzeug-zu-Fahrzeug-Kommunikationen können einzelne Fahrzeuge sogar als Netzwerk-Edge-Knoten für andere Autos fungieren (z. B. um Caching, Berichterstellung, Datenaggregation usw. durchzuführen). Somit versteht es sich, dass die Anwendungskomponenten, die in verschiedenen Edge-Knoten bereitgestellt sind, in vielzähligen Szenarien verteilt sein können, einschließlich Koordination zwischen einigen Funktionen oder Operationen an einzelnen Endpunktvorrichtungen oder den Edge-Gateway-Knoten 320, einigen anderen an dem Edge-Ressourcenknoten 340 und anderen in dem Kernrechenzentrum 350 oder in der globalen Netzwerk-Cloud 360.
  • In weiteren Konfigurationen kann das Edge-Rechensystem FaaS-Rechenfähigkeiten durch die Verwendung jeweiliger ausführbarer Anwendungen und Funktionen implementieren. In einem Beispiel schreibt ein Entwickler Funktionscode (hierin z. B. „Computercode“), der eine oder mehrere Computerfunktionen repräsentiert, und der Funktionscode wird auf eine FaaS-Plattform hochgeladen, die zum Beispiel durch einen Edge-Knoten oder ein Rechenzentrum bereitgestellt wird. Ein Auslöser, wie etwa beispielsweise ein Dienstanwendungsfall oder ein Edge-Verarbeitungsereignis, initiiert die Ausführung des Funktionscodes mit der FaaS-Plattform.
  • Bei einem Beispiel für FaaS wird ein Container verwendet, um eine Umgebung bereitzustellen, in der Funktionscode ausgeführt wird. Der Container kann eine beliebige Entität mit isolierter Ausführung sein, wie etwa ein Prozess, ein Docker- oder Kubernetes-Container, eine virtuelle Maschine usw. Innerhalb des Edge-Rechensystems werden verschiedene Rechenzenten-, Edge- und Endpunktvorrichtungen (einschließlich Mobilvorrichtungen) verwendet, um Funktionen „hochzufahren“ (z. B. Funktionsaktionen zu aktivieren und/oder zuzuweisen), die auf Abruf skaliert werden. Der Funktionscode wird auf der physischen Infrastrukturvorrichtung (z. B. Edge-Rechenknoten) und zugrundeliegenden virtualisierten Containern ausgeführt. Schließlich wird der Container auf der Infrastruktur als Reaktion darauf, dass die Ausführung abgeschlossen ist, „heruntergefahren“ (z. B. deaktiviert und/oder freigegeben).
  • Weitere Aspekte von FaaS können eine Bereitstellung von Edge-Funktionen auf Dienstweise ermöglichen, einschließlich einer Unterstützung jeweiliger Funktionen, die Edge-Computing als Dienst unterstützen. Zusätzliche Merkmale von FaaS können Folgendes beinhalten: eine granuläre Abrechnungskomponente, die Kunden (z. B. Computercodeentwicklern) ermöglicht, nur zu bezahlen, wenn ihr Code ausgeführt wird; gemeinsame Datenspeicherung zum Speichern von Daten zur Wiederverwendung durch eine oder mehrere Funktionen; Orchestrierung und Verwaltung zwischen einzelnen Funktionen; Funktionsausführungsverwaltung, Parallelität und Konsolidierung; Verwaltung von Container- und Funktionsspeicherplätzen; Koordination von Beschleunigungsressourcen, die für Funktionen verfügbar sind; und Verteilung von Funktionen zwischen Containern (einschließlich „warmer“ Container, die bereits eingesetzt oder betrieben werden, gegenüber „kalten“ Containern, die eine Bereitstellung oder Konfiguration erfordern).
  • Beispielhafte Internet-der-Dinge-Architekturen
  • Als eine ausführlichere Veranschaulichung eines Internet-der-Dinge (IoT)-Netzwerks veranschaulicht 4 eine Zeichnung einer Cloud oder eines Edge-Rechennetzwerks, bezeichnet als „Cloud“ 400, in Kommunikation mit einer Anzahl von IoT-Vorrichtungen. Das IoT ist ein Konzept, bei dem eine große Anzahl von Rechenvorrichtungen miteinander und mit dem Internet verbunden sind, um Funktionalität und Datenerfassung auf sehr niedriger Ebene bereitzustellen. Somit kann, wie hier verwendet, eine IoT-Vorrichtung eine semiautonome Vorrichtung umfassen, die eine Funktion, wie etwa Erfassen oder Steuern, unter anderem in Kommunikation mit anderen IoT-Vorrichtungen und einem breiteren Netzwerk, wie etwa dem Internet, durchführt.
  • Häufig sind IoT-Vorrichtungen hinsichtlich Speicher, Größe oder Funktionalität beschränkt, wodurch ermöglicht wird, dass größere Anzahlen für ähnliche Kosten wie kleinere Anzahlen von größeren Vorrichtungen eingesetzt werden. Eine IoT-Vorrichtung kann jedoch ein Smartphone, Laptop, Tablet oder PC oder eine andere größere Vorrichtung sein. Ferner kann eine IoT-Vorrichtung eine virtuelle Vorrichtung sein, wie etwa eine Anwendung auf einem Smartphone oder einer anderen Rechenvorrichtung. IoT-Vorrichtungen können IoT-Gateways aufweisen, die verwendet werden, um IoT-Vorrichtungen mit anderen IoT-Vorrichtungen und mit Cloud-Anwendungen zu koppeln, zur Datenspeicherung, Prozesssteuerung und dergleichen.
  • Netzwerke von IoT-Vorrichtungen können kommerzielle und Haushaltsautomatisierungsvorrichtungen aufweisen, wie etwa Wasserverteilungssysteme, Stromverteilungssysteme, Pipeline-Steuerungssysteme, Anlagensteuerungssysteme, Lichtschalter, Thermostate, Schlösser, Kameras, Alarme, Bewegungssensoren und dergleichen. Die IoT-Vorrichtungen können durch Ferncomputer, Server und andere Systeme zugänglich sein, um zum Beispiel Systeme zu steuern oder auf Daten zuzugreifen.
  • Erneut Bezug nehmend auf 4 kann die Cloud 400 das Internet darstellen oder kann ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetzwerk (WAN), wie beispielsweise ein proprietäres Netzwerk für ein Unternehmen, sein. Die IoT-Vorrichtungen können eine beliebige Anzahl unterschiedlicher Typen von Vorrichtungen beinhalten, die in verschiedenen Kombinationen gruppiert sind. Zum Beispiel kann eine Verkehrssteuerungsgruppe 406 IoT-Vorrichtungen entlang von Straßen in einer Stadt beinhalten. Diese IoT-Vorrichtungen können Ampeln, Verkehrsflussüberwachungsgeräte, Kameras, Wettersensoren und dergleichen umfassen. Die Verkehrssteuerungsgruppe 406 oder andere Untergruppen können über drahtgebundene oder drahtlose Links 408, wie etwa LPWA-Links, optische Links und dergleichen, in Kommunikation mit der Cloud 400 stehen. Weiter kann ein verdrahtetes oder drahtloses Unternetzwerk 412 den IoT-Vorrichtungen erlauben, miteinander zu kommunizieren, wie beispielsweise über ein lokales Netz, ein drahtloses lokales Netzwerk und dergleichen. Die IoT-Vorrichtungen können eine andere Vorrichtung, wie etwa einen Gateway 410 oder 428, verwenden, um mit entfernten Standorten, wie etwa der Cloud 400, zu kommunizieren; die IoT-Vorrichtungen können auch einen oder mehrere Server 430 verwenden, um die Kommunikation mit der Cloud 400 oder mit dem Gateway 410 zu erleichtern. Zum Beispiel können der eine oder die mehreren Server 430 als Zwischennetzknoten arbeiten, um eine lokale Edge-Cloud- oder Fog-Umsetzung in einem lokalen Netzwerk zu unterstützen. Weiter kann das abgebildete Gateway 428 in einer Cloud-zu-Gateway-Konfiguration zu vielen Edge-Vorrichtungen betrieben werden, wie beispielsweise mit den verschiedenen IoT-Vorrichtungen 414, 420, 424, die auf eine Zuweisung und Verwendung von Ressourcen in der Cloud 400 beschränkt oder dynamisch sind.
  • Andere beispielhafte Gruppen von IoT-Vorrichtungen können unter anderem entfernte Wetterstationen 414, lokale Informationsendgeräte 416, Alarmsysteme 418, Geldautomaten 420, Alarmtafeln 422 oder sich bewegende Fahrzeuge, wie etwa Einsatzfahrzeuge 424 oder andere Fahrzeuge 426, umfassen. Jede dieser IoT-Vorrichtungen kann in Kommunikation mit anderen IoT-Vorrichtungen, mit Servern 404, mit einer anderen IoT-Vorrichtung oder - System, einem anderen Edge-Computing- oder „Fog“-Rechensystem oder einer Kombination davon stehen. Die Gruppen von IoT-Vorrichtungen können in verschiedenen Wohn-, Gewerbe- und Industrieumgebungen (einschließlich sowohl in privaten als auch in öffentlichen Umgebungen) eingesetzt werden.
  • Wie aus 4 ersichtlich ist, kann eine große Anzahl von IoT-Vorrichtungen durch die Cloud 400 kommunizieren. Dies kann es verschiedenen IoT-Vorrichtungen ermöglichen, autonom Informationen von anderen Vorrichtungen anzufordern oder an diese zu liefern. Zum Beispiel kann eine Gruppe von IoT-Vorrichtungen (zum Beispiel die Verkehrssteuerungsgruppe 406) eine aktuelle Wettervorhersage von einer Gruppe entfernter Wetterstationen 414, die die Vorhersage ohne menschliches Eingreifen bereitstellen können, anfordern. Weiter kann ein Einsatzfahrzeug 424 von einem Geldautomaten 420 gewarnt werden, dass gerade ein Einbruch stattfindet. Wenn das Einsatzfahrzeug 424 zu dem Geldautomaten 420 fährt, kann es auf die Verkehrssteuergruppe 406 zugreifen, um eine Freigabe zu dem Standort anzufordern, indem beispielsweise Ampeln rot werden, um Querverkehr an einer Kreuzung rechtzeitig Zeit zu blockieren, damit das Einsatzfahrzeug 424 ungehinderten Zugang zur Kreuzung hat.
  • Cluster von IoT-Vorrichtungen können dahingehend ausgestattet sein, mit anderen IoT-Vorrichtungen sowie mit einem Cloud-Netzwerk zu kommunizieren. Dies kann ermöglichen, dass die IoT-Vorrichtungen ein Ad-hoc-Netzwerk zwischen den Vorrichtungen bilden, wodurch ermöglicht wird, dass sie als eine einzelne Vorrichtung fungieren, die als eine Fog-Vorrichtung oder -System bezeichnet werden kann. Cluster von IoT-Vorrichtungen, wie sie etwa durch die entfernten Wetterstationen 414 oder die Verkehrssteuergruppe 406 bereitgestellt werden, können dahingehend ausgestattet sein, um mit anderen IoT-Vorrichtungen sowie mit der Cloud 400 zu kommunizieren. Dies kann ermöglichen, dass die IoT-Vorrichtungen ein Ad-hoc-Netzwerk zwischen den Vorrichtungen bilden, wodurch ermöglicht wird, dass sie als eine einzelne Vorrichtung fungieren, die als eine Fog-Vorrichtung oder -System bezeichnet werden kann.
  • In weiteren Beispielen kann eine Vielfalt von Topologien für IoT-Netze verwendet werden, die IoT-Vorrichtungen umfassen, wobei die IoT-Netze über Backbone-Links mit jeweiligen Gateways gekoppelt sind. Zum Beispiel kann eine Anzahl von IoT-Vorrichtungen mit einem Gateway und miteinander durch das Gateway kommunizieren. Die Backbone-Links können eine beliebige Anzahl verdrahteter oder drahtloser Technologien beinhalten, einschließlich optischer Netzwerke, und können Teil eines lokalen Netzwerks (LAN), eines Weitverkehrsnetzwerks (WAN) oder des Internets sein. Außerdem erleichtern derartige Kommunikations-Links optische Signalwege zwischen sowohl den IoT-Vorrichtungen und Gateways, einschließlich der Verwendung von MUX/DeMUX-Bauelementen, die eine Verbindung der verschiedenen Vorrichtungen miteinander erleichtern.
  • Die Netztopologie kann eine beliebige Anzahl von Typen von IoT-Netzwerken beinhalten, wie etwa ein Mesh-Netzwerk, das mit dem Netzwerk unter Verwenden von Bluetooth-Low-Energy (BLE)-Links bereitgestellt wird. Andere Arten von IoT-Netzwerken, die vorhanden sein können, beinhalten ein Wireless-Local-Area-Network (WLAN-Netzwerk), das verwendet wird, um mit IoT-Vorrichtungen durch IEEE802.11(Wi-Fi®)-Links zu kommunizieren, ein Mobilfunknetz, das verwendet wird, um mit IoT-Vorrichtungen über ein LTE/LTE-A(4G)- oder 5G-Mobilfunknetzwerk zu kommunizieren, und ein Low-Power-Wide-Area-Netzwerk (LPWA), zum Beispiel ein LPWA-Netzwerk, das mit der von der LoRa-Allianz veröffentlichten LoRaWan-Spezifikation kompatibel ist, oder ein IPv6-over-Low-Power-Wide-Area-Networks-Netzwerk (LPWAN-Netzwerk), das mit einer von der Internet Engineering Task Force (IETF) veröffentlichten Spezifikation kompatibel ist.
  • Weiter können die jeweiligen IoT-Netzwerke mit einem externen Netzanbieter (zum Beispiel einem Ebene-2- oder Ebene-3-Anbieter) unter Verwenden einer beliebigen Anzahl von Kommunikations-Links kommunizieren, wie beispielsweise einem LTE-Zellular-Link, einem LPWA-Link oder einem Link basierend auf dem IEEE-802.15.4-Standard, wie Zigbee®. Die jeweiligen IoT-Netzwerke können auch mit Verwendung einer Vielfalt von Netzwerk- und Internetanwendungsprotokollen, wie dem Constrained Application Protocol (CoAP), arbeiten. Die jeweiligen IoT-Netzwerke können auch in Koordinatorvorrichtungen integriert werden, die eine Kette von Links bereitstellen, die einen Clusterbaum aus verknüpften Vorrichtungen und Netzwerken bildet.
  • IoT-Netzwerke können durch die Integration von Sensortechnologien, wie Ton-, Licht-, elektronischer Verkehrs-, Gesichts- und Mustererkennung, Geruch, Vibration, in die autonomen Organisationen unter den IoT-Vorrichtungen weiter verbessert werden. Die Integration sensorischer Systeme kann systematische und autonome Kommunikation und Koordination der Dienstleistungserbringung gegen vertragliche Dienstleistungsziele, Orchestrierung und Laufzeitdiensts (QoS) basiertes Schwärmen und Fusion von Ressourcen ermöglichen.
  • Ein IoT-Netzwerk, das zum Beispiel als Mesh-Netzwerk angeordnet ist, kann von Systemen erweitert werden, die Inline-Daten-zu-Informationen-Transformationen ausführen. Zum Beispiel können selbstbildende Ketten von Verarbeitungsressourcen, die ein Multilink-Netzwerk umfassen, die Transformation von Rohdaten in Informationen auf eine effiziente Weise verteilen und die Fähigkeit, zwischen Assets und Ressourcen und deren assoziierter Verwaltung unterscheiden. Darüber hinaus können die richtigen Bauelemente von infrastruktur- und ressourcenbasierten Vertrauens- und Dienstindizes eingefügt werden, um die Datenintegrität, Qualität und Sicherheit zu verbessern und eine Metrik einer Datenkonfidenz bereitzustellen.
  • Ein IoT-Netzwerk, das zum Beispiel als Mesh-Netzwerk angeordnet ist, kann Systeme verwenden, die eine Standardumwandlung ausführen, um Multistandard-Konnektivität bereitzustellen, wodurch IoT-Vorrichtungen, die unterschiedliche Protokolle verwenden, kommunizieren können. Weitere Systeme können eine nahtlose Interkonnektivität über eine Mehrfachstandardinfrastruktur bereitstellen, die sichtbare Internetressourcen und verborgene Internetressourcen umfasst.
  • Ein IoT-Netzwerk, das zum Beispiel Kommunikationen in dem Mobilfunknetzwerk verwendet, kann von Systemen verbessert werden, die Daten auslagern, Kommunikationen auf weiter entfernte Vorrichtungen erweitern oder beides. Ein LPWA-Netzwerk kann Systeme aufweisen, die Nicht-Internetprotokoll (IP)-zu-IP-Verbindungen, Adressieren und Routing durchführen. Weiter kann jede der IoT-Vorrichtungen den geeigneten Transceiver für die Weitverkehrskommunikation mit dieser Vorrichtung beinhalten. Weiter kann jede IoT-Vorrichtung andere Transceiver für Kommunikationen unter Verwenden zusätzlicher Protokolle und Frequenzen beinhalten.
  • In weiteren Beispielen kann ein Edge- oder Cloud-Computing-Netzwerk mit einem Mesh-Netzwerk von IoT-Vorrichtungen am Rand des Cloud-Computing-Netzwerks in Kommunikation stehen. Das Mesh-Netzwerk aus IoT-Vorrichtungen kann als Fog-Vorrichtung oder -System bezeichnet werden, die/das am Rand der Cloud arbeitet. Diese Fog-Vorrichtung oder dieses System kann ein massiv verbundenes Netzwerk sein, in dem eine Anzahl von IoT-Vorrichtungen zum Beispiel über Funkverbindungen miteinander in Kommunikation stehen. Als ein Beispiel kann dieses untereinander verbundene Netzwerk unter Verwenden einer Interconnect-Spezifikation, die von der Open Connectivity Foundation™ (OCF) veröffentlicht wurde, ermöglicht werden. Dieser Standard ermöglicht es Vorrichtungen, sich gegenseitig zu entdecken und Kommunikationen für Zwischenverbindungen aufzubauen. Es können auch andere Interconnect-Protokolle verwendet werden, einschließlich zum Beispiel des optimierten Link-State-Routing-Protokolls (OLSR-Protokolls), des Better-Approach-to-Mobile-Ad-hoc-Networking-Routing-Protokolls (B.A.T.M.A.N.-Routing-Protokolls) oder des OMA-Lightweight-M2M-Protokolls (LWM2M-Protokolls).
  • Beispielrechenvorrichtungen
  • Auf einer mehr generischen Ebene kann ein Edge-Rechensystem so beschrieben werden, dass es eine beliebige Anzahl von Einsätzen beinhaltet, die in der Edge-Cloud 110 arbeiten, die eine Koordination von Client- und verteilten Rechenvorrichtungen bereitstellen. 5 stellt einen weiter abstrahierten Überblick über Schichten verteilten Rechnens bereit, die zu Veranschaulichungszwecken in einer Edge-Computing-Umgebung eingesetzt werden.
  • 5 bildet generisch ein Edge-Rechensystem zum Bereitstellen von Edge-Diensten und Anwendungen an Multi-Stakeholder-Entitäten ab, wie sie unter einem oder mehreren Client-Rechenknoten 502, einem oder mehreren Edge-Gateway-Knoten 512, einem oder mehreren Edge-Aggregationsknoten 522, einem oder mehreren Kernrechenzentren 532 und einer globalen Netzwerk-Cloud 542 verteilt sind, wie sie über Schichten des Netzwerks verteilt sind. Die Implementierung des Edge-Rechensystems kann in einem oder im Auftrag eines Telekommunikationsdienstanbieters („Telco“ oder „TSP“), Internet-der-Dinge-Dienstanbieters, Cloud-Dienstanbieters (CSP), einer Unternehmensentität oder einer beliebigen anderen Anzahl von Entitäten bereitgestellt werden.
  • Jeder Knoten oder jede Vorrichtung des Edge-Rechensystems befindet sich auf einer speziellen Schicht, die den Schichten 510, 520, 530, 540, 550 entspricht. Zum Beispiel befinden sich die Client-Rechenknoten 502 jeweils auf einer Endpunktschicht 510, während sich jeder der Edge-Gateway-Knoten 512 auf einer Edge-Vorrichtungsschicht 520 (lokale Ebene) des Edge-Rechensystems befindet. Zusätzlich befindet sich jeder der Edge-Aggregationsknoten 522 (und/oder Fog-Vorrichtungen 524, falls sie mit oder unter einer Fog-Vernetzungskonfiguration 526 angeordnet oder betrieben werden) auf einer Netzwerkzugangsschicht 530 (einer Zwischenebene). Fog-Computing (oder „Fogging“) bezieht sich allgemein auf Erweiterungen von Cloud-Computing zur Edge eines Unternehmensnetzwerks, typischerweise in einem koordinierten verteilten oder Mehrknotennetzwerk. Einige Formen des Fog-Computing sehen den Einsatz von Rechen-, Speicher- und Netzwerkdiensten zwischen Endvorrichtungen und Cloud-Computing-Datenzentren im Auftrag der Cloud-Computing-Standorte vor. Solche Formen von Fog-Computing stellen Operationen bereit, die mit Edge-Computing, wie hier erörtert, konsistent sind; viele der vorliegend erörterten Edge-Computing-Aspekte sind auf Fog-Netzwerke, Fogging und Fog-Konfigurationen anwendbar. Ferner können Gesichtspunkte der hierin erörterten Edge-Rechensysteme als ein Fog konfiguriert sein oder Gesichtspunkte eines Fogs können in eine Edge-Rechenarchitektur integriert sein.
  • Das Kernrechenzentrum 532 befindet sich auf einer Kernnetzschicht 540 (z.B. einer regionalen oder geographisch zentralen Ebene), während sich die globale Netzwerk-Cloud 542 auf einer Cloud-Rechenzentrumschicht 550 (z.B. einer nationalen oder globalen Schicht) befindet. Die Verwendung von „Kern“ ist als Begriff für einen zentralen Netzwerkort - tiefer im Netzwerk - vorgesehen, auf den mehrere Edge-Knoten oder Komponenten zugreifen können; ein „Kern“ bezeichnet jedoch nicht notwendigerweise den „Mittelpunkt“ oder den tiefsten Ort des Netzwerks. Dementsprechend kann das Kernrechenzentrum 532 innerhalb, in oder nahe der Edge-Cloud 110 angeordnet sein.
  • Auch wenn eine veranschaulichende Anzahl von Client-Rechenknoten 502, Edge-Gateway-Knoten 512, Edge-Aggregationsknoten 522, Kernrechenzentren 532, globalen Netzwerk-Clouds 542 in 5 gezeigt ist, versteht es sich, dass das Edge-Rechensystem mehr oder weniger Vorrichtungen oder Systeme auf jeder Schicht beinhalten kann. Außerdem nimmt, wie in 5 gezeigt, die Anzahl von Komponenten jeder Schicht 510, 520, 530, 540, 550 allgemein auf jeder niedrigeren Ebene zu (d.h. wenn man sich näher an Endpunkte bewegt). Daher kann ein Edge-Gateway-Knoten 512 mehrere Client-Rechenknoten 502 bedienen, und ein Edge-Aggregationsknoten 522 kann mehrere Edge-Gateway-Knoten 512 bedienen.
  • Im Einklang mit den vorliegend bereitgestellten Beispielen kann jeder Client-Rechenknoten 502 als eine beliebige Art von Endpunktkomponente, - vorrichtung, -gerät oder ein anderes zum Kommunizieren als ein Produzent oder Konsument von Daten fähiges „Ding“ realisiert sein. Ferner bedeutet die Bezeichnung „Knoten“ oder „Vorrichtung“, wie im Edge-Rechensystem 500 verwendet, nicht unbedingt, dass solch ein Knoten oder solch eine Vorrichtung in einer Client- oder Agenten-/Follower-/Minion-Rolle arbeiten; vielmehr beziehen sich beliebige der Knoten oder Vorrichtungen im Edge-Rechensystem 500 auf einzelne Entitäten, Knoten oder Subsysteme, die diskrete oder verbundene Hardware- oder Softwarekonfigurationen umfassen, um die Edge-Cloud 110 zu ermöglichen oder zu verwenden.
  • Somit ist die Edge-Cloud 110 aus Netzwerkkomponenten und funktionalen Merkmalen gebildet, die durch und innerhalb der Edge-Gateway-Knoten 512 bzw. der Edge-Aggregationsknoten 522 der Schichten 520, 530 betrieben werden. Die Edge-Cloud 110 kann als ein beliebiger Typ von Netzwerk ausgebildet sein, der Edge-Computing- und/oder Speicherressourcen bereitstellt, die in der Nähe von Funkzugangsnetz- (RAN-) fähigen Endpunktvorrichtungen (z.B. mobilen Rechenvorrichtungen, IoT-Vorrichtungen, intelligenten Vorrichtungen usw.) angeordnet sind, die in 5 als die Client-Rechenknoten 502 gezeigt sind. Mit anderen Worten kann die Edge-Cloud 110 als eine „Edge“ vorgesehen sein, die die Endpunktvorrichtungen und herkömmlichen Mobilnetzzugangspunkten verbindet, die als ein Eintrittspunkt in Dienstanbieterkernnetze dienen, einschließlich Trägernetzwerken (z.B. GSM-(Global System for Mobile Communications) Netzwerke, LTE- (Long Term Evolution) Netzwerke, 5G-Netzwerke usw.), während auch Speicherungs- und/oder Rechenfähigkeiten bereitgestellt werden. Andere Arten und Formen von Netzwerkzugang (z.B. WiFi, drahtlose Netzwerke mit großer Reichweite) können auch anstelle von oder in Kombination mit solchen 3GPP Trägernetzwerken genutzt werden.
  • In einigen Beispielen kann die Edge-Cloud 110 einen Abschnitt einer Fog-Netzwerkkonfiguration 526 (z. B. eines Netzwerks der Fog-Vorrichtungen 524, nicht im Detail gezeigt) bilden oder anderweitig einen Zugangspunkt in diese oder über diese hinweg bereitstellen, der als eine horizontale und verteilte Architektur auf Systemebene ausgebildet sein kann, die Ressourcen und Dienste verteilt, um eine bestimmte Funktion durchzuführen. Ein koordiniertes und verteiltes Netzwerk der Fog-Vorrichtungen 524 kann beispielsweise Rechnen, Speicherung, Steuerung oder Netzwerkgesichtspunkte im Kontext einer IdD-Systemanordnung durchführen. Andere vernetzte, aggregierte und verteilte Funktionen können in der Edge-Cloud 110 zwischen der Kernrechenzentrumschicht 550 und den Client-Endpunkten (z.B. Client-Rechenknoten 502) existieren. Einige davon werden in den folgenden Abschnitten im Kontext von Netzwerkfunktionen oder Dienstvirtualisierung erörtert, einschließlich der Verwendung von virtuellen Edges und virtuellen Diensten, die für mehrere Akteure orchestriert werden.
  • Die Edge-Gateway-Knoten 512 und die Edge-Aggregationsknoten 522 arbeiten zusammen, um den Client-Rechenknoten 502 verschiedene Edge-Dienste und Sicherheit bereitzustellen. Weil jeder Client-Rechenknoten 502 stationär oder mobil sein kann, kann ferner jeder Edge-Gateway-Knoten 512 mit anderen Edge-Gateway-Vorrichtungen zusammenwirken, um gegenwärtig bereitgestellte Edge-Dienste und Sicherheit weiterzugeben, wenn sich der entsprechende Client-Rechenknoten 502 in einer Region bewegt. Dazu kann jeder der Edge-Gateway-Knoten 512 und/oder Edge-Aggregationsknoten 522 Konfigurationen mit mehreren Mandanten und mehreren Stakeholdern unterstützen, in denen Dienste von (oder gehostet für) mehreren Dienstanbietern und mehreren Konsumenten über eine einzelne oder mehrere Rechenvorrichtungen hinweg unterstützt und koordiniert werden können.
  • In verschiedenen Beispielen können die vorliegenden Techniken in Attestierungs- oder Vertrauensdomänen zwischen den Client-Rechenknoten 502, an den Edge-Gateway-Knoten 512 oder Aggregationsknoten 522 (z. B. an einem Ressourcenknoten, der eine zu attestierende Ressource aufweist) und anderen Zwischenknoten in der Edge-Cloud 110 (die z. B. Orchestrator-Funktionen, Attestierungsdienstfunktionen usw. betreiben), wie weiter unten unter Bezugnahme auf die verschiedenen Konfigurationen erörtert, die in den 7 bis 15 beschrieben sind, implementiert werden. Obwohl in vielen der folgenden Beispiele eine Bezugnahme auf eine delegierte „Verifizierer“-Entität bereitgestellt wird, kann sich der Verifizierer zusätzlich auch auf verschiedenen Ebenen des Netzwerks 520, 530, 540 befinden.
  • In weiteren Beispielen können beliebige der Rechenknoten oder -vorrichtungen, die unter Bezugnahme auf die vorliegenden Edge-Rechensysteme und -Umgebung erörtert wurden, basierend auf den Komponenten, die in 6A und 6B dargestellt sind, verwirklicht werden. Jeder Edge-Rechenknoten kann als eine Art von Vorrichtung, Gerät, Computer oder anderes „Ding“ ausgeführt sein, die/das/der zum Kommunizieren mit anderen Edge-, Vernetzungs- oder Endpunktkomponenten in der Lage ist. Zum Beispiel kann eine Edge-Rechenvorrichtung als ein Personalcomputer, ein Server, ein Smartphone, eine mobile Rechenvorrichtung, ein Smart-Gerät, ein fahrzeuginternes Rechensystem (z.B. ein Navigationssystem), eine eigenständige Vorrichtung mit einem Außengehäuse, einer Ummantelung usw. oder eine andere Vorrichtung oder ein anderes System, das in der Lage ist, die beschriebenen Funktionen durchzuführen, umgesetzt sein.
  • Im in 6A gezeigten vereinfachten Beispiel beinhaltet ein Edge-Rechenknoten 600 eine Rechen-Engine (hierin auch als „Rechenschaltungsanordnung“ bezeichnet) 602, ein Eingabe/Ausgabe(E/A)-Subsystem 608, eine Datenspeicherung 610, ein Kommunikationsschaltungsanordnungssubsystem 612 und optional eine oder mehrere Peripherievorrichtungen 614. In anderen Beispielen kann jede Rechenvorrichtung andere oder zusätzliche Komponenten umfassen, wie beispielsweise diejenigen, die in Personal- oder Server-Rechensystemen verwendet werden (z.B. eine Anzeige, Peripherievorrichtungen usw.). Zusätzlich können in einigen Beispielen eine oder mehrere der veranschaulichenden Komponenten in eine andere Komponente integriert sein oder anderweitig einen Teil davon bilden.
  • Der Rechenknoten 600 kann als eine beliebige Art von Engine, Vorrichtung oder Sammlung von Vorrichtungen ausgebildet sein, die in der Lage sind, verschiedene Rechenfunktionen durchzuführen. In manchen Beispielen kann der Rechenknoten 600 als eine einzelne Vorrichtung umgesetzt sein, wie etwa eine integrierte Schaltung, ein eingebettetes System, ein feldprogrammierbares Gate-Array (FPGA), ein System-on-a-Chip (SOC) oder ein anderes integriertes System oder eine andere integrierte Vorrichtung. In dem veranschaulichten Beispiel beinhaltet der Rechenknoten 600 einen Prozessor 604 und einen Speicher 606 oder ist als diese realisiert. Der Prozessor 604 kann als ein beliebiger Typ von Prozessor ausgebildet sein, der die hier beschriebenen Funktionen (z. B. Ausführen einer Anwendung) durchführen kann. Der Prozessor 604 kann zum Beispiel als ein oder mehrere Mehrkernprozessoren, ein Mikrocontroller, eine Verarbeitungseinheit, eine Spezial- oder Sonderverarbeitungseinheit oder ein anderer Prozessor oder eine andere Verarbeitungs-/Steuerschaltung ausgebildet sein.
  • In manchen Beispielen kann der Prozessor 604 als ein FPGA, eine anwendungsspezifische integrierte Schaltung (ASIC), eine neu konfigurierbare Hardware oder Hardwareschaltungsanordnung oder eine andere spezialisierte Hardware ausgebildet sein, diese enthalten oder an diese gekoppelt sein, um eine Durchführung der hier beschriebenen Funktionen zu ermöglichen. In manchen Beispielen kann der Prozessor 604 auch als eine spezialisierte x-Verarbeitungseinheit (XPU) ausgebildet sein, die auch als eine Datenverarbeitungseinheit (DPU), eine Infrastrukturverarbeitungseinheit (IPU) oder eine Netzwerkverarbeitungseinheit (NPU) bekannt ist. Solch eine xPU kann als eine eigenständige Schaltung oder ein eigenständiges Schaltungspaket ausgebildet, in einen SoC integriert oder mit einer Vernetzungsschaltungsanordnung (z. B. in einer SmartNIC oder einer erweiterten SmartNIC), einer Beschleunigungsschaltungsanordnung, Speichervorrichtungen oder einer KI- oder anderen spezialisierten Hardware (z. B. GPUs, programmierten FPGAs, Netzwerkverarbeitungseinheiten (NPUs), Infrastrukturverarbeitungseinheiten (IPUs), Speicherverarbeitungseinheiten (SPUs), KI-Prozessoren (APUs), einer Datenverarbeitungseinheit (DPUs) oder anderen spezialisierten Beschleunigern, wie etwa einer kryptographischen Verarbeitungseinheit/einem kryptographischen Beschleuniger) integriert sein. Eine derartige xPU kann dazu ausgelegt sein, eine Programmierung zu empfangen, um einen oder mehrere Datenströme zu verarbeiten und spezifische Aufgaben und Aktionen für die Datenströme durchzuführen (wie etwa ein Hosten von Mikrodiensten, Durchführen einer Dienstverwaltung oder - orchestrierung, Organisieren oder Verwalten einer Server- oder Rechenzentrumshardware, Verwalten von vernetzten Diensten oder Sammeln und Verteilen einer Telemetrie), außerhalb der CPU oder außerhalb einer Universalverarbeitungshardware. Es versteht sich jedoch, dass eine xPU, ein SOC, eine CPU und andere Variationen des Prozessors 604 koordiniert miteinander arbeiten können, um viele Arten von Operationen und Anweisungen innerhalb und im Auftrag des Rechenknotens 600 auszuführen.
  • Der Speicher 606 kann als ein beliebiger Typ von flüchtigem (z. B. dynamischer Direktzugriffsspeicher (DRAM) usw.) oder nichtflüchtigem Speicher oder flüchtiger oder nichtflüchtiger Datenspeicherung umgesetzt sein, der/die in der Lage ist, die hierin beschriebenen Funktionen durchzuführen. Ein flüchtiger Speicher kann ein Speichermedium sein, das Leistung zum Aufrechterhalten des Zustands von durch das Medium gespeicherten Daten benötigt. Nichtbeschränkende Beispiele für flüchtigen Speicher können verschiedene Typen von Direktzugriffsspeicher (RAM), wie etwa DRAM oder statischen Direktzugriffsspeicher (SRAM), einschließen. Ein bestimmter Typ von DRAM, der in einem Speichermodul verwendet werden kann, ist synchroner dynamischer Direktzugriffsspeicher (SDRAM).
  • In einem Beispiel ist die Speichervorrichtung eine blockadressierbare Speichervorrichtung, wie etwa jene, die auf NAND- oder NOR-Technologien basieren. Eine Speichervorrichtung kann auch eine dreidimensionale Crosspoint-Speichervorrichtung (z. B. Intel 3D XPoint™-Speicher) oder andere byteadressierbare nicht-flüchtige Write-in-Place-Speichervorrichtungen beinhalten. Die Speichervorrichtung kann sich auf den Die selbst und/oder auf ein gehäustes Speicherprodukt beziehen. In einigen Beispielen kann der 3D-Koppelpunkt-Speicher (z.B. Intel® 3D XPoint™-Speicher) eine transistorlose stapelbare Koppelpunkt-Architektur umfassen, bei der Speicherzellen am Schnittpunkt von Wortleitungen und Bitleitungen sitzen und individuell adressierbar sind, und bei der eine Bitspeicherung auf einer Änderung des Bulkwiderstands basiert. In einigen Beispielen kann der gesamte oder ein Teil des Hauptspeichers 606 in den Prozessor 604 integriert sein. Der Hauptspeicher 606 kann verschiedene Software und Daten speichern, die während des Betriebs verwendet werden, wie etwa eine oder mehrere Anwendungen, Daten, die durch die Anwendung(en) bearbeitet werden, Bibliotheken und Treiber.
  • Die Rechenschaltungsanordnung 602 ist über das E/A-Teilsystem 608 kommunikativ an andere Komponenten des Rechenknotens 600 gekoppelt, die als Schaltungsanordnung und/oder Komponenten umgesetzt sein können, um Eingabe/Ausgabe-Operationen mit der Rechenschaltungsanordnung 602 (z.B. mit dem Prozessor 604 und/oder dem Hauptspeicher 606) und anderen Komponenten der Rechenschaltungsanordnung 602 zu ermöglichen. Das E/A-Untersystem 608 kann beispielsweise als Speichersteuerungshubs, Eingabe/Ausgabe-Steuerungshubs, integrierte Sensorhubs, Firmwarevorrichtungen, Kommunikationsverbindungen (z. B. Punkt-zu-Punkt-Verknüpfungen, Busverbindungen, Drähte, Kabel, Lichtleiter, Bahnen auf gedruckten Leiterplatten usw.) und/oder andere Komponenten und Untersysteme ausgebildet sein oder diese anderweitig enthalten, um die Eingabe/Ausgabe-Operationen zu ermöglichen. In einigen Beispielen kann das E/A-Teilsystem 608 einen Abschnitt eines Ein-Chip-Systems (SoC) bilden und zusammen mit einem oder mehreren des Prozessors 604, des Hauptspeichers 606 und anderer Komponenten der Rechenschaltungsanordnung 602 in die Rechenschaltungsanordnung 602 eingebunden sein.
  • Die eine oder die mehreren veranschaulichenden Datenspeicherungsvorrichtungen 610 können als ein beliebiger Typ von Vorrichtungen ausgebildet sein, die zur kurzfristigen oder langfristigen Speicherung von Daten, wie zum Beispiel Speichervorrichtungen und Schaltungen, Speicherkarten, Festplattenlaufwerke, Festkörperlaufwerke oder andere Datenspeicherungsvorrichtungen konfiguriert sind. Jede Datenspeicherungseinrichtung 610 kann eine Systempartition beinhalten, die Daten und Firmwarecode für die Datenspeicherungseinrichtung 610 speichert. Jede Datenspeicherungsvorrichtung 610 kann auch eine oder mehrere Betriebssystempartitionen beinhalten, die Datendateien und Ausführungsprogramme für Betriebssysteme in Abhängigkeit von zum Beispiel dem Typ des Rechenknotens 600 speichern.
  • Die Kommunikationsschaltungsanordnung 612 kann als ein(e) beliebige(r) Kommunikationsschaltkreis, Vorrichtung oder Sammlung davon ausgeführt sein, der/die zum Ermöglichen von Kommunikationen über ein Netz zwischen der Rechenschaltungsanordnung 602 und einer anderen Rechenvorrichtung (z. B. einem Edge-Gateway-Knoten 512 des Edge-Rechensystems 500) in der Lage ist. Die Kommunikationsschaltungsanordnung 612 kann dazu konfiguriert sein, eine oder mehrere beliebige Kommunikationstechnologien (z. B. drahtgebundene oder drahtlose Kommunikationen) und assoziierte Protokolle (z. B. ein zellulares Networking-Protokoll, wie etwa einen 3GPP-, 4G- oder 5G-Standard, ein drahtloses lokales Netzwerkprotokoll, wie etwa IEEE 802.11/Wi-Fi®, ein drahtloses Weitverkehrsnetzwerkprotokoll, Ethernet, Bluetooth®, Bluetooth Low Energy, ein IoT-Protokoll, wie etwa IEEE 802.15.4 oder ZigBee®, LPWAN(Low-Power Wide Area Network)- oder LPWA(Low-Power Wide Area)-Protokolle usw.) zu verwenden, um eine solche Kommunikation zu bewirken.
  • Die veranschaulichende Kommunikationsschaltungsanordnung 612 beinhaltet eine Netzwerkschnittstellensteuerung (NIC) 620, die auch als eine Host-Fabric-Schnittstelle (HFI: Host Fabric Interface) bezeichnet werden kann. Die NIC 620 kann als eine oder mehrere Erweiterungskarten, Tochterkarten, Netzwerkschnittstellenkarten, Controller-Chips, Chipsätze oder andere Vorrichtungen, die von dem Rechenknoten 600 verwendet werden können, ausgeführt sein, um sich mit einer anderen Rechenvorrichtung (z.B. einem Edge-Gateway-Knoten 512) zu verbinden. In einigen Beispielen kann die NIC 620 als ein Teil eines Ein-Chip-Systems (SoC) ausgebildet sein, das einen oder mehrere Prozessoren beinhaltet, oder in einem Mehrchipgehäuse enthalten sein, das auch einen oder mehrere Prozessoren beinhaltet. In einigen Beispielen kann die NIC 620 einen lokalen Prozessor (nicht gezeigt) und/oder einen lokalen Speicher (nicht gezeigt) enthalten, die beide lokal zur NIC 620 sind. In derartigen Beispielen kann der lokale Prozessor der NIC 620 fähig sein, eine oder mehrere der Funktionen der hier beschriebenen Rechenschaltungsanordnung 602 durchzuführen. Zusätzlich oder alternativ kann der lokale Arbeitsspeicher der NIC 620 in derartigen Beispielen in eine oder mehrere Komponenten des Client-Rechenknotens auf Platinenebene, Sockelebene, Chipebene und/oder anderen Ebenen integriert sein.
  • Zusätzlich kann jeder Rechenknoten 600 in einigen Beispielen eine oder mehrere Peripherievorrichtungen 614 beinhalten. Derartige Peripherieeinrichtungen 614 können eine beliebige Art von Peripherieeinrichtung umfassen, die in einer Recheneinrichtung oder einem Server zu finden ist, wie etwa Audioeingabeeinrichtungen, eine Anzeige, andere Eingabe/Ausgabeeinrichtungen, Schnittstelleneinrichtungen und/oder andere Peripherieeinrichtungen, in Abhängigkeit von der speziellen Art des Rechenknotens 600. In weiteren Beispielen kann der Rechenknoten 600 durch einen jeweiligen Edge-Rechenknoten in einem Edge-Rechensystem (z.B. Client-Rechenknoten 502, Edge-Gateway-Knoten 512, Edge-Aggregationsknoten 522) oder ähnliche Formen von Geräten, Computern, Teilsystemen, Schaltungsanordnung oder andere Komponenten ausgeführt werden.
  • In einem ausführlicheren Beispiel veranschaulicht 6B ein Blockdiagramm eines Beispiels für Komponenten, die in einem Edge-Rechenknoten 650 zum Implementieren der hierin beschriebenen Techniken (z.B. Operationen, Prozesse, Verfahren und Methodiken) vorhanden sein können. Dieser Edge-Computing-Knoten 650 stellt eine nähere Ansicht der jeweiligen Komponenten des Knotens 600 bereit, wenn er als oder als Teil einer Rechenvorrichtung (z.B. als eine Mobilvorrichtung, eine Basisstation, ein Server, ein Gateway usw.) implementiert ist. Der Edge-Computing-Knoten 650 kann beliebige Kombinationen der oben genannten Komponenten umfassen, und er kann eine beliebige Vorrichtung umfassen, die mit einem Edge-Kommunikationsnetz oder einer Kombination solcher Netze verwendbar ist. Die Komponenten können als integrierte Schaltungen (Integrated Circuits, ICs), Teile davon, diskrete elektronische Vorrichtungen oder andere Module, Logik, Befehlssätze, programmierbare Logik oder Algorithmen, Hardware, Hardwarebeschleuniger, Software, Firmware oder eine Kombination davon, die in dem Edge-Computing-Knoten 650 angepasst sind, oder als Komponenten, die anderweitig in einem Chassis eines größeren Systems integriert sind, implementiert sein.
  • Der Edge-Rechenknoten 650 kann eine Verarbeitungsschaltungsanordnung in der Form eines Prozessors 652 beinhalten, der ein Mikroprozessor, ein Mehrkernprozessor, ein Multithread-Prozessor, ein Ultraniederspannungsprozessor, ein eingebetteter Prozessor, eine xPU/DPU/IPU/NPU, eine Spezialverarbeitungseinheit, eine spezialisierte Verarbeitungseinheit oder andere bekannte Verarbeitungselemente sein kann. Der Prozessor 652 kann ein Teil eines Ein-Chip-Systems (SoC) sein, in dem der Prozessor 652 und andere Komponenten in einer einzigen integrierten Schaltung oder einem einzigen Gehäuse gebildet sind, wie etwa die Edison™- oder Galileo™-SoC-Platinen von Intel Corporation, Santa Clara, Kalifornien. Als ein Beispiel kann der Prozessor 652 einen Intel®-Architecture-Core™-basierten Prozessor, wie etwa einen Quark™-, einen Atom™-i3-, einen i3-, einen i5-, einen i7-, einen i9- oder einen MCU-Klasse-Prozessor oder einen anderen solchen von Intel® erhältlichen Prozessor beinhalten. Jedoch kann eine beliebige Anzahl anderer Prozessoren verwendet werden, wie etwa jene, die von Advanced Micro Devices, Inc. (AMD) in Sunnyvale, Kalifornien, USA, erhältlich sind, ein MIPS-basiertes Design von MIPS Technologies, Inc. in Sunnyvale, Kalifornien, USA, ein ARM-basiertes Design, das von ARM Holdings, Ltd. oder einem Kunden davon oder deren Lizenznehmern oder Einsetzenden lizenziert ist. Die Prozessoren können Einheiten beinhalten, wie etwa einen A5-A13-Prozessor von Apple® Inc., einen SnapdragonTM-Prozessor von QualCommon® Technologies, Inc., oder einen OMAPTM-PROZESSOR von Texas Instruments, Inc. Der Prozessor 652 und die begleitende Schaltungsanordnung können in einem einzigen Sockelformfaktor, mehreren Sockelformfaktoren oder einer Vielfalt anderer Formate bereitgestellt sein, einschließlich in beschränkten Hardwarekonfigurationen oder Konfigurationen, die weniger als alle in 20 B gezeigten Elemente beinhalten.
  • Der Prozessor 652 kann über eine Verschaltung 656 (z. B. einen Bus) mit einem Systemspeicher 654 kommunizieren. Eine beliebige Anzahl von Speichervorrichtungen kann verwendet werden, um eine gegebene Menge an Systemspeicher bereitzustellen. Als Beispiele kann der Speicher Direktzugriffsspeicher (RAM) gemäß einem JEDEC-Design (JEDEC: Joint Electron Devices Engineering Council) sein, wie etwa den DDR- oder Mobil-DDDR-Standards (z.B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4). In bestimmten Beispielen kann eine Arbeitsspeicherkomponente einen von JEDEC veröffentlichten DRAM-Standard erfüllen, wie JESD79F für DDR-SDRAM, JESD79-2F für DDR2-SDRAM, JESD79-3F für DDR3-SDRAM, JESD79-4A für DDR4-SDRAM, JESD209 für Niedrigenergie-DDR (LPDDR), JESD209-2 für LPDDR2, JESD209-3 für LPDDR3 und JESD209-4 für LPDDR4. Solche Standards (und ähnliche Standards) können als DDR-basierte Standards bezeichnet werden und Kommunikationsschnittstellen der Speichervorrichtungen, die solche Standards implementieren, können als DDR-basierte Schnittstellen bezeichnet werden. In verschiedenen Ausführungen können die einzelnen Speicherbausteine aus einer beliebigen Anzahl verschiedener Gehäusetypen bestehen, wie z. B. Single Die Package (SDP), Dual Die Package (DDP) oder Quad Die Package (Q17P). In einigen Beispielen können diese Geräte direkt auf eine Hauptplatine gelötet werden, um eine Lösung mit geringerem Profil zu bieten, während in anderen Beispielen die Geräte als ein oder mehrere Speichermodule konfiguriert sind, die wiederum über einen bestimmten Anschluss mit der Hauptplatine verbunden sind. Es kann eine beliebige Anzahl von anderen Speicherimplementierungen verwendet werden, wie z. B. andere Arten von Speichermodulen, z. B. Dual-Inline-Speichermodule (DIMMs) verschiedener Sorten, einschließlich, aber nicht beschränkt auf microDIMMs oder MiniDIMMs.
  • Um eine dauerhafte Speicherung von Informationen wie Daten, Anwendungen, Betriebssystemen usw. zu ermöglichen, kann ein Massenspeicher 658 auch über die Verbindung 656 mit dem Prozessor 652 gekoppelt werden. In einem Beispiel kann der Massenspeicher 658 durch ein Solid-State-Laufwerk (SSDD) realisiert werden. Andere Vorrichtungen, die für die Speicherung 658 verwendet werden können, umfassen Flash-Speicherkarten, wie etwa SD-Karten, MicroSD-Karten, XD-Bildkarten und dergleichen und USB-Flash-Laufwerke. In einem Beispiel kann die Speichervorrichtung Folgendes sein oder beinhalten:
    • Speichervorrichtungen, die Chalkogenidglas verwenden, NAND-Flash-Speicher mit mehreren Bitebenen, NOR-Flash-Speicher, Phasenwechselspeicher mit einer oder mehreren Bitebenen (PCM), resistiven Speicher, Nanodrahtspeicher, ferroelektrischen Direktzugriffsspeicher (FeRAM), anti-ferroelektrischen Speicher, magnetoresistiven Direktzugriffsspeicher (MRAM), der Memristortechnologie beinhaltet, resistiven Speicher einschließlich Metalloxidbasis-, Sauerstoffleerstellen-Basis- und Direktzugriffsspeicher auf Basis von leitfähigen Brücken (CB-RAM), oder Spin Transfer Torque (STT)-MRAM, eine Vorrichtung auf Basis eines Spintronik-Magnetübergangsspeichers, eine Vorrichtung auf Basis von Magnettunnelübergang (MTJ), eine Vorrichtung auf Basis von DW (Domänenwand) und SOT (Spin Orbit Transfer), eine Speichervorrichtung auf Basis von Thyristoren oder eine Kombination eines oder mehrerer der oben genannten oder anderen Speicher.
  • Bei Niedrigleistungsimplementierungen kann der Datenspeicher 658 ein chipinterner Speicher oder Register sein, die dem Prozessor 652 zugeordnet sind. In manchen Beispielen kann der Datenspeicher 658 jedoch unter Verwendung eines Mikrofestplattenlaufwerks (HDD) implementiert sein. Ferner kann eine beliebige Anzahl neuer Technologien für die Speicherung 658 zusätzlich zu den, oder anstelle der, beschriebenen Technologien verwendet werden, wie etwa unter anderem Widerstandswechselspeicher, Phasenwechselspeicher, holografische Speicher oder chemische Speicher.
  • Die Komponenten können über das Interconnect 656 kommunizieren. Das Interconnect 656 kann eine beliebige Anzahl von Technologien beinhalten, einschließlich Industry Standard Architecture (ISA), extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI Express (PCIe) oder eine beliebige Anzahl anderer Technologien. Bei der Verbindung 656 kann es sich um einen proprietären Bus handeln, der beispielsweise in einem SoC-basierten System verwendet wird. Andere Bussysteme können enthalten sein, wie etwa unter anderem eine I2C-Schnittstelle, eine SPI-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Leistungsbus.
  • Die Zwischenverbindung 656 kann den Prozessor 652 mit einem Sendeempfänger 666 zur Kommunikation mit den verbundenen Edge-Vorrichtungen 662 koppeln. Der Sendeempfänger 666 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie etwa unter anderem Übertragungen auf 2,4 Gigahertz (GHz) unter dem IEEE 802.15.4-Standard unter Verwendung des Bluetooth®-Niederenergie(BLE)-Standards, wie durch die Bluetooth® Special Interest Group definiert, oder des ZigBee®-Standards. Eine beliebige Anzahl von Funkgeräten, die für ein bestimmtes Drahtloskommunikationsprotokoll konfiguriert sind, kann für die Verbindungen mit den verbundenen Edge-Vorrichtungen 662 verwendet werden. Zum Beispiel kann eine Drahtlos-Lokalnetz- (WLAN-) Einheit verwendet werden, um Wi-Fi®-Kommunikationen gemäß dem 802.11-Standard des Institute of Electrical and Electronic Engineers (IEEE) zu implementieren. Außerdem können Funkfernnetzkommunikationen, z.B. in Übereinstimmung mit einem Mobilfunk- oder anderen Funkfernnetzprotokoll über eine Funkfernnetz- (WWAN-) Einheit stattfinden.
  • Der Drahtlosnetzwerk-Sendeempfänger 666 (oder mehrere Sendeempfänger) kann unter Verwendung mehrerer Standards oder Funkgeräte für Kommunikationen in einer anderen Reichweite kommunizieren. Beispielsweise kann der Edge-Rechenknoten 650 mit nahen Vorrichtungen, z.B. innerhalb von etwa 10 Metern, unter Verwendung eines lokalen Sendeempfängers basierend auf BLE oder einem anderen Niedrigleistungsfunkgerät kommunizieren, um Leistung zu sparen. Weiter entfernte verbundene Edge-Vorrichtungen 662, z.B. innerhalb von etwa 50 Metern, können über ZigBee® oder andere Funkgeräte mit mittlerer Leistung erreicht werden. Beide Kommunikationstechniken können über ein einzelnes Funkgerät mit unterschiedlichen Leistungspegeln oder über separate Sendeempfänger erfolgen, beispielsweise einen lokalen Sendeempfänger, der BLE verwendet, und einen separaten Maschensendeempfänger, der ZigBee verwendet.
  • Ein Drahtlosnetzwerk-Sendeempfänger 666 (z.B. ein Funksendeempfänger) kann enthalten sein, um mit Vorrichtungen oder Diensten in der Edge-Cloud 690 über Lokal- oder Weitverkehrsnetzwerkprotokolle zu kommunizieren. Der Drahtlosnetzwerk-Sendeempfänger 666 kann unter anderem ein LPWA-Sendeempfänger sein, der den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt. Der Edge-Rechenknoten 650 kann über einen weiten Bereich unter Verwendung von LoRaWAN™ (Long Range Wide Area Network) kommunizieren, das von Semtech und der LoRa Alliance entwickelt wurde. Die hier beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl von anderen Cloud-Sendeempfängern verwendet werden, die Kommunikationen mit großer Reichweite, niedriger Bandbreite implementieren, wie etwa Sigfox, und anderen Technologien. Ferner können andere Kommunikationstechniken verwendet werden, wie etwa Zeitschlitz-Kanalspringen, das in der IEEE 802.15.4e-Spezifikation beschrieben ist.
  • Eine beliebige Anzahl anderer Funkkommunikationen und Protokolle kann zusätzlich zu den für den Drahtlosnetzwerk-Sendeempfänger 666 erwähnten Systemen verwendet werden, wie hier beschrieben. Der Sendeempfänger 666 kann zum Beispiel einen zellbasierten Sendeempfänger beinhalten, der Kommunikationen mit gespreiztem Spektrum (SPA/SAS-Kommunikationen) zum Umsetzen von Hochgeschwindigkeitskommunikationen verwendet. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa Wi-Fi®-Netzwerke für Mittelgeschwindigkeitskommunikationen und Bereitstellung von Netzwerkkommunikationen. Der Transceiver 666 kann Funkgeräte umfassen, die mit einer beliebigen Anzahl von 3GPP (Third Generation Partnership Project)-Spezifikationen kompatibel sind, wie etwa Long Term Evolution (LTE) und Kommunikationssysteme der 5. Generation (5G), die am Ende der vorliegenden Offenbarung ausführlicher erörtert werden. Eine Netzwerkschnittstellensteuerung (NIC) 668 kann enthalten sein, um eine drahtgebundene Kommunikation zu Knoten der Edge-Cloud 690 oder zu anderen Vorrichtungen bereitzustellen, wie etwa den angebundenen Edge-Vorrichtungen 662 (die z.B. in einem vermaschten Netz arbeiten). Die drahtgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen oder kann auf anderen Arten von Netzwerken basieren, wie etwa Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS oder PROFINET unter vielen anderen. Eine zusätzliche NIC 668 kann enthalten sein, um das Verbinden mit einem zweiten Netzwerk zu ermöglichen, wobei zum Beispiel eine erste NIC 668 Kommunikationen mit der Cloud über Ethernet bereitstellt und eine zweite NIC 668 Kommunikationen mit anderen Vorrichtungen über einen anderen Typ von Netzwerk bereitstellt.
  • Angesichts der Vielfalt von Typen anwendbarer Kommunikationen von der Vorrichtung zu einer anderen Komponente oder einem anderen Netzwerk kann eine anwendbare Kommunikationsschaltungsanordnung, die von der Vorrichtung verwendet wird, eine beliebige oder mehrere beliebige der Komponenten 664, 666, 668 oder 670 beinhalten oder durch diese ausgebildet sein. Dementsprechend können in verschiedenen Beispielen anwendbare Mittel zum Kommunizieren (z. B. Empfangen, Übertragen usw.) durch eine derartige Kommunikationsschaltungsanordnung ausgebildet sein.
  • Der Edge-Computing-Knoten 650 kann Beschleunigungsschaltungen 664 beinhalten oder mit diesen gekoppelt sein, die durch einen oder mehrere AI-Beschleuniger, einen neuronalen Computing-System-Stick, neuromorphe Hardware, ein FPGA, eine Anordnung von GPUs, eine Anordnung aus xPUs/DPUs/IPU/NPUs, einem oder mehreren SoCs, einem oder mehreren CPUs, einem oder mehreren digitalen Signalprozessoren, dedizierten ASICs oder anderen Formen spezialisierter Prozessoren oder Schaltungen, die zum Erfüllen einer oder mehrerer spezialisierter Aufgaben ausgelegt sind, verkörpert sind. Diese Aufgaben können KI-Verarbeitung (einschließlich Maschinenlern-, Trainings-, Inferenz- und Klassifizierungsoperationen), visuelle Datenverarbeitung, Netzwerkdatenverarbeitung, Objektdetektion, Regelanalyse oder dergleichen beinhalten. Dementsprechend können bei verschiedenen Beispielen anwendbare Mittel zur Beschleunigung durch eine solche Beschleunigungsschaltungsanordnung verkörpert werden.
  • Die Zwischenverbindung 656 kann den Prozessor 652 an einen Sensor-Hub oder eine externe Schnittstelle 670 koppeln, die zum Verbinden zusätzlicher Vorrichtungen oder Teilsysteme verwendet wird. Die Vorrichtungen können Sensoren 672, wie etwa Beschleunigungsmesser, Pegelsensoren, Strömungssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, Sensoren eines globalen Navigationssystems (z.B. GPS), Drucksensoren, barometrische Drucksensoren und dergleichen beinhalten. Der Hub oder die Schnittstelle 670 kann ferner verwendet werden, um den Edge-Rechenknoten 650 mit Aktoren 674, wie etwa Leistungsschaltern, Ventilantrieben, einem akustischen Tongenerator, einer visuellen Warnvorrichtung und dergleichen, zu verbinden.
  • In manchen optionalen Beispielen können verschiedene Eingabe/Ausgabe(E/A)-Vorrichtungen innerhalb des Edge-Rechenknotens 650 vorhanden sein oder mit diesem verbunden sein. Beispielsweise kann eine Anzeige oder eine andere Ausgabevorrichtung 684 enthalten sein, um Informationen, wie etwa Sensorablesungen oder Stellgliedposition, zu zeigen. Eine Eingabevorrichtung 686, wie etwa ein berührungsempfindlicher Bildschirm oder eine Tastatur, kann zum Annehmen einer Eingabe beinhaltet sein. Eine Ausgabevorrichtung 684 kann eine beliebige Anzahl von Formen einer Audio- oder visuellen Anzeige aufweisen, einschließlich einfacher visueller Ausgaben, wie etwa binärer Statusindikatoren (z.B. LEDs) und visueller Mehrzeichenausgaben, oder komplexere Ausgaben, wie etwa Anzeigebildschirme (z.B. LCD-Bildschirme), mit der Ausgabe von Zeichen, Grafiken, Multimediaobjekten, Und dergleichen, die aus dem Betrieb des Edge-Rechenknotens 650 erzeugt oder produziert werden. Eine Anzeigen- oder Konsolenhardware kann im Kontext des vorliegenden Systems verwendet werden, um eine Ausgabe bereitzustellen und eine Eingabe eines Edge-Rechensystems zu empfangen; Komponenten oder Dienste eines Edge-Rechensystems zu verwalten; einen Zustand einer Edge-Rechenkomponente oder eines Edge-Dienstes zu identifizieren; oder eine beliebige andere Anzahl von Verwaltungs- oder Administrationsfunktionen oder Dienstanwendungsfällen durchzuführen.
  • Eine Batterie 676 kann den Edge-Rechenknoten 650 mit Strom versorgen, obwohl sie in Beispielen, in denen der Edge-Rechenknoten 650 an einem festen Standort montiert ist, eine Stromversorgung aufweisen kann, die mit einem Stromnetz gekoppelt ist, oder die Batterie als Ausfallsicherheit oder für temporäre Funktionen verwendet werden kann. Die Batterie 676 kann eine Lithiumionenbatterie oder eine Metall-Luft-Batterie, wie etwa eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen, sein.
  • Ein Batterieüberwachungsgerät/-ladegerät 678 kann in dem Edge-Computing-Knoten 650 enthalten sein, um den Ladungszustand (SoCh) der Batterie 676 zu verfolgen. Die Batterieüberwachungs-/-Ladevorrichtung 678 kann verwendet werden, um andere Parameter der Batterie 676 zu überwachen, um Ausfallvorhersagen bereitzustellen, wie etwa den Gesundheitszustand (SoH) und den Funktionszustand (SOF) der Batterie 676. Die Batterieüberwachungs-/- ladevorrichtung 678 kann eine integrierte Batterieüberwachungsschaltung aufweisen, wie etwa eine LTC4020 oder eine LTC2990 von Linear Technologies, eine ADT7488A von ON Semiconductor aus Phoenix, Arizona, oder eine IC der UCD90xxx-Familie von Texas Instruments aus Dallas, TX. Die Batterieüberwachungs-/-ladevorrichtung 678 kann die Informationen über die Batterie 676 über die Verschaltung 656 an den Prozessor 652 kommunizieren. Die Batterieüberwachungs-/-ladevorrichtung 678 kann auch einen Analog-Digital-Wandler (ADC) umfassen, der es dem Prozessor 652 ermöglicht, die Spannung der Batterie 676 oder den Stromfluss von der Batterie 676 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Aktionen zu bestimmen, die der Edge-Rechenknoten 650 ausführen kann, wie etwa Übertragungsfrequenz, Mesh-Netzwerkoperation, Erfassungsfrequenz und dergleichen.
  • Ein Leistungsblock 680 oder eine andere Leistungsversorgung, die an ein Stromnetz gekoppelt ist, kann mit dem Batterieüberwachungs-/-ladegerät 678 gekoppelt werden, um die Batterie 676 zu laden. Bei einigen Beispielen kann der Leistungsblock 680 durch einen drahtlosen Leistungsempfänger ersetzt werden, um die Leistung drahtlos, zum Beispiel durch eine Schleifenantenne im Edge-Rechenknoten 650, zu erhalten. Eine Drahtlosbatterieladeschaltung, wie etwa unter anderem ein LTC4020-Chip von Linear Technologies aus Milpitas, Kalifornien, kann im Batterieüberwachungs-/-ladegerät 678 enthalten sein. Die spezifischen Ladeschaltungen können basierend auf der Größe der Batterie 676 und somit dem erforderlichen Strom ausgewählt werden. Das Aufladen kann unter anderem unter Verwendung des von der Airfuel Alliance veröffentlichten Airfuel-Standard, dem vom Wireless Power Consortium veröffentlichten Qi-Ladestandard oder dem von der Alliance for Wireless Power veröffentlichten Rezence-Ladestandard durchgeführt werden.
  • Die Speicherung 658 kann Anweisungen 682 in Form von Software-, Firmware- oder Hardwarebefehlen enthalten, um die hierin beschriebenen Techniken zu implementieren. Obwohl solche Anweisungen 682 als Codeblöcke gezeigt sind, die in dem Speicher 654 und der Speicherung 658 enthalten sind, versteht es sich, dass beliebige der Codeblöcke durch festverdrahtete Schaltungen ersetzt werden können, die zum Beispiel in einer anwendungsspezifischen integrierten Schaltung (ASIC) integriert sind.
  • Auch können in einem spezifischen Beispiel die Anweisungen 682 auf dem Prozessor 652 (separat oder in Kombination mit den Anweisungen 682 des maschinenlesbaren Mediums 660) die Ausführung oder den Betrieb einer vertrauenswürdigen Ausführungsumgebung (TEE) 695 konfigurieren. In einem Beispiel arbeitet die TEE 695 als ein geschützter Bereich, der für den Prozessor 652 zur sicheren Ausführung von Anweisungen und zum sicheren Zugriff auf Daten zugänglich ist. Verschiedene Implementierungen der TEE 695 und eines zugehörigen sicheren Bereichs im Prozessor 652 oder dem Speicher 654 können beispielsweise durch die Verwendung von Intel® Software Guard Extensions (SGX) oder ARM® TrustZone® Hardwaresicherheitserweiterungen, Intel® Management Engine (ME) oder Intel® Converged Security Manageability Engine (CSME) bereitgestellt werden. Andere Aspekte von Sicherheitshärtung, Hardware-Vertrauensankern und vertrauenswürdigen oder geschützten Operationen können im Knoten 650 durch die TEE 695 und den Prozessor 652 implementiert sein.
  • In einem Beispiel können die Anweisungen 682, die über den Speicher 654, die Datenspeicher 658 oder den Prozessor 652 bereitgestellt werden, als ein nicht transitorisches maschinenlesbares Medium 660 ausgebildet sein, das Code beinhaltet, um den Prozessor 652 anzuweisen, elektronische Operationen im Edge-Rechenknoten 650 durchzuführen. Der Prozessor 652 kann über die Zwischenverbindung 656 auf das nichttransiente maschinenlesbare Medium 660 zugreifen. Beispielsweise kann das nichtflüchtige maschinenlesbare Medium 660 von Vorrichtungen umgesetzt werden, die für die Speicherung 658 beschrieben sind, oder kann spezifische Speichereinheiten, wie etwa optische Platten, Flash-Laufwerke oder eine beliebige Anzahl anderer Hardwarevorrichtungen, beinhalten. Das nichtflüchtige, maschinenlesbare Medium 660 kann Anweisungen beinhalten, um den Prozessor 652 anzuweisen, eine spezifische Sequenz oder einen spezifischen Fluss von Aktionen durchzuführen, wie zum Beispiel mit Bezug auf das Flussdiagramm bzw. die Flussdiagramme und das Blockdiagramm bzw. die Blockdiagramme von Operationen und Funktionalität, die oben dargestellt sind, beschrieben. Wie hierin verwendet, sind die Ausdrücke „maschinenlesbares Medium“, „computerlesbares Medium“, „maschinenlesbare Speicherung“ und „computerlesbare Speicherung“ austauschbar.
  • In weiteren Beispielen beinhaltet ein maschinenlesbares Medium ein beliebiges greifbares Medium, das fähig ist, Anweisungen zur Ausführung durch eine Maschine zu speichern, zu kodieren oder auszuführen, und die bewirken, dass die Maschine eine oder mehrere der Methodiken der vorliegenden Offenbarung durchzuführen, oder das fähig ist, von solchen Anweisungen genutzte oder mit diesen verbundene Datenstrukturen zu speichern, zu kodieren oder zu tragen. Ein „maschinenlesbares Medium“ kann dementsprechend unter anderem Festkörperspeicher und optische und magnetische Medien beinhalten. Zu spezifischen Beispielen für maschinenlesbare Medien zählen nichtflüchtiger Speicher, wie zum Beispiel Halbleiterspeichervorrichtungen (z. B. elektrisch programmierbarer Nurlesespeicher (Electrically Programmable Read-Only Memory, EPROM), elektrisch löschbarer programmierbarer Nurlesespeicher (Electrically Erasable Programmable Read-Only Memory, EEPROM)) und Flash-Speichervorrichtungen, Magnetplatten, wie zum Beispiel interne Festplatten und austauschbare Speicherplatten, magnetooptische Speicherplatten und CD-ROM- und DVD-ROM-Speicherplatten. Die durch ein maschinenlesbares Medium verkörperten Anweisungen können ferner über ein Kommunikationsnetzwerk unter Verwendung eines Übertragungsmediums über eine Netzwerkschnittstelleneinrichtung übertragen oder empfangen werden, die ein beliebiges einer Anzahl von Übertragungsprotokollen (z.B. HTTP) nutzt.
  • Ein maschinenlesbares Medium kann durch eine Speichervorrichtung oder eine andere Einrichtung bereitgestellt sein, die in der Lage ist, Daten in einem nichtflüchtigen Format zu hosten. In einem Beispiel können auf einem maschinenlesbaren Medium gespeicherte oder anderweitig bereitgestellte Informationen Anweisungen repräsentieren, wie etwa Anweisungen selbst oder ein Format, aus dem die Anweisungen abgeleitet werden können. Dieses Format, aus dem die Anweisungen abgeleitet werden können, kann Quellcode, kodierte Anweisungen (z.B. in komprimierter oder verschlüsselter Form), verpackte Anweisungen (z.B. in mehrere Pakete aufgeteilt) oder dergleichen beinhalten. Die Informationen, welche die Anweisungen in dem maschinenlesbaren Medium repräsentieren, können durch eine Verarbeitungsschaltungsanordnung zu den Anweisungen verarbeitet werden, um beliebige der hier erörterten Operationen zu implementieren. Zum Beispiel kann das Ableiten der Anweisungen aus den Informationen (z.B. Verarbeiten durch die Verarbeitungsschaltungsanordnung) Folgendes beinhalten: Kompilieren (z.B. aus Quellcode, Objektcode usw.), Interpretieren, Laden, Organisieren (z.B. dynamisches oder statisches Linken), Kodieren, Dekodieren, Verschlüsseln, Entschlüsseln, Verpacken, Entpacken oder anderweitiges Manipulieren der Informationen in die Anweisungen.
  • In einem Beispiel kann das Ableiten der Anweisungen Assemblieren, Kompilieren oder Interpretieren der Informationen (z.B. durch die Verarbeitungsschaltungsanordnung) beinhalten, um die Anweisungen aus einem Zwischenformat oder einem vorverarbeiteten Format zu erzeugen, das durch das maschinenlesbare Medium bereitgestellt wird. Die Informationen können, wenn sie in mehreren Teilen bereitgestellt werden, kombiniert, entpackt und modifiziert werden, um die Anweisungen zu erzeugen. Zum Beispiel können sich die Informationen in mehreren komprimierten Quellcodepaketen (oder Objektcode oder binärer ausführbarer Code usw.) auf einem oder mehreren entfernten Servern befinden. Die Quellcodepakete können verschlüsselt sein, wenn sie über ein Netzwerk übertragen werden, und können an einer lokalen Maschine falls notwendig entschlüsselt, dekomprimiert, zusammengesetzt (z. B. verknüpft) und kompiliert oder interpretiert (z. B. in eine Bibliothek, selbständige ausführbare Datei usw.) werden und durch die lokale Maschine ausgeführt werden.
  • 6C veranschaulicht eine beispielhafte Softwareverteilungsplattform 696 zum Verteilen von Software, wie etwa der beispielhaften computerlesbaren Anweisungen 699, zu einer oder mehreren Vorrichtungen, wie etwa der/den Prozessorplattform(en) 698 und/oder den beispielhaften verbundenen Edge-Vorrichtungen 662 von 6B. Die beispielhafte Softwareverteilungsplattform 696 kann von einem beliebigen Computerserver, einer beliebigen Dateneinrichtung, einem beliebigen Cloud-Dienst usw. umgesetzt werden, der in der Lage ist, Software zu speichern und zu anderen Rechenvorrichtungen zu übertragen (z.B. Dritten, den beispielhaften verbundenen Edge-Vorrichtungen 662 von 6B). Beispielhafte verbundene Edge-Vorrichtungen können Kunden, Clients, Verwaltungsvorrichtungen (z.B. Server), Dritte (z.B. Kunden einer Entität, die die Softwareverteilungsplattform 696 besitzt und/oder betreibt) sein. Beispielhafte verbundene Edge-Vorrichtungen können in kommerziellen und/oder Heimautomatisierungsumgebungen arbeiten. In einigen Beispielen ist ein Dritter ein Entwickler, ein Verkäufer und/oder ein Lizenzgeber von Software, wie etwa der beispielhaften computerlesbaren Anweisungen 682. Die Dritten können Verbraucher, Benutzer, Einzelhändler, OEMs usw. sein, die die Software zur Verwendung und/oder zum Weiterverkauf und/oder zum Sublizenzieren erwerben und/oder lizenzieren. In manchen Beispielen bewirkt verteilte Software, dass die Anzeige einer oder mehrerer Benutzeroberflächen (UIs) und/oder grafischer Benutzeroberflächen (GUIs) die eine oder die mehreren Vorrichtungen (z. B. verbundene Edge-Vorrichtungen) geographisch und/oder logisch voneinander getrennt (z. B. physisch getrennte IoT-Vorrichtungen, beauftragt mit der Verantwortung zur Wasserverteilungssteuerung (z. B. Pumpen), Stromverteilungssteuerung (z. B. Relais) usw.) identifiziert.
  • In dem veranschaulichten Beispiel von 6C beinhaltet die Softwareverteilungsplattform 696 einen oder mehrere Server und eine oder mehrere Speicherungsvorrichtungen. Die Speicherungsvorrichtungen speichern die computerlesbaren Anweisungen 699, die den beispielhaften computerlesbaren Anweisungen 682 von 6B entsprechen können, wie oben beschrieben. Der eine oder die mehreren Server der beispielhaften Softwareverteilungsplattform 696 stehen in Kommunikation mit einem Netzwerk 697, das einem oder mehreren beliebigen des Internets und/oder beliebigen der hierin beschriebenen beispielhaften Netzwerke entsprechen kann. In einigen Beispielen reagieren der eine oder die mehreren Server auf Anforderungen, die Software als Teil einer kommerziellen Transaktion an eine anfragende Partei zu übertragen. Die Zahlung für die Lieferung, den Verkauf und/oder die Lizenz der Software kann durch den einen oder die mehreren Server der Softwareverteilungsplattform und/oder über eine Zahlungsentität eines Dritten gehandhabt werden. Die Server ermöglichen Käufern und/oder Lizenzgebern, die computerlesbaren Anweisungen 699 von der Softwareverteilungsplattform 696 herunterzuladen. Zum Beispiel kann die Software, die den beispielhaften computerlesbaren Anweisungen 682 von 6B entsprechen kann, auf die beispielhafte(n) Prozessorplattform(en) 698 (z. B. beispielhafte verbundene Edge-Vorrichtungen) heruntergeladen werden, die die computerlesbaren Anweisungen 699 ausführen sollen, um die hierin erörterten Techniken zu implementieren. In manchen Beispielen sind ein oder mehrere Server der Softwareverteilungsplattform 696 kommunikativ mit einer oder mehreren Sicherheitsdomänen und/oder Sicherheitsvorrichtungen verbunden, durch die Anforderungen und Übertragungen der beispielhaften computerlesbaren Anweisungen 699 laufen müssen. In manchen Beispielen bieten ein oder mehrere Server der Softwareverteilungsplattform 696 periodisch Aktualisierungen an der Software (z. B. die beispielhaften maschinenlesbaren Anweisungen 682 von 6B, die die gleichen wie die computerlesbaren Anweisungen 699 sein können) an, übertragen und/oder erzwingen diese, um sicherzustellen, dass Verbesserungen, Patches, Aktualisierungen usw. verteilt und auf die Software an den Endbenutzervorrichtungen angewendet werden.
  • In dem veranschaulichten Beispiel von 6C sind die computerlesbaren Anweisungen 699 auf Speicherungsvorrichtungen der Softwareverteilungsplattform 696 in einem bestimmten Format gespeichert. Ein Format von computerlesbaren Anweisungen beinhaltet unter anderem eine spezielle Codesprache (z. B. Java, JavaScript, Python, C, C#, SQL, HTML usw.) und/oder einen speziellen Codezustand (z. B. unkompilierter Code (z. B. ASCII), interpretierter Code, verknüpfter Code, ausführbarer Code (z. B. ein Binärobjekt) usw.). In manchen Beispielen befinden sich die computerlesbaren Anweisungen 699, die in der Softwareverteilungsplattform 696 gespeichert sind, in einem ersten Format, wenn sie an die beispielhafte(n) Prozessorplattform(en) 696 übertragen werden. In manchen Beispielen ist das erste Format ein ausführbares Binärobjekt, in dem bestimmte Arten der Prozessorplattform(en) 698 ausgeführt werden können. In manchen Beispielen ist das erste Format jedoch unkompilierter Code, der eine oder mehrere Vorbereitungsaufgaben erfordert, um das erste Format in ein zweites Format zu transformieren, um eine Ausführung auf der (den) beispielhaften Prozessorplattform(en) 698 zu ermöglichen. Beispielsweise müssen die empfangende(n) Prozessorplattform(en) 698 die computerlesbaren Anweisungen 699 in dem ersten Format kompilieren, um ausführbaren Code in einem zweiten Format zu erzeugen, der in der Lage ist, auf der (den) Prozessorplattform(en) 698 ausgeführt zu werden. In noch anderen Beispielen ist das erste Format interpretierter Code, der beim Erreichen der Prozessorplattform(en) 698 durch einen Interpreter interpretiert wird, um die Ausführung von Anweisungen zu ermöglichen.
  • Jedes der Blockdiagramme aus 6A bis 6C soll eine Ansicht auf hoher Ebene von Komponenten einer Vorrichtung, eines Teilsystems oder einer Anordnung eines Edge-Computing-Knotens und -Systems darstellen. Es wird jedoch klar sein, dass einige der gezeigten Komponenten weggelassen werden können, zusätzliche Komponenten vorhanden sein können und eine andere Anordnung der gezeigten Komponenten in anderen Implementierungen stattfinden kann.
  • Rollendelegierung für Attestierungsverifizierer
  • Im Kontext einer eingesetzten Vorrichtung (wie etwa der/die oder die in 5 dargestellten Edge-Rechenknoten oder -Vorrichtungen) stellen die vorliegenden Techniken und Konfigurationen die Rahmenbedingungen für verteilte Attestierungsfunktionen und das Delegieren einer Verifiziererrolle zur Attestierung bereit.
  • Die Komponentenauthentifizierung mittels Attestierung ist ein typisches Verfahren zum Validieren der Identität einer Entität in einer Plattform, die eine strikte Durchsetzung eines Identitätsnachweises erfordert. In einem Attestierungsmodell sendet der Verifizierer eine Challenge an den Attestor und empfängt als Reaktion darauf eine Zertifikatskette - oder Sammlung von Zertifikaten - vom Attestor. Der Attestor berechnet die Antwort mit eindeutigem Kryptogeheimnis (üblicherweise durch einen privaten Schlüssel oder einen Alias-Schlüssel abgeleitet) und sendet dann die Antwort zurück an den Verifizierer.
  • Die Attestierungsverifizierung wird in fast allen vertrauenswürdigen Rechenumgebungen verwendet, um die Glaubwürdigkeit und Vertrauenswürdigkeit der Attestierungsumgebung festzustellen. Beispielsweise implementieren Intel® SGX, SPDM (Security Protocol and Data Model) von DMTF, DICE (Device Identity Composition Engine) von TCG und TPM-Technologie jeweils Attestierungsmechanismen.
  • Typischerweise ist der Verifizierer in dem Attestierungsmodell entweder eine zentrale Entität (wie etwa ein Cloud-Dienst) oder ein Edge-Orchestrator, der für die Attestierung nachgelagerter Entitäten verantwortlich ist. Attestierer können auch statisch in verschiedenen Schichten eines Edge- oder IoT-Netzwerks verteilt sein, wobei jeder nachgelagerte Knoten für die Attestierung anderer Downstream-Entitäten verantwortlich ist.
  • Als ein Beispiel zeigt 7 eine zentrale Attestierungsverifiziererarchitektur, bei der ein Attestierungsverifizierer 710 Informationen an eine Vielzahl von Attestierungsknoten 720 verteilt. Die Verwendung einer zentralen Attestierungsverifiziererarchitektur stellt jedoch Skalierbarkeitsherausforderungen bereit, die mit zwei Nachteilen verbunden sind.
  • Erstens weist die Arbeitslast des zentralen Verifizierers 710, der eine Attestierung durchführt, ein kaskadiertes Rückstandsverhalten auf, während die Anzahl von Knoten 720 in dem Netzwerk erhöht wird. Der Rückstand verursacht Verzögerungen oder Timeouts, wenn mehr nachgelagerte Knoten für das Netzwerk bereitgestellt werden. Dies ist besonders kritisch bei IoT- und Edge-Computing, bei dem viele Knoten häufig in das Netzwerk eintreten (und es wieder verlassen) können.
  • Zweitens birgt das zentrale Verifizierungsmodell auch eine Bedrohung für die Privatsphäre. Die Verwendung eines zentralen Verifizierers 710 kann zur Extraktion von privatsphärensensitiven Kundendaten führen, einschließlich Graphendaten, die die Dichteverteilungskarten verschiedener Kundenarbeitslasten angeben, und vorrichtungsspezifischer Informationen, die aus dem gesammelten Attestierungsbeweis verfügbar sind.
  • Nachfolgend wird ein Mechanismus zur Verteilung der Verifiziererfunktion in nachgelagerte Entitäten durch Zuweisen der Verifiziererrolle zu anderen Entitäten im Netzwerk vorgeschlagen. Dieser Mechanismus wendet den Attestierungsprozess rekursiv als eine Möglichkeit an, Vertrauen in alternativen Knoten vor dem Zuweisen der Verifiziererrolle zu evaluieren. Zusätzlich dazu kann der neue Verifizierer periodische Neuattestierungen und Prüfungen durch seine Peers und durch seinen Endorser/Hersteller unterzogen werden.
  • Im Gegensatz zu dem folgenden Mechanismus für verteilte Verifizierer sehen sich herkömmliche Attestierungs- und Sicherheitsansätze Skalierbarkeits- oder Datenschutzproblemen gegenübergestellt. Beispielsweise wissen Netzwerkorchestratoren, Router oder andere Operationsknoten der Netzwerksteuerung nicht, wie sie einen lokalen Verifizierer einer komplexen Vorrichtung bereitstellen und eine Genehmigung erteilen sollen, dass dieser als ein Verifizierer fungiert (mit entsprechenden Einschränkungen, dass nur lokalen Attestierer bedient werden). Zusätzlich weisen komplexe Vorrichtungsarchitekturen, einschließlich solcher mit mehreren Vertrauensankern auf derselben Vorrichtung, keinen Mechanismus zum Delegieren einer Verifiziererrolle an DICE-Schichten oder Teilkomponenten einer komplexen Vorrichtung auf.
  • 8 zeigt ein Systemdiagramm einer Konfiguration eines verteilten Attestierungsverifizierers. Das System kann mehrere Knoten in einem Netzwerk oder verteiltem System aufweisen, wie etwa ein Cloud-, Edge-, IoT- oder Enterprise-Netzwerk. In diesem Diagramm übernimmt Knoten 1 810 die Rolle des führenden Attestierungsverifizierers. Mit einem Verifiziererdelegierungsverfahren kann der Knoten 1 810 einen anderen Knoten dynamisch attestieren und bewerten und zum Beispiel die Verifiziererrolle an den Knoten 2 820 delegieren. Der Knoten 2 820 wird lokale Attestierungsarbeitslasten für seine nachgelagerten Knoten (in der Domäne 821) unter Verwendung einer Bewertungsrichtlinie handhaben, die durch den führenden Attestierungsverifizierer 810 übermittelt wird. Die lokale Attestierung unter Knoten 2 820 (innerhalb der Domäne 821) wird dann vor dem führenden Attestierungsverifizierer 810 verborgen, um die Belastung des führenden Attestierungsverifizierers 810 zu reduzieren. Gleichermaßen ist die lokale Attestierung unter Knoten 3 830 (innerhalb der Domäne 831) vor dem führenden Attestierungsverifizierer 810 verborgen.
  • Die Attestierungsfunktionalität und die Rollen eines Attestierers, Endorser, Verifizierers, Verifizierer-Eigentümers, vertrauenden Partei in den unterschiedlichen Attestierungsszenarien ist im Allgemeinen in 9a bis 9E beschrieben. Eine Attestierungsarchitektur weist mehrere Rollen auf, und jede arbeitet jeweils bei der Durchführung der verschiedenen Rollen mit den anderen zusammen, um Attestierungsergebnisse zu erzielen, die eine vertrauende Partei (wie etwa eine Anwendung oder einen anderen Netzwerkknoten) über das Ergebnis der Sicherheitsrisikobewertung informiert.
  • 9a veranschaulicht ein Hintergrundprüfmodell zur Attestierung, wobei ein Attestierer 911 einem Verifizierer 913 über eine vertrauende Partei 912 einen Attestierungsbeweis bereitstellt (Operation (A)). Der Verifizierer 913 stellt die Attestierungsergebnisse für die vertrauende Partei 912 bereit (Operation (B)), die dann eine Korrektur mit dem Attestierer 911 durchführt (Operation (C)).
  • 9b stellt eine Veranschaulichung eines Mehrparteien-Hintergrundprüfmodells zur Attestierung bereit, wobei ein Attestierer 921 einen Beweis für eine vertrauende Partei 922 bereitstellt (Operation (A)), die dann den Beweis an einen Verifizierer 924 kommuniziert (Operation (A)). Der Verifizierer 924 stellt die Attestierungsergebnisse für die vertrauende Partei 922 bereit (Operation (B)), die dann die Attestierungsergebnisse bereitstellt und eine erste Korrektur mit dem Attestierer 921 durchführt (Operation (C)). Zusätzlich stellt der Attestierer 921 die Attestierungsergebnisse für eine vertrauende Partei 923 bereit (Operation (D)), die auch eine zweite Korrektur mit dem Attestierer 921 durchführt (Operation (E)).
  • 9c stellt eine Veranschaulichung eines Passport-Modells zur Attestierung bereit, wobei ein Attestierer 931 einen Beweis für einen Verifizierer 933 bereitstellt (Operation (A)), der dann die Attestierungsergebnisse an eine vertrauende Partei 932 kommuniziert (Operation (B)). Die vertrauende Partei 932 führt dann eine Korrektur mit dem Attestierer 931 durch (Operation (C)).
  • 9D stellt eine Veranschaulichung eines Endorser-Eigentümermodells zur Attestierung bereit, und 9E stellt eine Veranschaulichung der Verwendung des Endorser-Eigentümermodells in einem Satz von Computersystemen bereit. Insbesondere verdeutlichen diese Zeichnungen, wie ein Endorser 941 (z. B. eine Lieferkettenentität 951) Endorsements (z. B. Endorsement-Informationen oder Endorsement-Daten, die über strukturierte Daten bereitgestellt werden) übermittelt, und wie ein Verifizierer-Eigentümer 942 (z. B. eine Verwaltungskonsole 952) eine Bewertungsrichtlinie (z. B. eine Datenstruktur oder eine ähnliche definierte Darstellung von Bewertungsmerkmalen) als Beweis an einen Verifizierer 945 (z. B. einen Attestierungsdienstanbieter 955) übermittelt. Der Attestierer 944 (z. B. die Vorrichtung 954) übermittelt einen Beweis an den Verifizierer 945 zur Bewertung gemäß dieser Bewertungsrichtlinie und den Endorsements.
  • Der Verifizierer 945 übermittelt die Attestierungsergebnisse an eine vertrauende Partei 946 (z. B. einen Ressourcenmanager 956), und ein Eigentümer einer vertrauenden Partei 943 (z. B. eine Verwaltungskonsole 953) übermittelt eine Bewertungsrichtlinie für die Attestierungsergebnisse an die vertrauende Partei 946. Dementsprechend kann die vertrauende Partei 946 eine Bewertung der Attestierungsergebnisse in Übereinstimmung mit der Attestierungsrichtlinie durchführen.
  • Die Verifiziererrolle in diesen und anderen Attestierungsmodellen ist Gegenstand der folgenden Techniken. Wie zu verstehen ist, muss der Verifizierer möglicherweise mehrere Funktionen oder Unterfunktionen von Attestierungsvorgängen behandeln, die jeweils Skalierbarkeitsherausforderungen sind. Eine Funktion ist das Kodieren und Dekodieren der verschiedenen Attestierungsnachrichtenarten (z. B. Beweis, Endorsements, Attestierungsergebnisse und -Richtlinien, die mittels verschiedener Datennachrichten ausgetauscht werden), die in diesen und anderen Attestierungsszenarien kommuniziert werden. Solche Attestierungsdaten oder den Attestierungsoperationen zugeordnete Informationen können gemäß einer Vielfalt von computerlesbaren Formaten definiert werden und können einer Validierung oder Verifizierung, Änderungen oder Transformationen usw. unterzogen werden. Mit den folgenden Attestierungsdelegierungsansätzen kann das Hochskalieren und Herunterskalieren von Attestierungsoperationen in einem Netzwerk möglich sein und eine Vielzahl von technischen Vorteilen bereitstellen.
  • 10 stellt einen Satz von Attestierern 1011 (1011A-1011C), Endorsern 1021 (1021A-1021C) und Eigentümern (Verifizierer-Eigentümer 1072, Eigentümer einer vertrauenden Partei 1082) dar, die Nachrichten (z. B. Kommunikationen mit einer definierten Struktur) mit mehreren Kodierungsformaten und Datenmodellen zur Verwendung mit einer Verifiziererarchitektur liefern können. Insbesondere zeigt dieses Diagramm, wie die Verifiziererarchitektur die Kodierungs- und Dekodierungsfunktionen partitionieren kann, sodass mehrere Kodierungsformate und Datenstrukturdefinitionen durch einen einzigen Verifiziererknoten 1031 unterstützt werden können, der Attestierungsergebnisse für eine vertrauende Partei 1081 bereitstellt. Obwohl separate Entitäten in 10 und begleitende Figuren gezeigt werden, versteht es sich, dass die Verifiziererarchitektur durch jeweilige Rechenknoten, Rechenschaltungen, Rechenkomponenten, Rechenvorrichtungen oder Rechenentitäten innerhalb derselben, unterschiedlichen oder verteilten Systemanordnungen bereitgestellt werden kann.
  • 10 zeigt ferner die internen Komponentenanordnungen des einzelnen Verifiziererknotens 1031. Verifizierer können mit einer Vielzahl unterschiedlicher Attestierungssysteme interagieren, wobei zugehörige Informationen gemäß der Gestaltung der unterstützten Anwendungen und Standards unterschiedlich kodiert werden. Infolgedessen werden verschiedene Kodier-/Dekodierfunktionen benötigt. 10 zeigt insbesondere einige beispielhafte Kodierungen (CBOR Web Token (CWT), JSON Web Token (JWT) usw.), die von Dekodierern (einschließlich der Dekodierer 1041, 1071 und des Kodierers 1061) verwendet werden, aber es sind auch andere Kodierungen möglich.
  • Innerhalb des Verifiziererknotens 1031 befindet sich eine Bewertungsfunktion 1051, die die Beweise und die Endorsements bewertet, um zu einem Attestierungsergebnis zu gelangen. Die Bewertungsfunktion kann aus dem Erstellen einer internen Darstellung von Beweisen bestehen, wobei verschiedene Teilkomponenten einer attestierten Vorrichtung (ausführlicher unter Bezugnahme auf 12 unten beschrieben) in den Beweisen und in den Endorsements dargestellt werden können.
  • Selbst in diesem Zusammenhang kann ein Verifiziererknoten 1031 beschränkte Ressourcen zum Unterstützen vieler unterschiedlicher Nachrichtenkodierungsformate aufweisen. Folglich kann ein Netzwerkbetreiber mehrere Verifiziererknoten zum Lastausgleich basierend auf einer Partitionierung von Kodierungsformaten bereitstellen. Der Verifizierer A kann zum Beispiel JWT-kodierte Nachrichten handhaben, während der Verifizierer B CWT-kodierte Nachrichten handhaben kann.
  • Die Verifiziererskalierbarkeit wird auch durch die Funktionalität des Bewerters 1051 beeinflusst. Das Abgeben von Bewertungsfunktionen kann ein anderes Verfahren sein, das eine Beendigung einer Attestierungsverifizierung gerechtfertigt hat. Dementsprechend wird in einem Beispiel ein Verifiziererdelegierter erzeugt, der einen Teil der Bewertungsarbeitslast akzeptiert. Dies kann durch eine interne Darstellung von Attestierungsinformationen, zum Beispiel Concise Binary Object Representation (CBOR), verbessert werden, die unter allen internen Verifiziererfunktionen üblich ist. Darüber hinaus ist dies bei allen Verifiziererdelegiertern im Zuge der Minimierung des Kodier-/Dekodieraufwands üblich, während die Datenserialisierung und der netzwerkübergreifende Schutz weiterhin unterstützt werden.
  • 11 zeigt einen Attestierungsrollen-Delegierungsprozess, der nachfolgend ausführlicher beschrieben wird. Diese und andere „Attestierungsdelegierungs“-Operationen können als elektronische Operationen (z. B. Schritte, Funktionen, Prozeduren, Logik, Automationen usw.) in einem Computersystem, einer Vorrichtung oder einem Knoten implementiert werden, wie hierin erörtert. Als ein erster Schritt des Delegierens wird die Attestierung rekursiv angewendet, um eine Grundlage für das Vertrauen in den Verifiziererdelegierten zu schaffen. Bei der rekursiven Anwendung der Attestierung werden die Attestierungsrollen von jedem Knoten durchgeführt, wobei der voraussichtliche Delegierte die Attestiererrolle durchführt und der Verifizierer als ein Verifizierer fortfährt. Ein voraussichtlicher Delegierter kann jedoch auch eine Rolle einer vertrauenden Partei implementieren, bei der die Entscheidung, den voraussichtlichen Delegierten zu akzeptieren oder abzulehnen, eine Entscheidung des Delegators ist (wie ausführlicher in 13 unten gezeigt).
  • Vor dem Attestierungsprozess attestiert der Verifizierer 1111 die Authentizität des Attestierers 1121, der einen Beweis für den Verifizierer bereitstellen muss und die Attestierungs-Challenge erfolgreich bewerten muss (Bewertungsoperationen 1130). Der Attestierer sammelt Vertrauenswürdigkeitsbehauptungen über sich selbst, indem er die Software und andere Konfiguration oder Einstellungen misst, die im Vergleich zu einer vorherigen Attestierung einer Änderung unterzogen wurden. Der Attestierer stellt sowohl ein ordnungsgemäßes Zertifikat bereit, das seine Vorrichtungsidentität bestätigt, als auch einen Beweis, der durch den privaten Zertifikatsschlüssel signiert ist. Der Verifizierer kann eine Nonce- oder andere Aktualitäts-Challenge liefern, die dem Beweis beigelegt werden soll.
  • Falls die Bewertung des Verifizierers erfolgreich ist, akzeptiert der Verifizierer eine Richtlinie des Orchestrators oder von einer anderen Netzwerkoperationsquelle, die eine Delegierung der Attestierungsverifiziererrolle an eine andere Vorrichtung (z. B. der Attestierer 1121) autorisiert.
  • Nach einer erfolgreichen Attestierungsbewertung kann der Attestierer als ein neuer Verifizierer in dem System anerkannt werden (Endorsee-Operationen 1140). Er kann autorisiert sein, die Rolle des Attestierungsverifizierers für einige oder alle der ihm nachgelagerten Vorrichtungen durchzuführen, wie in 12 gezeigt. Zusätzlich oder alternativ dazu kann er autorisiert sein, eine lokale Attestierungsverifizierung für eine komplexe Vorrichtung durchzuführen, die mehrere lokale Attestierer beinhaltet und einen Bericht über die Zusammensetzung lokaler Komponenten erzeugen, der in Reaktion auf eine Attestierungs-Challenge an einen entfernten Verifizierer übermittelt wird.
  • Der neue Knoten kann autorisiert sein, ferner Berechtigungen für Attestierungsrollen für andere Attestieren, die dem Netzwerk beitreten/erneut beitreten/bereits beigetreten sind, zu gewähren. Der ursprüngliche Verifizierungs-Endorser kann den Verifizierungs-Endorser (gezeigt in den Endorsee-Operationen 1140) periodisch prüfen, um sicherzustellen, dass dieser funktioniert und nicht kompromittiert ist. Falls ein Endorsee nicht auf die Prüfung reagiert, werden alle nachgelagerten Knoten als nicht vertrauenswürdig eingestuft und auf eine Ausschlussliste gesetzt. Dieses Ereignis kann an alle vorgelagerte Knoten gesendet werden, um die Ausschlussliste zu benachrichtigen/zu aktualisieren, wie etwa wenn Verkehr von den Knoten in der Ausschlussliste nicht vertrauenswürdig ist.
  • 12 zeigt eine Verifizierungsdelegierung in einem komplexen Vorrichtungsnetz dar. In diesem Beispiel richten Elemente eines Root-Complex (RC) 1210, eines Management Component Transport Protocol (MCTP) 1220, eines Platform Controller Hub (PCH) 1230 und eines feldprogrammierbaren Gate-Arrays (FPGA) 1240 vier separate Domänen ein, von denen jede ihren eigenen Vertrauensanker besitzt (z. B. der RC-Attestierungsverifizierer 1212, der MCTP-Bus-Master 1222, der PCH-Attestierungsverifizierer 1232, der FPGA-RoT 1242) und ein Attestierer für die anderen sein kann. In diesem Beispiel dient der Root-Complex 1210 als der führende Attestierungsverifizierer. Der Root-Complex 1210 attestiert und bewertet den Attestierer (zum Beispiel den MCTP-Bus-Master 1222) und delegiert, falls erfolgreich, die Verifiziererrolle an den MCTP-Bus-Master. An diesem Punkt erfolgt eine Delegierung an den MCTP-Bus-Master 1222 als Verifiziererrolle, um eine lokale Attestierung an alle MCTP-Endpunkte unter Verwendung eines Sicherheitsprotokoll- und Datenmodell (SPDM)-Protokolls durchzuführen und Graphendaten der Attestierung vor dem führenden Attestierungsverifizierer (z. B. dem Root-Complex 1210 in diesem Beispiel) zu verbergen.
  • 13 bildet ferner eine Attestierungsrollenarchitektur ab, wobei ein Verifiziererknoten 1031 einen Delegator 1391 zur Abgabe von Bewertungsfunktionen enthält. Diese Figur beinhaltet Elemente ähnlich jenen, die in 10 beschrieben sind, aber auch zusätzliche Merkmale, die zu dem Verifiziererknoten 1031 (einer Delegator-Funktion 1391) hinzugefügt werden, um Bewertungsfunktionen an einen entfernten (delegierten) Verifizierer-/Bewertungsknoten 1392 abzugeben. Das Abgeben fügt nur einen minimalen Mehraufwand für das Kodieren von Attestierungsinformationen hinzu, die den Beweis, das Endorsement und die Richtlinie beinhalten können. Die interne (gegenüber dem Verifizierer) Darstellung, hier als CBOR gezeigt, ermöglicht es dem Delegierten, Bewertungen unter Verwendung der internen Kodierung zu verarbeiten, und kann von Bewertungsarbeitslasten in einer Vorstufe profitieren. Beispielsweise kann der führende Bewerter 1051 eine logische Vorrichtungskarte aus Beweisen erstellen und eine andere aus Endorsements, und dann die zwei Karten für einen effizienten Kartendurchlauf in Beziehung setzen.
  • 14 zeigt rekursive Attestierungsbeispiele, die mit den vorstehend erörterten Attestierungsansätzen übereinstimmen. Die rekursive Attestierung ist eine Möglichkeit, um Vertrauen zu einem voraussichtlichen Verifiziererdelegierten zu schaffen, wobei die Attestierung als Teil der „Eingliederung“ des Delegierten verwendet wird und wobei der Delegierte die Rolle des Attestierer übernimmt, der Verifizierer die Rolle des Verifizierers beibehält und die Delegatorfunktion des Verifizierers die Rolle der vertrauenden Partei ausübt.
  • Zur kurzen Erläuterung der in 14 gezeigten Schritte:
    • (1) der Verifiziererdelegierte 1492 als Attestierer 1490 liefert den Beweis über den Netzwerkknoten und die Umgebung, die die Funktion des Verifiziererdelegierten 1492 implementiert.
    • (2) der Bewerter 1451 als Verifizierer 1441 (der im Wesentlichen in derselben Rolle innerhalb des Verifiziererknotens 1431 arbeitet) führt eine lokale Bewertung durch, um ein Attestierungsergebnis zu erzeugen.
    • (3a) der Delegator 1491 als eine lokale vertrauende Partei 1481 bewertet die Attestierungsergebnisse (unter der Annahme, dass der Attestierer 1490 bezüglich der Arbeitslasten des Verifiziererdelegierten 1492 vertrauenswürdig ist) und autorisiert den Delegator 1491, die Arbeitslasten des Bewerters 1451 bezüglich des Verifiziererdelegierten 1492 bei zukünftigen Lastausgleichsentscheidungen zu planen.
    • (3b) Der Attestierer 1490 wird über das Attestierungsergebnis und die Entscheidung darüber benachrichtigt, den voraussichtlichen Verifiziererdelegierten 1492 zu verwenden (oder nicht). Damit ist die Delegierung abgeschlossen. Anschließende zusätzliche Abläufe können erforderlich sein, um den Verifiziererdelegierten 1492 für den Normalbetrieb zu konfigurieren, wie etwa das Bereitstellen von Schlüsseln, Vertrauensankern, Richtlinien zum Austauschen von Bewertungsarbeitslasten und Richtlinien zum Formatieren und Auswerten von Arbeitslasten.
  • In weiteren Beispielen sind die hier erörterten Attestierungsdelegierungstechniken auf ein zusammengesetztes Vorrichtungsmuster anwendbar und können auf verschiedene Formen von delegierten Verifizierungsarbeitslasten anwendbar sein. Beispielsweise sei ein Szenario für eine zusammengesetzte Vorrichtung betrachtet, bei dem Verifiziererdelegierte jedem der Attestierer A, B, C usw. zugewiesen werden, und wobei der Delegierte A auch als Workload Scheduler für B, C usw. dient. Ein relevanter Anwendungsfall ist ein lokaler Verifizierungsdelegierter, bei dem ein aktiver Plattform-Vertrauensanker (PaRoT) auf der lokalen Maschine vorhanden ist, der normalerweise alle Verifizierungen für lokale Komponenten durchführt. Dies kann erweitert werden, sodass das Vorrichtungsmuster den führenden Verifizierer darüber informieren kann, wie lokale Verifizierungsarbeitslasten partitioniert werden sollen. Hierbei wird einem lokalen Delegierter erst dann vertraut, wenn er selbst eine Attestierungsprüfung erfolgreich bestanden hat. Die erste Verifizierung könnte entfernt erfolgen, dann könnte der lokal vertrauenswürdige Knoten ein Verifizierungsdelegierter für einen anderen lokalen Attestierungsknoten werden, bis alle Knoten verifiziert sind. Im Anschluss könnten nachfolgende Verifizierungen lokal durchgeführt werden, wobei zu beachten ist, keine lokale Neuattestierung auf dem Knoten zu planen, der gleichzeitig ein lokaler Verifizierungsdelegierter ist. Dieser Ansatz würde eine Skalierbarkeit innerhalb der lokalen Vorrichtung für Zeiten ermöglichen, in denen die externe Konnektivität beschränkt ist.
  • Diese Attestierungsdelegierungskonzepte können auf netzwerkverbundene Verifizierungsdelegierte erweitert werden, wobei ein beliebiger einzelner verifizierter Knoten anfänglich der führende Verifizierer/Scheduler sein kann und dann das Verfahren des vorherigen Absatzes zum Bootstrappen anderer Knoten in Verifiziererdelegierte (oder eine Unterkomponente eines Knotens, der die Knotenattestierungsprüfung abgeschlossen hat) anwendet. Dies ermöglicht einen GOSSIP-Ansatz zur Delegierung der Verifiziererrolle. Solche Konzepte können auch erweitert werden, um vertrauenswürdige Ausführungsdomänen (z. B. Intel Software Guard Extensions (SGX) und Trusted Domain Extensions (TDX)-Domänen) als Delegierte zu verwenden, nachdem ihre Attestierungsverifizierung erfolgreich war. Somit könnte eine TDX-Domäne, die über TDX/IO mit einer DICEbasierten Vorrichtung verbunden ist, ein Verifizierungsdelegierter für andere lokale Komponenten werden.
  • 15 veranschaulicht ein Flussdiagramm eines Verfahrens zum Durchführen von Attestierungsdelegierungsoperationen gemäß einem Beispiel. Obwohl dieses Flussdiagramm aus der Perspektive der Verifiziererentität (Verifiziererknoten) bereitgestellt wird, können entsprechende Operationen durch den Verifizierer implementiert werden. Dieses Verfahren kann durch Folgendes implementiert werden: eine Rechenvorrichtung, die eine Verarbeitungsschaltungsanordnung und eine Speichervorrichtung mit darauf ausgeführten Anweisungen umfasst, wobei die Anweisungen durch die Verarbeitungsschaltungsanordnung ausgeführt werden, um die Attestierungsdelegierungsoperationen durchzuführen. Dieses Verfahren kann durch ein nichtflüchtiges vorrichtungslesbares Speichermedium, das Anweisungen enthält, implementiert werden, wobei die Anweisungen bei Ausführung durch eine Verarbeitungsschaltungsanordnung einer Vorrichtung die Verarbeitungsschaltungsanordnung veranlassen, Attestierungsoperationen durchzuführen. Dieses Verfahren kann auch durch mehrere Operationen implementiert werden, die mit einem Prozessor und einem Speicher einer Vorrichtung ausgeführt werden, um Attestierungsdelegierungsoperationen durchzuführen. Dieses Verfahren kann auch durch eine Vorrichtung implementiert werden, die jeweilige Mittel zum Durchführen der folgenden Attestierungsdelegierungsoperationen umfasst. In einem spezifischen Beispiel ist die Vorrichtung oder Einrichtung ein Knoten, der in einem Internet-der-Dinge (IoT)-Rechensystem (oder IoT-Netzwerk) oder in einem Edge-Rechennetzwerk betrieben wird.
  • Die Operation 1502 ist eine optionale Operation (Voraussetzung), um ein Vertrauen zu einer Verifizierungsdelegierer-Entität herzustellen. Diese Operation kann auf die rekursive Attestierung folgen, um das Vertrauen der Verifizierungsdelegierer-Entität herzustellen, wie etwa unter Bezugnahme auf 14 erörtert. In einem spezifischen Beispiel beinhaltet Operation 1502 Teilschritte (Teiloperationen) zum: Erhalten eines Attestierungsbeweises von der Delegiererentität (Operation 1512), Erhalten von Attestierungsergebnissen aus der Bewertung des Attestierungsbeweises (Operation 1514), Durchführen einer Delegierungsentscheidung basierend auf dem bereitgestellten Attestierungsbeweis und den Attestierungsergebnissen (Operation 1516) und Kommunizieren der Ergebnisse der Delegierungsentscheidung an die Verifiziererentität (Operation 1518).
  • Beim Herstellen von Vertrauen zu der Verifizierungsdelegierer-Entität beziehen sich die folgenden Operationen 1504-1508 auf Operationen, die durch eine Verifizierentität-Rechenvorrichtung (z. B. ein führender Attestierungsverifizierer) durchgeführt werden, die es einem Delegierten (z. B. ein erweiterter Attestierungsverifizierer, der als ein Verifizierer-Endorsee konfiguriert ist) ermöglichen, eine Attestierung einer bestimmten externen Entität durchzuführen. In einem Beispiel ist die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung und die Verifiziererentität-Rechenvorrichtung und die andere Rechenvorrichtung sind kommunikativ über ein Netzwerk oder einen Bus gekoppelt oder kommunizieren anderweitig über dieses. In einem anderen Beispiel ist der führende Attestierungsverifizierer ein Root-Complex, der in Hardware der Rechenvorrichtung implementiert ist, und die Verifizierungsdelegierer-Entität ist eine andere Entität, die in der Hardware der Rechenvorrichtung implementiert ist.
  • Die Operation 1504 ist eine Operation zum Erhalten von Endorsement-Informationen zur Attestierung der externen Entität. In einem Beispiel werden solche Endorsement-Informationen von Endorser-Entitäten in einem oder mehreren kodierten Formaten bereitgestellt oder stammen von diesen, und die Endorsement-Informationen werden in ein gemeinsames Format zur Bewertung dekodiert.
  • Die Operation 1506 ist eine Operation zum Erhalten einer Bewertungsrichtlinie, wobei die Bewertungsrichtlinie zur Bewertung eines Attestierungsbeweises für die Attestierung der externen Entität definiert ist. In einem Beispiel wird eine solche Bewertungsrichtlinie von einer Verifizierer-Eigentümerentität in einem oder mehreren kodierten Formaten bereitgestellt, und die Bewertungsrichtlinie wird in ein gemeinsames Format zur Bewertung dekodiert (es kann dasselbe Format wie für die Endorsement-Informationen sein oder nicht).
  • Die Operation 1508 ist eine Operation zum Bestimmen, basierend auf den Endorsement-Informationen und der Bewertungsrichtlinie, dass eine Delegierung an die Verifiziererentität gestattet ist, um der Verifiziererentität zu ermöglichen, die Attestierung der externen Entität durchzuführen.
  • Die Operation 1510 ist eine Operation zum Bereitstellen eines Delegierungsbefehls (z. B. eine Anforderung, Nachricht, Entscheidung oder eine andere kommunizierte Autorisierung) an die Verifiziererentität, um die Attestierung der externen Entität durchzuführen. In einem Beispiel autorisiert der Delegierungsbefehl die delegierte Verifizierungsinstanz, Attestierungsoperationen für eine Domäne von Entitäten einschließlich der externen Entität durchzuführen. Insbesondere können solche Attestierungsoperationen jene vorstehend unter Bezugnahme auf 9a bis 9E beschriebenen beinhalten, sobald die Verifizierungsdelegierer-Entität mit dem Delegierungsbefehl ordnungsgemäß delegiert ist.
  • In weiteren Beispielen wird der Delegierungsbefehl der Verifizierungsdelegierer-Entität in einem definierten Format über eine sichere Kommunikationsverbindung bereitgestellt. Beispielsweise kann ein CBOR-Datenformat (Concise Binary Object Representation) verwendet werden.
  • In weiteren Beispielen ist die Rechenvorrichtung auch als ein führender Attestierungsverifizierer konfiguriert und kann zusätzlich zum Delegieren einer derartigen Rolle an einen Verifiziererdelegierten eine Attestierung der externen Entität oder anderer Entitäten (als die „zweite Entität“ bezeichnet) durchführen. Beispielsweise können Attestierungsoperationen für eine zweite Entität Operationen beinhalten zum: Erhalten eines Beweises von einem oder mehreren Attestierern bezüglich der zweiten Entität, Anwenden der Endorsement-Informationen und der Bewertungsrichtlinie für Beweise, als Beweis für den einen oder die mehreren Attestierer und Kommunizieren von Attestierungsergebnissen für die zweite Entität an eine vertrauende Partei. In diesem beispielhaften Szenario können Attestierungsergebnisse gemäß einem definierten Format kodiert werden. Auch in diesem beispielhaften Szenario kann die vertrauende Partei die Gültigkeit der Attestierungsergebnisse basierend auf einer Bewertungsrichtlinie für Attestierungsergebnisse bestimmen, die von einem Eigentümer einer vertrauenden Partei bereitgestellt wird, da die Bewertungsrichtlinie für Attestierungsergebnisse in einem definierten Format bereitgestellt wird. Auch in diesem beispielhaften Szenario wird der Beweis von dem einen oder den mehreren Attestierern in einem oder mehreren Formaten bereitgestellt, und der Beweis wird in ein gemeinsames Format zur Bewertung dekodiert.
  • Zusätzliche Beispiele der vorliegend beschriebenen Verfahrens-, System- und Vorrichtungsausführungsformen beinhalten die folgenden, nicht beschränkenden Implementierungen. Jedes der folgenden nicht einschränkenden Beispiele kann für sich allein stehen oder kann in einer beliebigen Permutation oder Kombination mit einem oder mehreren beliebigen der anderen Beispiele, die unten oder in der gesamten vorliegenden Offenbarung bereitgestellt werden, kombiniert werden.
  • Beispiel 1 ist ein Rechensystem, das umfasst: eine Verarbeitungsschaltungsanordnung; Anweisungen; und eine Speichervorrichtung (die z. B. darin ausgeführte Anweisungen beinhaltet), wobei die Anweisungen bei Ausführung durch die Verarbeitungsschaltungsanordnung die Verarbeitungsschaltungsanordnung konfigurieren, um Attestierungsoperationen zu Folgendem durchzuführen:
  • Beispiel 1 ist eine Rechenvorrichtung, die umfasst: mindestens einen Speicher; Anweisungen in der Rechenvorrichtung; und eine Verarbeitungsschaltung zum Ausführen der Anweisungen, um Attestierungsdelegierungsoperationen durchzuführen, die: Endorsement-Informationen zur Attestierung einer Entität erhalten; eine Bewertungsrichtlinie zur Bewertung eines Attestierungsbeweises für die Attestierung der Entität erhalten; basierend auf den Endorsement-Informationen und der Bewertungsrichtlinie bestimmen, dass es einer Verifizierungsdelegierer-Entität gestattet ist, die Attestierung der Entität durchzuführen, und für die Verifizierungsdelegierer-Entität einen Delegierungsbefehls zum Durchführen der Attestierung der Entität bereitzustellen, wobei der Delegierungsbefehl die Verifizierungsdelegierer-Entität autorisiert, Attestierungsoperationen für eine Domäne von Entitäten einschließlich der Entität durchzuführen.
  • In Beispiel 2 beinhaltet der Gegenstand von Beispiel 1 optional, dass der Delegierungsbefehl der Verifizierungsdelegierer-Entität in einem definierten Format über eine sichere Kommunikationsverbindung bereitgestellt wird.
  • In Beispiel 3 beinhaltet der Gegenstand des Beispiels 2 optional, dass das definierte Format ein CBOR-Datenformat (Concise Binary Object Representation) ist.
  • In Beispiel 4 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 1 bis 3 optional, dass die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung ist, wobei die Rechenvorrichtung und die andere Rechenvorrichtung kommunikativ über ein Netzwerk oder einen Bus gekoppelt sind oder anderweitig über dieses kommunizieren.
  • In Beispiel 5 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 1 bis 4 optional, dass die Verarbeitungsschaltungsanordnung der Rechenvorrichtung ferner konfiguriert ist, um die Anweisungen auszuführen, um eine Vertrauensherstellung der Verifizierungsdelegierer-Entität mit Operationen durchzuführen, die: einen Attestierungsbeweis von der Verifizierungsdelegierer-Entität erhalten; Attestierungsergebnisse aus der Bewertung des Attestierungsbeweises erhalten; eine Delegierungsentscheidung bezüglich des Attestierungsbeweises und der Attestierungsergebnisse durchführen, wobei die Delegierungsentscheidung eine Delegierung von Attestierungsfunktionen an die Verifizierungsdelegierer-Entität ermöglichen soll; und die Delegierungsentscheidung an die Verifizierungsdelegierer-Entität kommunizieren.
  • In Beispiel 6 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 1 bis 5 optional, dass die Endorsement-Informationen von Endorser-Entitäten in einem oder mehreren kodierten Formaten bereitgestellt werden, wobei die Endorsement-Informationen in ein gemeinsames Format zur Bewertung dekodiert werden; und wobei die Bewertungsrichtlinie von einer Verifizierer-Eigentümerentität in einem oder mehreren kodierten Formaten bereitgestellt wird, wobei die Bewertungsrichtlinie in ein gemeinsames Format zur Bewertung dekodiert wird.
  • In Beispiel 7 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 1 bis 6 optional, dass die Rechenvorrichtung als ein führender Attestierungsverifizierer konfiguriert ist, und wobei die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung ist, die als ein Verifizierer-Endorsee konfiguriert ist, wobei die Verarbeitungsschaltungsanordnung der Rechenvorrichtung ferner dazu dient, die Anweisungen zum Durchführen von Attestierungsoperationen für eine zweite Entität auszuführen, mit Operationen, die: einen Beweis von einem oder mehreren Attestierern bezüglich der zweiten Entität erhalten; die Endorsement-Informationen und die Bewertungsrichtlinie als Beweis für den Beweis von dem einen oder den mehreren Attestierern anwenden; und Attestierungsergebnisse für die zweite Entität an eine vertrauende Partei kommunizieren.
  • In Beispiel 8 beinhaltet der Gegenstand von Beispiel 7 optional, dass die Attestierungsergebnisse gemäß einem definierten Format kodiert werden.
  • In Beispiel 9 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 7 bis 8 optional, dass die vertrauende Partei die Gültigkeit der Attestierungsergebnisse basierend auf einer Bewertungsrichtlinie für Attestierungsergebnisse bestimmt, die von einem Eigentümer einer vertrauenden Partei bereitgestellt wird, und wobei die Bewertungsrichtlinie für Attestierungsergebnisse in einem definierten Format bereitgestellt wird.
  • In Beispiel 10 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 7 bis 9 optional, dass der Beweis von dem einen oder den mehreren Attestierern in einem oder mehreren Formaten bereitgestellt wird, und wobei der Beweis in ein gemeinsames Format zur Bewertung dekodiert wird.
  • In Beispiel 11 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 1 bis 10 optional, dass die Attestierungsdelegierungsoperationen durch einen Verifizierer durchgeführt werden, der ein Root-Complex ist, der in Hardware der Rechenvorrichtung implementiert ist, und wobei die Verifizierungsdelegierer-Entität eine andere Entität ist, die in der Hardware der Rechenvorrichtung implementiert ist.
  • Beispiel 12 ist ein nichtflüchtiges vorrichtungslesbares Speichermedium, das Anweisungen enthält, wobei die Anweisungen bei Ausführung durch eine Verarbeitungsschaltungsanordnung einer Rechenvorrichtung die Verarbeitungsschaltungsanordnung veranlassen, Attestierungsdelegierungsoperationen durchzuführen, um: Endorsement-Informationen zur Attestierung einer Entität zu erhalten; eine Bewertungsrichtlinie zur Bewertung eines Attestierungsbeweises für die Attestierung der Entität zu erhalten; basierend auf den Endorsement-Informationen und der Bewertungsrichtlinie zu bestimmen, dass es einer Verifizierungsdelegierer-Entität gestattet ist, die Attestierung der Entität durchzuführen; und für die Verifizierungsdelegierer-Entität einen Delegierungsbefehls zum Durchführen der Attestierung der Entität bereitzustellen, wobei der Delegierungsbefehl die Verifizierungsdelegierer-Entität autorisiert, Attestierungsoperationen für eine Domäne von Entitäten einschließlich der Entität durchzuführen.
  • In Beispiel 13 beinhaltet der Gegenstand von Beispiel 12 optional, dass der Delegierungsbefehl der Verifizierungsdelegierer-Entität in einem definierten Format über eine sichere Kommunikationsverbindung bereitgestellt wird.
  • In Beispiel 14 beinhaltet der Gegenstand des Beispiels 13 optional, dass das definierte Format ein CBOR-Datenformat (Concise Binary Object Representation) ist.
  • In Beispiel 15 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 12 bis 14 optional, dass die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung ist, wobei die Rechenvorrichtung und die andere Rechenvorrichtung kommunikativ über ein Netzwerk oder einen Bus gekoppelt sind oder anderweitig über dieses kommunizieren.
  • In Beispiel 16 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 12 bis 15 optional die Anweisungen, die die Verarbeitungsschaltungsanordnung ferner veranlassen, eine Vertrauensherstellung der Verifizierungsdelegierer-Entität mit Operationen durchzuführen, die: einen Attestierungsbeweis von der Verifizierungsdelegierer-Entität erhalten; Attestierungsergebnisse aus der Bewertung des Attestierungsbeweises erhalten; eine Delegierungsentscheidung bezüglich des Attestierungsbeweises und der Attestierungsergebnisse durchführen, wobei die Delegierungsentscheidung eine Delegierung von Attestierungsfunktionen an die Verifizierungsdelegierer-Entität ermöglichen soll; und die Delegierungsentscheidung an die Verifizierungsdelegierer-Entität kommunizieren.
  • In Beispiel 17 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 12 bis 16 optional, dass die Endorsement-Informationen von Endorser-Entitäten in einem oder mehreren kodierten Formaten bereitgestellt werden, wobei die Endorsement-Informationen zur Bewertung in ein gemeinsames Format dekodiert werden; und wobei die Bewertungsrichtlinie von einer Verifizierer-Eigentümerentität in einem oder mehreren kodierten Formaten bereitgestellt wird, wobei die Bewertungsrichtlinie zur Bewertung in ein gemeinsames Format dekodiert wird.
  • In Beispiel 18 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 12 bis 17 optional, dass die Rechenvorrichtung als ein führender Attestierungsverifizierer konfiguriert ist, und wobei die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung ist, die als ein Verifizierer-Endorsee konfiguriert ist, wobei die Verarbeitungsschaltungsanordnung der Rechenvorrichtung ferner dazu dient, die Anweisungen zum Durchführen von Attestierungsoperationen für eine zweite Entität auszuführen, mit Operationen, die: einen Beweis von einem oder mehreren Attestierern bezüglich der zweiten Entität erhalten; die Endorsement-Informationen und die Bewertungsrichtlinie als Beweis für den Beweis von dem einen oder den mehreren Attestierern anwenden; und Attestierungsergebnisse für die zweite Entität an eine vertrauende Partei kommunizieren.
  • In Beispiel 19 beinhaltet der Gegenstand von Beispiel 18 optional, dass die Attestierungsergebnisse gemäß einem definierten Format kodiert werden.
  • In Beispiel 20 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 18 bis 19 optional, dass die vertrauende Partei die Gültigkeit der Attestierungsergebnisse basierend auf einer Bewertungsrichtlinie für Attestierungsergebnisse bestimmt, die von einem Eigentümer einer vertrauenden Partei bereitgestellt wird, und wobei die Bewertungsrichtlinie für Attestierungsergebnisse in einem definierten Format bereitgestellt wird.
  • In Beispiel 21 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 18 bis 20 optional, dass der Beweis von dem einen oder den mehreren Attestierern in einem oder mehreren Formaten bereitgestellt wird, und wobei der Beweis in ein gemeinsames Format zur Bewertung dekodiert wird.
  • In Beispiel 22 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 12 bis 21 optional, dass die Attestierungsdelegierungsoperationen durch einen Verifizierer durchgeführt werden, der ein Root-Complex ist, der in Hardware der Rechenvorrichtung implementiert ist, und wobei die Verifizierungsdelegierer-Entität eine andere Entität ist, die in der Hardware der Rechenvorrichtung implementiert ist.
  • Beispiel 23 ist ein Verfahren, das eine Vielzahl von Operationen umfasst, die mit einem Prozessor und einem Speicher einer Rechenvorrichtung ausgeführt werden, um Attestierungsdelegierungsoperationen durchzuführen, die Folgendes umfassen: Erhalten von Endorsement-Informationen zur Attestierung einer Entität; Erhalten einer Bewertungsrichtlinie zur Bewertung eines Attestierungsbeweises für die Attestierung der Entität; Bestimmen, basierend auf den Endorsement-Informationen und der Bewertungsrichtlinie, dass es einer Verifizierungsdelegierer-Entität gestattet ist, die Attestierung der Entität durchzuführen; und Bereitstellen, für die Verifizierungsdelegierer-Entität, eines Delegierungsbefehls zum Durchführen der Attestierung der Entität, wobei der Delegierungsbefehl die Verifizierungsdelegierer-Entität autorisiert, Attestierungsoperationen für eine Domäne von Entitäten einschließlich der Entität durchzuführen.
  • In Beispiel 24 beinhaltet der Gegenstand von Beispiel 23 optional, dass der Delegierungsbefehl der Verifizierungsdelegierer-Entität in einem definierten Format über eine sichere Kommunikationsverbindung bereitgestellt wird.
  • In Beispiel 25 beinhaltet der Gegenstand des Beispiels 24 optional, dass das definierte Format ein CBOR-Datenformat (Concise Binary Object Representation) ist.
  • In Beispiel 26 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 23 bis 25 optional, dass die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung ist, wobei die Rechenvorrichtung und die andere Rechenvorrichtung kommunikativ über ein Netzwerk oder einen Bus gekoppelt sind oder anderweitig über dieses kommunizieren.
  • In Beispiel 27 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 23 bis 26 optional das Verfahren, das ferner das Durchführen einer Vertrauensherstellung der Verifizierungsdelegierer-Entität mit Operationen umfasst, welche Folgendes umfassen: Erhalten eines Attestierungsbeweises von der Verifizierungsdelegierer-Entität; Erhalten von Attestierungsergebnissen aus der Bewertung des Attestierungsbeweises; Durchführen einer Delegierungsentscheidung bezüglich des Attestierungsbeweises und der Attestierungsergebnisse, wobei die Delegierungsentscheidung eine Delegierung von Attestierungsfunktionen an die Verifizierungsdelegierer-Entität ermöglichen soll; und Kommunizieren der Delegierungsentscheidung an die Verifizierungsdelegierer-Entität.
  • In Beispiel 28 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 23 bis 27 optional, dass die Endorsement-Informationen von Endorser-Entitäten in einem oder mehreren kodierten Formaten bereitgestellt werden, wobei die Endorsement-Informationen in ein gemeinsames Format zur Bewertung dekodiert werden; und wobei die Bewertungsrichtlinie von einer Verifizierer-Eigentümerentität in einem oder mehreren kodierten Formaten bereitgestellt wird, wobei die Bewertungsrichtlinie in ein gemeinsames Format zur Bewertung dekodiert wird.
  • In Beispiel 29 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 23 bis 28 optional, dass die Rechenvorrichtung als ein führender Attestierungsverifizierer konfiguriert ist, und wobei die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung ist, die als ein Verifizierer-Endorsee konfiguriert ist, wobei das Verfahren ferner das Durchführen von Attestierungsoperationen für eine zweite Entität umfasst, mit Operationen, die umfassen: Erhalten von Beweisen von einem oder mehreren Attestierern bezüglich der zweiten Entität; Anwenden der Endorsement-Informationen und der Bewertungsrichtlinie als Beweis für den Beweis von dem einen oder den mehreren Attestierern; und Kommunizieren der Attestierungsergebnisse für die zweite Entität an eine vertrauende Partei.
  • In Beispiel 30 beinhaltet der Gegenstand von Beispiel 29 optional, dass die Attestierungsergebnisse gemäß einem definierten Format kodiert werden.
  • In Beispiel 31 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 29 bis 30 optional, dass die vertrauende Partei die Gültigkeit der Attestierungsergebnisse basierend auf einer Bewertungsrichtlinie für Attestierungsergebnisse bestimmt, die von einem Eigentümer einer vertrauenden Partei bereitgestellt wird, und wobei die Bewertungsrichtlinie für Attestierungsergebnisse in einem definierten Format bereitgestellt wird.
  • In Beispiel 32 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 29 bis 31 optional, dass der Beweis von dem einen oder den mehreren Attestierern in einem oder mehreren Formaten bereitgestellt wird, und wobei der Beweis in ein gemeinsames Format zur Bewertung dekodiert wird.
  • In Beispiel 33 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 23 bis 32 optional, dass die Attestierungsdelegierungsoperationen durch einen Verifizierer durchgeführt werden, der ein Root-Complex ist, der in Hardware der Rechenvorrichtung implementiert ist, und wobei die Verifizierungsdelegierer-Entität eine andere Entität ist, die in der Hardware der Rechenvorrichtung implementiert ist.
  • Beispiel 34 ist eine Vorrichtung zum Durchführen von Attestierungsdelegierungsoperationen, die Folgendes umfassen: Mittel zum Erhalten von Endorsement-Informationen zur Attestierung einer Entität; Mittel zum Erhalten einer Bewertungsrichtlinie zur Bewertung eines Attestierungsbeweises für die Attestierung der Entität; Mittel zum Bestimmen, basierend auf den Endorsement-Informationen und der Bewertungsrichtlinie, dass es einer Verifizierungsdelegierer-Entität gestattet ist, die Attestierung der Entität durchzuführen, und Mittel zum Bereitstellen, für die Verifizierungsdelegierer-Entität, eines Delegierungsbefehls zum Durchführen der Attestierung der Entität, wobei der Delegierungsbefehl die Verifizierungsdelegierer-Entität autorisiert, Attestierungsoperationen für eine Domäne von Entitäten einschließlich der Entität durchzuführen.
  • In Beispiel 35 beinhaltet der Gegenstand von Beispiel 34 optional Mittel zum Bereitstellen des Delegierungsbefehls für die Verifizierungsdelegierer-Entität in einem definierten Format über eine sichere Kommunikationsverbindung.
  • In Beispiel 36 beinhaltet der Gegenstand des Beispiels 35 optional Mittel zum Kodieren und Dekodieren des Delegierungsbefehls in einem definierten Format, einschließlich in einem CBOR-Datenformat (Concise Binary Object Representation).
  • In Beispiel 37 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 34 bis 36 optional Mittel zum Kommunizieren mit der Verifizierungsdelegierer-Entität, wobei die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung ist, und wobei die Rechenvorrichtung und die andere Rechenvorrichtung kommunikativ über ein Netzwerk oder einen Bus gekoppelt sind oder anderweitig über dieses kommunizieren.
  • In Beispiel 38 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 34 bis 37 optional Mittel zum Erhalten eines Attestierungsbeweises von der Verifizierungsdelegierer-Entität: Mittel zum Erhalten eines Attestierungsbeweises von der Verifizierungsdelegierer-Entität, Mittel zum Erhalten von Attestierungsergebnissen aus der Bewertung des Attestierungsbeweises; Mittel zum Durchführen einer Delegierungsentscheidung bezüglich des Attestierungsbeweises und der Attestierungsergebnisse, wobei die Delegierungsentscheidung eine Delegierung von Attestierungsfunktionen an die Verifizierungsdelegierer-Entität ermöglichen soll; und Mittel zum Kommunizieren der Delegierungsentscheidung an die Verifizierungsdelegierer-Entität.
  • In Beispiel 39 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 34 bis 38 optional Mittel zum Dekodieren der Endorsement-Informationen in ein gemeinsames Format zur Bewertung, wobei die Endorsement-Informationen von Endorser-Entitäten in einem oder mehreren kodierten Formaten bereitgestellt werden; und Mittel zum Dekodieren der Bewertungsrichtlinie in ein gemeinsames Format zur Bewertung, wobei die Bewertungsrichtlinie von einer Verifizierer-Eigentümerentität in einem oder mehreren kodierten Formaten bereitgestellt wird.
  • In Beispiel 40 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 34 bis 39 optional eine Vorrichtung, wobei die Vorrichtung als ein führender Attestierungsverifizierer konfiguriert ist und wobei die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung ist, die als ein Verifizierer-Endorsee konfiguriert ist, wobei die Vorrichtung ferner konfiguriert ist, um Attestierungsoperationen für eine zweite Entität durchzuführen, und die Vorrichtung ferner umfasst: Mittel zum Erhalten von Beweisen von einem oder mehreren Attestierern bezüglich der zweiten Entität; Mittel zum Anwenden der Endorsement-Informationen und der Bewertungsrichtlinie als Beweis für den Beweis von dem einen oder den mehreren Attestierern; und Mittel zum Kommunizieren der Attestierungsergebnisse für die zweite Entität an eine vertrauende Partei.
  • In Beispiel 41 beinhaltet der Gegenstand von Beispiel 40 optional Mittel zum Dekodieren der Attestierungsergebnisse, die gemäß einem definierten Format kodiert werden.
  • In Beispiel 42 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 40 bis 41 optional Mittel zum Bewerten der Bewertungsrichtlinie für Attestierungsergebnisse, die in einem definierten Format bereitgestellt werden, wobei die vertrauende Partei die Gültigkeit der Attestierungsergebnisse basierend auf einer Bewertungsrichtlinie für Attestierungsergebnisse bestimmt, die von einem Eigentümer einer vertrauenden Partei bereitgestellt wird.
  • In Beispiel 43 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 40 bis 42 optional Mittel zum Dekodieren des Beweises in ein gemeinsames Format zur Bewertung, wobei der Beweis von dem einen oder den mehreren Attestierern in einem oder mehreren Formaten bereitgestellt wird.
  • In Beispiel 44 beinhaltet der Gegenstand eines oder mehrerer der Beispiele 34 bis 43 optional Mittel zum Konfigurieren der Vorrichtung als ein führender Attestierungsverifizierer unter Verwendung eines Root-Complex in Hardware der Vorrichtung, wobei die Verifizierungsdelegierer-Entität eine andere Entität ist, die in der Hardware der Vorrichtung implementiert ist.
  • Beispiel 45 ist zumindest ein maschinenlesbares Medium, das Anweisungen enthält, die bei Ausführung einer Verarbeitungsschaltungsanordnung die Verarbeitungsschaltungsanordnung veranlassen, Operationen zum Umsetzen eines der Beispiele 1 bis 44 durchzuführen.
  • Beispiel 46 ist eine Vorrichtung, die Mittel zum Implementieren eines der Beispiele 1 bis 44 umfasst.
  • Beispiel 47 ist ein System zum Implementieren eines beliebigen der Beispiele 1 bis 44.
  • Beispiel 48 ist ein Verfahren zum Implementieren eines beliebigen der Beispiele 1 bis 44.
  • Beispiel 49 ist ein mehrschichtiges Edge-Computersystem, das eine Vielzahl von Edge-Computerknoten umfasst, die unter Edge-On-Premise-Edge-, Netzwerkzugangs-Edge-oder Nah-Edge-Computereinstellungen bereitgestellt sind, wobei die Vielzahl von Edge-Computerknoten konfiguriert ist, um eines der Verfahren der Beispiele 1 bis 44 auszuführen.
  • Beispiel 50 ist ein Edge-Rechensystem, das mehrere Edge-Rechenknoten umfasst, wobei jeder der mehreren Edge-Rechenknoten konfiguriert ist, um eines der Verfahren der Beispiele 1 bis 44 durchzuführen.
  • Beispiel 51 ist ein Edge-Rechenknoten, der in einer Schicht eines Edge-Computing-Netzwerks als ein Aggregationsknoten, Netzwerkhubknoten, Gateway-Knoten oder Kerndatenverarbeitungsknoten betreibbar und konfiguriert ist, um eines der Verfahren nach Beispiel 1 bis 44 durchzuführen.
  • Beispiel 52 ist ein Edge-Computing-Netzwerk, das Netzwerk- und Verarbeitungskomponenten umfasst, die konfiguriert sind, um ein Kommunikationsnetzwerk bereitzustellen oder zu betreiben, um einem Edge-Computing-System zu ermöglichen, eines der Verfahren nach Beispiel 1 bis 44 zu implementieren.
  • Beispiel 53 ist ein Edge-Rechensystem, das als ein Edge-Mesh konfiguriert ist, das mit einem Mikrodienstcluster, einem Mikrodienstcluster mit Sidecars oder verknüpften Mikrodienstclustern mit Sidecars versehen ist, das konfiguriert ist, um eines der Verfahren der Beispiele 1 bis 44 zu implementieren.
  • Beispiel 54 ist ein Edge-Rechensystem, das Schaltungsanordnungen umfasst, die konfiguriert sind, um Dienste mit einer oder mehreren Isolationsumgebungen zu implementieren, die zwischen dedizierter Hardware, virtuellen Maschinen, Containern oder virtuellen Maschinen auf Containern bereitgestellt werden, wobei das Edge-Rechensystem dazu ausgelegt ist, eines der Verfahren der Beispiele 1 bis 44 zu implementieren.
  • Beispiel 55 ist ein Edge-Rechensystem, das Networking- und Verarbeitungskomponenten zum Kommunizieren mit einer Benutzergerätevorrichtung, einer Client-Rechenvorrichtung, einer Bereitstellungsvorrichtung oder einer Verwaltungsvorrichtung umfasst, um eines der Verfahren der Beispiele 1 bis 44 zu implementieren.
  • Beispiel 56 ist Netzwerkhardware mit darauf implementierten Netzwerkfunktionen, die innerhalb eines Edge-Rechensystems betreibbar sind, wobei die Netzwerkfunktionen konfiguriert sind, um eines der Verfahren der Beispiele 1 bis 44 zu implementieren.
  • Beispiel 57 ist Beschleunigungshardware mit darauf implementierten Beschleunigungsfunktionen, die in einem Edge-Computing-System betreibbar sind, wobei die Beschleunigungsfunktionen konfiguriert sind, um ein beliebiges der Verfahren der Beispiele 1 bis 44 zu implementieren.
  • Beispiel 58 ist Speicherungshardware mit darauf implementierten Speicherungsfähigkeiten, die in einem Edge-Rechensystem betreibbar ist, wobei die Speicherungshardware konfiguriert ist, eines der Verfahren der Beispiele 1 bis 44 zu implementieren.
  • Beispiel 59 ist Berechnungshardware mit darauf implementierten Rechenfähigkeiten, die in einem Edge-Rechensystem betreibbar ist, wobei die Berechnungshardware konfiguriert ist, um eines der Verfahren der Beispiele 1 bis 44 zu implementieren.
  • Beispiel 60 ist ein Edge-Rechensystem, das dazu ausgelegt ist, Dienste mit einem beliebigen der Verfahren der Beispiele 1 bis 44 zu implementieren, wobei sich die Dienste auf eines oder mehrere von Folgenden beziehen: Rechen-Offload, Daten-Caching, Videoverarbeitung, Netzwerkfunktionsvirtualisierung, Funkzugangsnetzwerkverwaltung, Augmented Reality, Virtual Reality, autonomes Fahren, Fahrzeugassistenz, Fahrzeugkommunikationen, industrielle Automatisierung, Einzelhandelsdienste, Herstellungsoperationen, intelligente Gebäude, Energieverwaltung, Operationen im Internet der Dinge, Objektdetektion, Spracherkennung, Anwendungen im Gesundheitswesen, Gaming-Anwendungen oder beschleunigte Inhaltsverarbeitung.
  • Beispiel 61 ist eine Vorrichtung eines Edge-Rechensystems, die Folgendes umfasst: einen oder mehrere Prozessoren und ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, die bei Ausführung durch den einen oder die mehreren Prozessoren den einen oder die mehreren Prozessoren veranlassen, eines der Verfahren der Beispiele 1 bis 44 ausführen.
  • Beispiel 62 ist ein oder mehrere computerlesbare Speicherungsmedien, die Anweisungen umfassen, um eine elektronische Vorrichtung eines Edge-Rechensystems zu veranlassen, bei Ausführung der Anweisungen durch einen oder mehrere Prozessoren der elektronischen Vorrichtung eines der Verfahren der Beispiele 1 bis 44 durchzuführen.
  • Beispiel 63 ist ein Computerprogramm, das in einem Edge-Rechensystem verwendet wird, wobei das Computerprogramm Anweisungen umfasst, wobei die Ausführung des Programms durch ein Verarbeitungselement in dem Edge-Rechensystem das Verarbeitungselement veranlassen soll, eines der Verfahren der Beispiele 1 bis 44 durchzuführen.
  • Beispiel 64 ist eine Edge-Computing-Gerätevorrichtung, die als ein eigenständiges Verarbeitungssystem arbeitet, das ein Gehäuse, eine Einhausung oder eine Schale, Netzwerkkommunikationsschaltungsanordnungen, Speicherungsschaltungsanordnungen und Prozessorschaltungsanordnungen umfasst, die dazu ausgelegt sind, eines der Verfahren der Beispiele 1 - 44 durchzuführen.
  • Beispiel 65 ist eine Vorrichtung eines Edge-Rechensystems, die Mittel zum Durchführen eines Verfahrens der Beispiele 1 bis 44 umfasst.
  • Beispiel 66 ist eine Vorrichtung eines Edge-Rechensystems, die Logik, Module oder eine Schaltungsanordnung zum Durchführen eines der Verfahren der Beispiele 1 bis 44 umfasst.
  • Beispiel 67 ist ein Edge-Rechensystem, das jeweilige Edge-Verarbeitungsvorrichtungen und -knoten zum Aufrufen oder Durchführen der Operationen der Beispiele 1 bis 44 oder eines anderen hierin beschriebenen Gegenstands beinhaltet.
  • Beispiel 68 ist ein Client-Endpunktknoten, der dazu betrieben werden kann, die Operationen eines der Beispiele 1 - 44 oder eines anderen hierin beschriebenen Gegenstands aufzurufen oder durchzuführen.
  • Beispiel 69 ist ein Aggregationsknoten, ein Netzwerkhubknoten, ein Gateway-Knoten oder ein Kerndatenverarbeitungsknoten, innerhalb eines oder gekoppelt mit einem Edge-Rechensystem, der dazu betrieben werden kann, die Operationen eines der Beispiele 1 bis 44 oder eines anderen hierin beschriebenen Gegenstands aufzurufen oder durchzuführen.
  • Beispiel 70 ist ein Zugangspunkt, eine Basisstation, eine Straßenrandeinheit, eine straßenseitige Einheit oder eine Vor-Ort-Einheit, innerhalb eines oder gekoppelt mit einem Edge-Rechensystem, die dazu betrieben werden kann, die Operationen eines der Beispiele 1 bis 44 oder eines anderen hierin beschriebenen Gegenstands aufzurufen oder durchzuführen.
  • Beispiel 71 ist ein Edge-Bereitstellungsknoten, ein Dienstorchestrierungsknoten, ein Anwendungsorchestrierungsknoten oder ein Multi-Mandanten-Verwaltungsknoten, innerhalb eines oder gekoppelt mit einem Edge-Rechensystem, der dazu betrieben werden kann, die Operationen der Beispiele 1 bis 44 oder eines anderen hierin beschriebenen Gegenstands aufzurufen oder durchzuführen.
  • Beispiel 72 ist ein Edge-Knoten, der einen Edge-Bereitstellungsdienst, einen Anwendungs- oder Dienstorchestrierungsdienst, einen Einsatz virtueller Maschinen, einen Container-Einsatz, einen Funktionseinsatz und eine Rechenverwaltung, innerhalb eines oder gekoppelt mit einem Edge-Rechensystem, betreibt, der/die dazu betrieben werden kann, die Operationen eines der Beispiele 1 bis 44 oder eines anderen hierin beschriebenen Gegenstands aufzurufen oder auszuführen.
  • Beispiel 73 ist ein Edge-Rechensystem, das Aspekte von Netzwerkfunktionen, Beschleunigungsfunktionen, Beschleunigungshardware, Speicherungshardware oder Berechnungshardwareressourcen umfasst und dazu betrieben werden kann, die hierin besprochenen Nutzungsfälle unter Verwendung eines der Beispiele 1 bis 44 oder eines anderen hierin beschriebenen Gegenstands aufzurufen oder durchzuführen.
  • Beispiel 74 ist ein Edge-Rechensystem, das zum Unterstützen von Client-Mobilitäts-, Fahrzeug-zu-Fahrzeug(V2V)-, Fahrzeug-zu-Allem(V2X)- oder Fahrzeug-zu-Infrastruktur(V2I)-Szenarien ausgelegt ist und optional gemäß den Mehrfachzugriff-Edge-Computing(MEC)-Spezifikationen des European Telecommunications Standards Institute (ETSI) betrieben wird und dazu betrieben werden kann, die hierin besprochenen Nutzungsfälle unter Verwendung eines der Beispiele 1 bis 44 oder eines anderen hierin beschriebenen Gegenstands aufzurufen oder durchzuführen.
  • Beispiel 75 ist ein Edge-Rechensystem, das für mobile Drahtloskommunikationen ausgelegt ist, einschließlich Konfigurationen gemäß 3GPP-4G/LTE- oder 5G-Netzwerkfähigkeiten, das dazu betrieben werden kann, die hierin besprochenen Nutzungsfälle unter Verwendung eines der Beispiele 1 bis 44 oder eines anderen hierin beschriebenen Gegenstands aufzurufen oder durchzuführen.
  • Beispiel 76 ist ein Edge-Rechenknoten, der in einer Schicht eines Edge-Rechennetzwerks oder Edge-Rechensystems als ein Aggregationsknoten, Netzwerkhubknoten, Gateway-Knoten oder Kerndatenverarbeitungsknoten betrieben werden kann, der in einer Close-Edge-, Local-Edge-, Enterprise-Edge-, Vor-Ort-Edge-, Near-Edge-, Middle-Edge- oder Far-Edge-Netzwerkschicht betrieben werden kann oder in einem Satz von Knoten mit gemeinsamen Latenz-, Timing- oder Distanzcharakteristiken betrieben werden kann, der dazu betrieben werden kann, die hierin besprochenen Nutzungsfälle unter Verwendung eines der Beispiele 1 bis 44 oder eines anderen hierin beschriebenen Gegenstands aufzurufen oder durchzuführen.
  • Beispiel 77 ist Networking-Hardware, Beschleunigungshardware, Speicherungshardware oder Berechnungshardware mit darauf implementierten Fähigkeiten, die in einem Edge-Rechensystem betrieben werden kann, um die hierin besprochenen Nutzungsfälle unter Verwendung eines der Beispiele 1 bis 44 oder eines anderen hierin beschriebenen Gegenstands aufzurufen oder durchzuführen.
  • Beispiel 78 ist eine Einrichtung eines Edge-Rechensystems, die umfasst: einen oder mehrere Prozessoren und ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, die, wenn sie durch den einen oder die mehreren Prozessoren eingesetzt und ausgeführt werden, den einen oder die mehreren Prozessoren dazu veranlassen, die hierin besprochenen Nutzungsfälle unter Verwendung eines der Beispiele 1 bis 44 oder eines anderen hierin beschriebenen Gegenstands aufzurufen oder durchzuführen.
  • Beispiel 79 ist ein oder mehrere computerlesbare Speicherungsmedien, die Anweisungen umfassen, um zu bewirken, dass eine elektronische Vorrichtung eines Edge-Rechensystems bei Ausführung der Anweisungen durch einen oder mehrere Prozessoren der elektronischen Vorrichtung die hierin besprochenen Nutzungsfälle unter Verwendung eines der Beispiele 1 bis 44 oder eines anderen hierin beschriebenen Gegenstands aufruft oder durchführt.
  • Beispiel 80 ist eine Einrichtung eines Edge-Rechensystems, die Mittel, Logik, Module oder Schaltungsanordnungen zum Aufrufen oder Durchführen der hierin besprochenen Nutzungsfälle unter Verwendung eines der Beispiele 1 bis 44 oder eines anderen hierin beschriebenen Gegenstands umfasst.
  • Es versteht sich, dass die in dieser Beschreibung beschriebenen Funktionseinheiten oder Fähigkeiten als Komponenten oder Module bezeichnet oder gekennzeichnet worden sein können, um ihre Implementierungsunabhängigkeit genauer hervorzuheben. Solche Komponenten können durch eine beliebige Anzahl von Software- oder Hardwareformen umgesetzt werden. Zum Beispiel kann eine Komponente oder ein Modul als eine Hardwareschaltung implementiert werden, die angepasste Very-Large-Scale-Integration-Schaltungen (VLSI-Schaltungen) oder Gate-Arrays, handelsübliche Halbleiter, wie Logikchips, Transistoren oder andere diskrete Komponenten, umfasst. Eine Komponente oder ein Modul kann auch in programmierbaren Hardwarevorrichtungen implementiert werden, wie feldprogrammierbaren Gate-Arrays, programmierbarer Arraylogik, programmierbaren Logikvorrichtungen oder dergleichen. Komponenten oder Module können auch in Software zur Ausführung durch verschiedene Arten von Prozessoren implementiert werden. Eine identifizierte Komponente oder ein identifiziertes Modul aus ausführbarem Code kann beispielsweise einen oder mehrere physische oder logische Blöcke von Computeranweisungen umfassen, die beispielsweise als ein Objekt, eine Prozedur oder eine Funktion organisiert sein können. Nichtsdestotrotz müssen die ausführbaren Elemente einer identifizierten Komponente oder eines identifizierten Moduls nicht physisch zusammen angeordnet sein, sondern können heterogene Anweisungen umfassen, die an unterschiedlichen Orten gespeichert sind, die, wenn sie logisch miteinander verbunden werden, die Komponente oder das Modul umfassen und den angegebenen Zweck für die Komponente oder das Modul erfüllen.
  • Tatsächlich kann eine Komponente oder ein Modul eines ausführbaren Codes eine einzige Anweisung oder viele Anweisungen sein und kann sogar über mehrere verschiedene Codesegmente, unter verschiedenen Programmen und über mehrere Speichervorrichtungen oder Verarbeitungssysteme hinweg verteilt sein. Insbesondere können manche Aspekte des beschriebenen Prozesses (wie Codeumschreiben und Codeanalyse) auf einem anderen Verarbeitungssystem (z. B. in einem Computer in einem Rechenzentrum) als jenem stattfinden, in dem der Code eingesetzt wird (z. B. in einem Computer, der in einen Sensor oder Roboter eingebettet ist). Auf ähnliche Weise können Betriebsdaten hier innerhalb von Komponenten oder Modulen identifiziert und veranschaulicht werden und können in einer beliebigen geeigneten Form ausgeführt und in einer beliebigen geeigneten Art von Datenstruktur organisiert sein. Die Betriebsdaten können als ein einziger Datensatz gesammelt werden oder über verschiedene Orte, einschließlich verschiedener Speichervorrichtungen, verteilt sein und zumindest teilweise lediglich als elektronische Signale in einem System oder Netzwerk bestehen. Die Komponenten oder Module können passiv oder aktiv sein, einschließlich Agenten, die betrieben werden können, um gewünschte Funktionen durchzuführen.
  • 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 63049442 [0001]
    • US 63/050988 [0001]

Claims (45)

  1. Computervorrichtung, umfassend: mindestens einen Speicher; Anweisungen in der Computervorrichtung; und eine Verarbeitungsschaltung zum Ausführen der Anweisungen, um Attestierungsdelegierungsoperationen durchzuführen, die: Endorsement-Informationen für die Attestierung einer Entität erhalten; eine Bewertungsrichtlinie zur Bewertung eines Attestierungsbeweises für die Attestierung der Entität erhalten; basierend auf den Endorsement-Informationen und der Bewertungsrichtlinie zu bestimmen, dass eine Delegierung an eine Verifizierungsdelegierer-Entität gestattet ist, um die Attestierung der Entität durchzuführen; und für die Verifizierungsdelegierer-Entität einen Delegierungsbefehls zum Durchführen der Attestierung der Entität bereitzustellen, wobei der Delegierungsbefehl die Verifizierungsdelegierer-Entität autorisiert, Attestierungsoperationen für eine Domäne von Entitäten einschließlich der Entität durchzuführen.
  2. Rechenvorrichtung nach Anspruch 1, wobei der Delegierungsbefehl der Verifizierungsdelegierer-Entität in einem definierten Format über eine sichere Kommunikationsverbindung bereitgestellt wird.
  3. Rechenvorrichtung nach Anspruch 2, wobei das definierte Format ein CBOR-Datenformat (Concise Binary Object Representation) ist.
  4. Rechenvorrichtung nach Anspruch 1, wobei die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung ist, wobei die Rechenvorrichtung und die andere Rechenvorrichtung über ein Netzwerk oder einen Bus kommunizieren.
  5. Rechenvorrichtung nach Anspruch 1, wobei die Verarbeitungsschaltungsanordnung der Rechenvorrichtung ferner dazu dient, die Anweisungen auszuführen, um eine Vertrauensherstellung der Verifizierungsdelegierer-Entität mit Operationen durchzuführen, die: : einen Attestierungsbeweis von der Verifizierungsdelegierer-Entität zu erhalten; Attestierungsergebnisse aus der Bewertung des Attestierungsbeweises zu erhalten; eine Delegierungsentscheidung bezüglich des Attestierungsbeweises und der Attestierungsergebnisse durchzuführen, wobei die Delegierungsentscheidung eine Delegierung von Attestierungsfunktionen an die Verifizierungsdelegierer-Entität ermöglichen soll; und die Delegierungsentscheidung an die Verifizierungsdelegierer-Entität zu kommunizieren.
  6. Rechenvorrichtung nach Anspruch 1, Wobei die Endorsement-Informationen von Endorser-Entitäten in einem oder mehreren kodierten Formaten bereitgestellt werden und die Endorsement-Informationen in ein gemeinsames Format zur Bewertung dekodiert werden; und wobei die Bewertungsrichtlinie von einer Verifizierer-Eigentümerentität in einem oder mehreren kodierten Formaten bereitgestellt wird, wobei die Bewertungsrichtlinie in ein gemeinsames Format zur Bewertung dekodiert wird.
  7. Rechenvorrichtung nach Anspruch 1, wobei die Rechenvorrichtung als ein führender Attestierungsverifizierer konfiguriert ist und wobei die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung ist, die als ein Verifizierer-Endorsee konfiguriert ist, wobei die Vorrichtung ferner konfiguriert ist, um Attestierungsoperationen für eine zweite Entität durchzuführen, mit Operationen, die: einen Beweis von einem oder mehreren Attestierern bezüglich der zweiten Entität erhalten; die Endorsement-Informationen und die Bewertungsrichtlinie als Beweis für den Beweis von dem einen oder den mehreren Attestierern anwenden; und Attestierungsergebnisse für die zweite Entität an eine vertrauende Partei kommunizieren.
  8. Rechenvorrichtung nach Anspruch 7, wobei die Attestierungsergebnisse gemäß einem definierten Format kodiert werden.
  9. Rechenvorrichtung nach Anspruch 7, wobei die vertrauende Partei die Gültigkeit der Attestierungsergebnisse basierend auf einer Bewertungsrichtlinie für Attestierungsergebnisse bestimmt, die von einem Eigentümer einer vertrauenden Partei bereitgestellt wird, und wobei die Bewertungsrichtlinie für Attestierungsergebnisse in einem definierten Format bereitgestellt wird..
  10. Rechenvorrichtung nach Anspruch 7, wobei der Beweis von dem einen oder den mehreren Attestierern in einem oder mehreren Formaten bereitgestellt wird und der Beweis in ein gemeinsames Format zur Bewertung dekodiert wird.
  11. Rechenvorrichtung nach Anspruch 1, wobei die Attestierungsdelegierungsoperationen durch einen Verifizierer durchgeführt werden, der ein Root-Complex ist, der in Hardware der Rechenvorrichtung implementiert ist, und wobei die Verifizierungsdelegierer-Entität eine andere Entität ist, die in der Hardware der Rechenvorrichtung implementiert ist.
  12. Verfahren, umfassend eine Vielzahl von Operationen, die mit einem Prozessor und einem Speicher einer Vorrichtung ausgeführt werden, um Attestierungsdelegierungsoperationen durchzuführen, die umfassen: Erhalten von Endorsement-Informationen für die Attestierung einer Entität; Erhalten einer Bewertungsrichtlinie zur Bewertung eines Attestierungsbeweises für die Attestierung der Entität; Bestimmen, basierend auf den Endorsement-Informationen und der Bewertungsrichtlinie, dass eine Delegierung an eine Verifizierungsdelegierer-Entität gestattet ist, um die Attestierung der Entität durchzuführen; und Bereitstellen, für die Verifizierungsdelegierer-Entität, eines Delegierungsbefehls zum Durchführen der Attestierung der Entität, wobei der Delegierungsbefehl die Verifizierungsdelegierer-Entität autorisiert, Attestierungsoperationen für eine Domäne von Entitäten einschließlich der Entität durchzuführen.
  13. Verfahren nach Anspruch 12, wobei der Delegierungsbefehl der Verifizierungsdelegierer-Entität in einem definierten Format über eine sichere Kommunikationsverbindung bereitgestellt wird.
  14. Verfahren nach Anspruch 13, wobei das definierte Format ein CBOR-Datenformat (Concise Binary Object Representation) ist.
  15. Verfahren nach Anspruch 12, wobei die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung ist, wobei die Rechenvorrichtung und die andere Rechenvorrichtung über ein Netzwerk oder einen Bus kommunizieren.
  16. Verfahren nach Anspruch 12, wobei das Verfahren ferner das Durchführen einer Vertrauensherstellung der Verifizierungsdelegierer-Entität mit Operationen umfasst, welche Folgendes umfassen: Erhalten eines Attestierungsbeweises von der Verifizierungsdelegierer-Entität; Erhalten von Attestierungsergebnissen aus der Bewertung des Attestierungsbeweises; Durchführen einer Delegierungsentscheidung bezüglich des Attestierungsbeweises und der Attestierungsergebnisse, wobei die Delegierungsentscheidung eine Delegierung von Attestierungsfunktionen an die Verifizierungsdelegierer-Entität ermöglichen soll; und Kommunizieren der Delegierungsentscheidung an die Verifizierungsdelegierer-Entität.
  17. Verfahren nach Anspruch 12, wobei die Endorsement-Informationen von Endorser-Entitäten in einem oder mehreren kodierten Formaten bereitgestellt werden und die Endorsement-Informationen in ein gemeinsames Format zur Bewertung dekodiert werden; und wobei die Bewertungsrichtlinie von einer Verifizierer-Eigentümerentität in einem oder mehreren kodierten Formaten bereitgestellt wird, wobei die Bewertungsrichtlinie in ein gemeinsames Format zur Bewertung dekodiert wird.
  18. Verfahren nach Anspruch 12, wobei die Rechenvorrichtung als ein führender Attestierungsverifizierer konfiguriert ist und wobei die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung ist, die als ein Verifizierer-Endorsee konfiguriert ist, wobei das Verfahren ferner das Durchführen von Attestierungsoperationen für eine zweite Entität umfasst, wobei die Operationen umfassen: Erhalten eines Beweises von einem oder mehreren Attestierern bezüglich der zweiten Entität; Anwenden der Endorsement-Informationen und der Bewertungsrichtlinie als Beweis für den Beweis von dem einen oder den mehreren Attestierern; und Kommunizieren von Attestierungsergebnissen für die zweite Entität an eine vertrauende Partei.
  19. Verfahren nach Anspruch 18, wobei die Attestierungsergebnisse gemäß einem definierten Format kodiert werden.
  20. Verfahren nach Anspruch 18, wobei die vertrauende Partei die Gültigkeit der Attestierungsergebnisse basierend auf einer Bewertungsrichtlinie für Attestierungsergebnisse bestimmt, die von einem Eigentümer einer vertrauenden Partei bereitgestellt wird, und wobei die Bewertungsrichtlinie für Attestierungsergebnisse in einem definierten Format bereitgestellt wird.
  21. Verfahren nach Anspruch 18, wobei der Beweis von dem einen oder den mehreren Attestierern in einem oder mehreren Formaten bereitgestellt wird und der Beweis in ein gemeinsames Format zur Bewertung dekodiert wird.
  22. Verfahren nach Anspruch 12, wobei die Attestierungsdelegierungsoperationen durch einen Verifizierer durchgeführt werden, der ein Root-Complex ist, der in Hardware der Rechenvorrichtung implementiert ist, und wobei die Verifizierungsdelegierer-Entität eine andere Entität ist, die in der Hardware der Rechenvorrichtung implementiert ist.
  23. Mindestens ein nichtflüchtiges maschinenlesbares Speichermedium, umfassend darauf gespeicherte Anweisungen, die bei Ausführung durch eine Verarbeitungsschaltungsanordnung einer Rechenvorrichtung die Verarbeitungsschaltungsanordnung veranlassen, die Attestierungsdelegierungsverfahren nach einem der Ansprüche 12 bis 22 durchzuführen.
  24. Nichtflüchtiges vorrichtungslesbares Speichermedium, das Anweisungen enthält, wobei die Anweisungen bei Ausführung durch eine Verarbeitungsschaltungsanordnung einer Vorrichtung die Verarbeitungsschaltungsanordnung veranlassen, Attestierungsdelegierungsoperationen durchzuführen, um: Endorsement-Informationen für die Attestierung einer Entität erhalten; eine Bewertungsrichtlinie zur Bewertung eines Attestierungsbeweises für die Attestierung der Entität erhalten; basierend auf den Endorsement-Informationen und der Bewertungsrichtlinie zu bestimmen, dass eine Delegierung an eine Verifizierungsdelegierer-Entität gestattet ist, um die Attestierung der Entität durchzuführen; und für die Verifizierungsdelegierer-Entität einen Delegierungsbefehls zum Durchführen der Attestierung der Entität bereitzustellen, wobei der Delegierungsbefehl die Verifizierungsdelegierer-Entität autorisiert, eine Attestierung von einer Domäne von Entitäten einschließlich der Entität durchzuführen.
  25. Vorrichtungslesbares Speichermedium nach Anspruch 24, wobei der Delegierungsbefehl der Verifizierungsdelegierer-Entität in einem definierten Format über eine sichere Kommunikationsverbindung bereitgestellt wird.
  26. Vorrichtungslesbares Speichermedium nach Anspruch 25, wobei das definierte Format ein CBOR-Datenformat (Concise Binary Object Representation) ist.
  27. Vorrichtungslesbares Speichermedium nach Anspruch 24, wobei die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung ist, wobei die Rechenvorrichtung und die andere Rechenvorrichtung über ein Netzwerk oder einen Bus kommunikativ gekoppelt sind.
  28. Vorrichtungslesbares Speichermedium nach Anspruch 24, wobei die Anweisungen die Verarbeitungsschaltungsanordnung ferner veranlassen, eine Vertrauensherstellung der Verifizierungsdelegierer-Entität mit Operationen durchzuführen, die: einen Attestierungsbeweis von der Verifizierungsdelegierer-Entität zu erhalten; Attestierungsergebnisse aus der Bewertung des Attestierungsbeweises zu erhalten; eine Delegierungsentscheidung bezüglich des Attestierungsbeweises und der Attestierungsergebnisse durchzuführen, wobei die Delegierungsentscheidung eine Delegierung von Attestierungsfunktionen an die Verifizierungsdelegierer-Entität ermöglichen soll; und die Delegierungsentscheidung an die Verifizierungsdelegierer-Entität zu kommunizieren.
  29. Vorrichtungslesbares Speichermedium nach Anspruch 24, wobei die Endorsement-Informationen von Endorser-Entitäten in einem oder mehreren kodierten Formaten bereitgestellt werden und die Endorsement-Informationen in ein gemeinsames Format zur Bewertung dekodiert werden; und wobei die Bewertungsrichtlinie von einer Verifizierer-Eigentümerentität in einem oder mehreren kodierten Formaten bereitgestellt wird, wobei die Bewertungsrichtlinie in ein gemeinsames Format zur Bewertung dekodiert wird.
  30. Vorrichtungslesbares Speichermedium nach Anspruch 24, wobei die Rechenvorrichtung als ein führender Attestierungsverifizierer konfiguriert ist und wobei die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung ist, die als ein Verifizierer-Endorsee konfiguriert ist, wobei die Vorrichtung ferner konfiguriert ist, um Attestierungsoperationen für eine zweite Entität durchzuführen, mit Operationen, die: einen Beweis von einem oder mehreren Attestierern bezüglich der zweiten Entität erhalten; die Endorsement-Informationen und die Bewertungsrichtlinie als Beweis für den Beweis von dem einen oder den mehreren Attestierern anwenden; und Attestierungsergebnisse für die zweite Entität an eine vertrauende Partei kommunizieren.
  31. Vorrichtungslesbares Speichermedium nach Anspruch 30, wobei die Attestierungsergebnisse gemäß einem definierten Format kodiert werden.
  32. Vorrichtungslesbares Speichermedium nach Anspruch 30, wobei die vertrauende Partei die Gültigkeit der Attestierungsergebnisse basierend auf einer Bewertungsrichtlinie für Attestierungsergebnisse bestimmt, die von einem Eigentümer einer vertrauenden Partei bereitgestellt wird, und wobei die Bewertungsrichtlinie für Attestierungsergebnisse in einem definierten Format bereitgestellt wird.
  33. Vorrichtungslesbares Speichermedium nach Anspruch 30, wobei der Beweis von dem einen oder den mehreren Attestierern in einem oder mehreren Formaten bereitgestellt wird und der Beweis in ein gemeinsames Format zur Bewertung dekodiert wird.
  34. Vorrichtungslesbares Speichermedium nach Anspruch 24, wobei die Attestierungsdelegierungsoperationen durch einen Verifizierer durchgeführt werden, der ein Root-Complex ist, der in Hardware der Rechenvorrichtung implementiert ist, und wobei die Verifizierungsdelegierer-Entität eine andere Entität ist, die in der Hardware der Rechenvorrichtung implementiert ist.
  35. Vorrichtung zum Durchführen von Attestierungsdelegierungsoperationen, umfassend: Mittel zum Erhalten von Endorsement-Informationen für die Attestierung einer Entität; Mittel zum Erhalten einer Bewertungsrichtlinie zur Bewertung eines Attestierungsbeweises für die Attestierung der Entität; Mittel zum Bestimmen, basierend auf den Endorsement-Informationen und der Bewertungsrichtlinie, dass eine Delegierung an eine Verifizierungsdelegierer-Entität gestattet ist, um die Attestierung der Entität durchzuführen; und Mittel zum Bereitstellen, für die Verifizierungsdelegierer-Entität, eines Delegierungsbefehls zum Durchführen der Attestierung der Entität, wobei der Delegierungsbefehl die Verifizierungsdelegierer-Entität autorisiert, Attestierungsoperationen für eine Domäne von Entitäten einschließlich der Entität durchzuführen.
  36. Vorrichtung nach Anspruch 35, ferner umfassend: Mittel zum Bereitstellen des Delegierungsbefehls der Verifizierungsdelegierer-Entität in einem definierten Format über eine sichere Kommunikationsverbindung.
  37. Vorrichtung nach Anspruch 36, ferner umfassend: Mittel zum Kodieren und Dekodieren des Delegierungsbefehls in einem definierten Format, einschließlich in einem CBOR-Datenformat (Concise Binary Object Representation).
  38. Vorrichtung nach Anspruch 35, ferner umfassend: Mittel zum Kommunizieren mit der Verifizierungsdelegierer-Entität, wobei die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung ist und wobei die Rechenvorrichtung und die andere Rechenvorrichtung über ein Netzwerk oder einen Bus kommunikativ gekoppelt sind.
  39. Vorrichtung nach Anspruch 35, ferner umfassend: Mittel zum Erhalten eines Attestierungsbeweises von der Verifizierungsdelegierer-Entität, Mittel zum Erhalten von Attestierungsergebnissen aus der Bewertung des Attestierungsbeweises; Mittel zum Durchführen einer Delegierungsentscheidung bezüglich des Attestierungsbeweises und der Attestierungsergebnisse, wobei die Delegierungsentscheidung eine Delegierung von Attestierungsfunktionen an die Verifizierungsdelegierer-Entität ermöglichen soll; und Mittel zum Kommunizieren der Delegierungsentscheidung an die Verifizierungsdelegierer-Entität.
  40. Vorrichtung nach Anspruch 35, ferner umfassend: Mittel zum Dekodieren der Endorsement-Informationen in ein gemeinsames Format zur Bewertung, wobei die Endorsement-Informationen von Endorser-Entitäten in einem oder mehreren kodierten Formaten bereitgestellt werden; und Mittel zum Dekodieren der Bewertungsrichtlinie in ein gemeinsames Format zur Bewertung, wobei die Bewertungsrichtlinie von einer Verifizierer-Eigentümerentität in einem oder mehreren kodierten Formaten bereitgestellt wird.
  41. Vorrichtung nach Anspruch 35, wobei die Vorrichtung als ein führender Attestierungsverifizierer konfiguriert ist und wobei die Verifizierungsdelegierer-Entität eine andere Rechenvorrichtung ist, die als ein Verifizierer-Endorsee konfiguriert ist, wobei die Vorrichtung konfiguriert ist, um Attestierungsoperationen für eine zweite Entität durchzuführen, und die Vorrichtung ferner umfasst: Mittel zum Erhalten eines Beweises von einem oder mehreren Attestierern bezüglich der zweiten Entität; Mittel zum Anwenden der Endorsement-Informationen und der Bewertungsrichtlinie als Beweis für den Beweis von dem einen oder den mehreren Attestierern; und Mittel zum Kommunizieren von Attestierungsergebnissen für die zweite Entität an eine vertrauende Partei.
  42. Vorrichtung nach Anspruch 41, ferner umfassend Mittel zum Dekodieren der Attestierungsergebnisse, die gemäß einem definierten Format kodiert werden.
  43. Vorrichtung nach Anspruch 41, ferner umfassend: Mittel zum Bewerten der Bewertungsrichtlinie für Attestierungsergebnisse, die in einem definierten Format bereitgestellt werden, wobei die vertrauende Partei die Gültigkeit der Attestierungsergebnisse basierend auf einer Bewertungsrichtlinie für Attestierungsergebnisse bestimmt, die von einem Eigentümer einer vertrauenden Partei bereitgestellt wird.
  44. Vorrichtung nach Anspruch 41, ferner umfassend: Mittel zum Dekodieren des Beweises in ein gemeinsames Format zur Bewertung, wobei der Beweis von dem einen oder den mehreren Attestierern in einem oder mehreren Formaten bereitgestellt wird.
  45. Vorrichtung nach Anspruch 35, ferner umfassend: Mittel zum Konfigurieren der Vorrichtung als ein führender Attestierungsverifizierer unter Verwendung eines Root-Complex in Hardware der Vorrichtung, wobei die Verifizierungsdelegierer-Entität eine andere Entität ist, die in der Hardware der Vorrichtung implementiert ist.
DE112021003656.4T 2020-07-08 2021-07-07 Rollendelegierung bei attestierungsverifizierern Pending DE112021003656T5 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US202063049442P 2020-07-08 2020-07-08
US63/049,442 2020-07-08
US202063050988P 2020-07-13 2020-07-13
US63/050,988 2020-07-13
PCT/US2021/040681 WO2022011009A1 (en) 2020-07-08 2021-07-07 Attestation verifier role delegation

Publications (1)

Publication Number Publication Date
DE112021003656T5 true DE112021003656T5 (de) 2023-05-25

Family

ID=79552204

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112021003656.4T Pending DE112021003656T5 (de) 2020-07-08 2021-07-07 Rollendelegierung bei attestierungsverifizierern

Country Status (3)

Country Link
US (1) US20230216849A1 (de)
DE (1) DE112021003656T5 (de)
WO (1) WO2022011009A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11770377B1 (en) * 2020-06-29 2023-09-26 Cyral Inc. Non-in line data monitoring and security services
US20230030816A1 (en) * 2021-07-30 2023-02-02 Red Hat, Inc. Security broker for consumers of tee-protected services

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102522778B1 (ko) * 2016-04-27 2023-04-19 한국전자통신연구원 분산 대리자 기반 무결성 검증을 수행하는 개별 기기, 그를 포함하는 개별 기기 무결성 검증 시스템 및 그 방법
US10735197B2 (en) * 2016-07-29 2020-08-04 Workday, Inc. Blockchain-based secure credential and token management across multiple devices
US11425111B2 (en) * 2018-11-14 2022-08-23 Intel Corporation Attestation token sharing in edge computing environments

Also Published As

Publication number Publication date
WO2022011009A1 (en) 2022-01-13
US20230216849A1 (en) 2023-07-06

Similar Documents

Publication Publication Date Title
US11669368B2 (en) Multi-tenant data protection in edge computing environments
US11831507B2 (en) Modular I/O configurations for edge computing using disaggregated chiplets
US11425111B2 (en) Attestation token sharing in edge computing environments
DE102020131613A1 (de) Verfahren, system und produkt zum implementieren von deterministischem on-boarding und planen virtualisierter arbeitslasten für edge-computing.
DE102022203247A1 (de) Disintermedierte Attestierung in einem MEC-Service-MESH-Framework
US12010144B2 (en) End-to-end device attestation
DE102021209282A1 (de) Verfahren, einrichtungen und systeme zur gemeinsamen nutzung von rechenressourcen zwischen edge-rechenknoten unter verwendung eines overlay-managers
DE102021210705A1 (de) Intelligente datenweiterleitung in edge-netzen
DE102021210882A1 (de) Erweitertes peer-to-peer (p2p) mit edge-vernetzung
DE112020007229T5 (de) Föderiertes mec-framework für kraftfahrzeugdienste
US20210117697A1 (en) Edge automatic and adaptive processing activations
DE102022203249A1 (de) Mehrfachzugriff-edge-computing- (mec-) fahrzeug-zu-alles-(v2x-) interoperabilitätsunterstützung für mehrere v2x-nachrichtenbroker
US20220014566A1 (en) Network supported low latency security-based orchestration
KR20220088306A (ko) 트러스트 크리덴셜의 자동 에스컬레이션
DE112018006935T5 (de) Sicherheitsprofile für OCF-Vorrichtungen und vertrauenswürdige Plattformen
DE102022208681A1 (de) Schichtübergreifende automatisierte fehlernachverfolgung und anomaliedetektion
WO2022125456A1 (en) Mec federation broker and manager enabling secure cross-platform communication
DE102022212395A1 (de) Ende-zu-ende-netzwerk-slicing (ens) vom ran- zum kernnetz für kommunikationen der nächsten generation (ng)
DE102022121227A1 (de) Dynamische slice-rekonfiguration während fafo(fault-attack-failure-outage)-ereignissen
DE102021209043A1 (de) Methods and apparatus to select a location of execution of a computation
US20230045110A1 (en) Import of deployable containers and source code in cloud development environment
DE102021121267A1 (de) Verfahren, Systeme, Vorrichtungen und Erzeugnisse zur Verwaltung des Zugriffs auf dezentrale Data Lakes
US20240243924A1 (en) Attestation microservices and service mesh for distributed workloads
DE112021003656T5 (de) Rollendelegierung bei attestierungsverifizierern
US20240241960A1 (en) Trusted provenance authority for cloud native computing platforms