DE112018005260T5

DE112018005260T5 - Sichere Gerät-Onboarding-Techniken

Info

Publication number: DE112018005260T5
Application number: DE112018005260.5T
Authority: DE
Inventors: Ned M. Smith; Mats Agerstam; Abhilasha Bhargav-Spantzel; Nathan Heldt-Sheller
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2017-11-06
Filing date: 2018-09-28
Publication date: 2020-06-18
Also published as: US20200275273A1; US11399285B2; WO2019089164A1; US20230009787A1

Abstract

Diverse Systeme und Verfahren zum Herstellen von Netzwerkkonnektivität und Onboarding für Internet-der-Dinge-Geräte (IoT-Geräte) und vertrauenswürdiger Plattformen, einschließlich Gerätbereitstellung gemäß Open Connectivity Foundation-Spezifikation (OCF-Spezifikation), werden besprochen. Bei einem Verfahren umfasst ein Zero-Touch-Inhabertransferverfahren folgende Vorgänge: Empfangen einer ersten Anfrage von einem neuen Gerät um Netzwerkzugang, um eine Onboarding-Vorgehensweise mit einer Netzwerkplattform zu beginnen; Übertragen von Befugnissen eines ersten Netzwerks zu dem neuen Gerät, wobei das erste Netzwerk verwendet wird, um auf einen Rendezvous-Server zuzugreifen und Onboarding-Information zu erhalten, die mit der Netzwerkplattform assoziiert ist; Empfangen einer zweiten Anfrage von einem neuen Gerät um Netzwerkzugang, um die Onboarding-Vorgehensweise fortzusetzen; und Übertragen von Befugnissen eines zweiten Netzwerks zu dem neuen Gerät, wobei das neue Gerät das zweite Netzwerk verwendet, um auf den Onboarding-Server der Netzwerkplattform zuzugreifen und die Onboarding-Vorgehensweise mit der Netzwerkplattform auszuführen oder abzuschließen.

Description

PRIORITÄTSANSPRUCH
Diese Anmeldung beansprucht den Vorrang der vorläufigen U.S.-Patentanmeldungen mit den Serien-Nr. 62/582 134 , eingereicht am 06. November 2017 mit dem Titel „ZERO-TOUCH DEVICE ONBOARDING“, und 62/625 184, eingereicht am 01. Februar 2018 mit dem Titel „PRIVACY-PROTECTED SELF SOVEREIGN IDENTITY FOR SECURE DEVICE ONBOARDING“; wobei die oben identifizierten vorläufigen Anmeldungen hiermit durch Bezugnahme vollständig aufgenommen werden.
TECHNISCHES GEBIET
Ausführungsformen, die hierin beschrieben sind, betreffen im Allgemeinen Datenkommunikationen und verknüpfte Gerätedatennetzwerke, und insbesondere Techniken für die Datenverarbeitung und Sicherheitsauthentifizierung für Geräte des Internets der Dinge (IoT) und Gerätnetzwerke, einschließlich Zero-Touch-Gerät-Onboarding unter Verwenden eines Authentifikators, der unter Verwenden eines Rendezvous-Service erhalten wird, und sicheres Gerät-Onboarding unter Verwenden einer Privatsphären-geschützten selbstverwalteten Identität (Privacy-Protected Self-Sovereign Identity).
ALLGEMEINER STAND DER TECHNIK
IoT-Geräte sind physische oder virtualisierte Objekte, die auf einem Netzwerk kommunizieren können, und die Sensoren, Aktuatoren und andere Eingabe-/Ausgabekomponenten beinhalten können, um Daten zu sammeln oder Handlungen von einer realen Umgebung auszuführen. IoT-Geräte können zum Beispiel Geräte mit niedriger Leistungsaufnahme beinhalten, die in alltäglichen Dingen eingebettet oder an ihnen angebracht sind, wie zum Beispiel Gebäuden, Fahrzeugen, Paketen usw., um ein zusätzliches Niveau an künstlicher Sinneswahrnehmung dieser Dinge bereitzustellen. IoT-Geräte wurden kürzlich beliebter, und daher haben sich Anwendungen, die diese Geräte verwenden, stark vermehrt.
Es wurden diverse Standards vorgeschlagen, um IoT-Geräte und IoT-Netzwerkverwendungsfälle effizienter zu vernetzen und zu betreiben. Diese beinhalten die Spezialisierung von Kommunikationsstandards, die von Gruppen, wie von dem Institute of Electrical and Electronics Engineers (IEEE) verteilt werden, und die Spezialisierung von Anwendungswechselwirkungsarchitektur- und Konfigurationsstandards, die von Gruppen wie der Open Connectivity Foundation (OCF) verteilt werden.
Figurenliste
In den Zeichnungen, die nicht zwingend maßstabgerecht gezeichnet sind, können gleiche Bezugszeichen ähnliche Komponenten in unterschiedlichen Ansichten beschreiben. Gleiche Bezugszeichen, die unterschiedliche Buchstabensuffixe aufweisen, können unterschiedliche Instanzen ähnlicher Komponenten darstellen. Einige Ausführungsformen sind beispielhaft und nicht einschränkend in den Figuren der begleitenden Zeichnungen veranschaulicht, in welchen:

1 eine Domänentopologie für jeweilige Internet-der-Dinge-Netzwerke (IoT-Netzwerke), die durch Links mit jeweiligen Gateways gekoppelt sind, gemäß einem Beispiel veranschaulicht.
2 ein Cloud-Computing-Netzwerk in Kommunikation mit einem Maschennetz aus IoT-Geräten, die als ein Fog-Gerät oder eine Fog-Plattform funktionieren, die mit einem Cloud-Computing-Netzwerk verbunden ist, gemäß einem Beispiel veranschaulicht.
3 und 4 Blockschaltbilder von Komponenten, die an Zero-Touch-Gerät-Onboarding beteiligt sind, gemäß jeweiligen Beispielen veranschaulichen.
5A bis 5E ein „Swim-Lane“-Nachrichtenübermittlungsdiagramm für Zero-Touch-Gerät-Onboarding gemäß einem Beispiel einer ersten Umsetzung veranschaulichen.
6A bis 6D ein „Swim-Lane“-Nachrichtenübermittlungsdiagramm für Zero-Touch-Gerät-Onboarding gemäß einem Beispiel einer zweiten Umsetzung veranschaulichen.
7 ein „Swim-Lane“-Nachrichtenübermittlungsdiagramm für eine Vorgehensweise zum Entdecken neuer Geräte gemäß einem Beispiel veranschaulicht.
8 ein „Swim-Lane“-Nachrichtenübermittlungsdiagramm zum Ausführen einer Zero-Touch-Inhabertransfertechnik, die in einer OCF-Umsetzung, die asymmetrische Schlüssel involviert, angewandt wird, gemäß einem Beispiel veranschaulicht.
9 ein „Swim-Lane“-Nachrichtenübermittlungsdiagramm zum Ausführen einer Zero-Touch-Inhabertransfertechnik, die in einer OCF-Umsetzung, die symmetrische Schlüssel involviert, angewandt wird, gemäß einem Beispiel veranschaulicht.
10 ein Ablaufdiagramm eines Verfahrens zum Ausführen einer Onboarding-Technik gemäß einem Beispiel veranschaulicht.
11 ein beispielhaftes Szenario für Onboarding, das mit einem Inhabergerät, Befugnis-Service und Zugriffsservice ausgeführt wird, gemäß einem Beispiel abbildet.
12 ein Blockchain-Umsetzungssystem gemäß einem Beispiel veranschaulicht.
13 ein Szenario, das eine Blockchain und Self-Sovereign-Identity-Management in einer IoT-Netzwerkbereitstellung involviert, gemäß einem Beispiel veranschaulicht.
14 ein Ablaufdiagramm veranschaulicht, das Self-Sovereign-Identity-Registrierung mit einer Blockchain gemäß einem Beispiel veranschaulicht.
15 einen Privacy-Protected Self-Sovereign-Identity-Registrierungsfluss mit einer Blockchain, die ein kryptografisches Protokoll umsetzt, gemäß einem Beispiel veranschaulicht.
16 ein Ablaufdiagramm veranschaulicht, das Self-Sovereign-Identity-Konfliktlösung mit einer Blockchain, ohne einen Privatsphären-geschützten Fluss gemäß einem Beispiel veranschaulicht.
17 ein Ablaufdiagramm veranschaulicht, das Self-Sovereign-Identity-Konfliktlösung mit einer Blockchain unter Verwenden eines Privatsphären-geschützten Flusses gemäß einem Beispiel veranschaulicht.
18 ein Ablaufdiagramm eines Verfahrens für Geräteattributregistrierung und -prüfung unter Verwenden einer Blockchain gemäß einem Beispiel veranschaulicht.
19 ein Blockschaltbild eines Netzwerks, das Kommunikation unter einer Anzahl von IoT-Geräten veranschaulicht, gemäß einem Beispiel veranschaulicht.
20 ein Blockschaltbild für eine beispielhafte IoT-Verarbeitungssystemarchitektur, auf der eine oder mehrere der Techniken (zum Beispiel Vorgänge, Prozesse, Verfahren und Methodologien), die hierin besprochen sind, ausgeführt werden können, veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden Verfahren, Konfigurationen und damit zusammenhängende Geräte für das Verarbeiten von Sicherheitskontexten in einer IoT-Vernetzungseinrichtung durch die Verwendung eines Zero-Touch-IoT-Gerät-Onboardings unter Verwenden eines Authentifikators, der von einem Rendezvous-Service erhalten wird, offenbart. Was den Kontext betrifft, involviert sicheres Gerät-Onboarding oft einen oder mehrere Kontaktpunkte, an welchen Sicherheitsinformationen konfiguriert werden, um eine Vielfalt von Isolationsbarrieren zu überwinden. Eine solche Barriere ist das Inhabernetzwerk, das in Übereinstimmung mit der Familie der IEEE 802.11-Standards (zum Beispiel Wi-Fi) arbeitet, die ein Wi-Fi Protected-Access-Passwort (WPA-Passwort) oder ein Standortzertifikat erfordern kann, um sich an einen Wi-Fi-Zugangspunkt (AP) anzuschließen.
IoT-Geräte durchlaufen gewöhnlich einen „Inbetriebnahme“- oder „Onboarding“-Prozess, um Vertrauen in das Gerät herzustellen und Betriebsbefugnisse zu beschaffen. Um das zu vollbringen, muss das neue Gerät an einen Inbetriebnahmeservice angeschlossen werden. Zugang zu dem Service sollte gesichert sein, um Denial-of-Service- und Protokoll attacken an dem Inbetriebnahmeprozess zu verhindern. Das Ermöglichen sicherer Inbetriebnahme involviert jedoch auch das Konfigurieren des Geräts für sicheren Zugang zu dem Inbetriebnahmeservice. IoT-Bereitstellungsszenarien können die Notwendigkeit involvieren, viele Geräte in Betrieb zu nehmen, wo kein ausreichendes IT-Personal zum rechtzeitigen Vollbringen der Aufgabe zur Verfügung steht. Angesichts der IoT-Netzwerke ist folglich sichere Zero-Touch-Inbetriebnahme ein wichtiges Problem.
Secure-Device-Onboard-Technology (SDO-Technologie), wie sie bei Umsetzungen der Intel Corporation in Santa Clara, Kalifornien, bereitgestellt wird, bietet eine Lösung für das Zero-Touch-Inbetriebnahmeproblem, die einen Cloud-gehosteten Rendezvous-Service (Rendezvous Service - RS) verwendet, um Geräte, die in Betrieb genommen werden sollen, mit einer Internetprotokoll-Adresse (IP-Adresse) des Servers zu versorgen, der zum Onboarden des jeweiligen Geräts befugt ist. Der Besitz einer IP-Adresse reicht jedoch nicht, um es dem neuen Gerät zu ermöglichen, sich sicher an den Onboarding-Server über ein Netzwerk mit kontrolliertem Zugang, wie einem mit WPA2-Schlüssel gesicherten Wi-Fi-Netzwerk, anzuschließen.
Das OCF-Owner-Transfer-Method (OCF-Inhabertransferverfahren - OTM) ist ein anderer Ansatz für die Gerätinbetriebnahme, der auf ein von dem Hersteller geliefertes Zertifikat oder einen eingebetteten PIN zurückgreift, das/der das Gerät bei dem Onboarding-Server authentifiziert.
Die Verwendung eines OTM setzt jedoch voraus, dass das Gerät bereits an ein Netzwerk (zum Beispiel ein Local Area Network (LAN)) angeschlossen ist, wobei ein IP-Multicast geliefert werden kann, und wobei das neue Gerät seinen Status als inbetriebnahmebereit melden kann.
Keiner dieser Ansätze setzt sich jedoch mit dem Problem des sicheren Verbindens des neuen Geräts mit einem Netzwerk-Inbetriebnahmeserver auseinander, ohne das Produktionsnetzwerk mit dem noch nicht vertrauenswürdigen Gerät zu exponieren, oder den Netzwerk-Inbetriebnahmeserver mit möglichen Denial-of-Service- oder Protokollattacken zu exponieren, während er auf Inbetriebnahmeanfragen wartet.
Um diesen Problemen zu begegnen, ist hierin eine Zero-Touch-Gerät-Onboarding-Technik beschrieben. Die Technik verwendet einen Intermediär (zum Beispiel einen Mediator), um Gäste-Wi-Fi-Befugnisse einzurichten, die für Zugang zu einem Rendezvous-Service verwendet werden. Das Gerät registriert eine Onboarding-Absicht bei dem Rendezvous-Service und empfängt Informationen für einen Onboarding-Server (zum Beispiel eine Internet-Protokoll-Adresse (IP-Adresse) für einen Onboarding-Service). Der Rendezvous-Service verständigt auch den Rendezvous-Service des Geräts über die Onboarding-Absicht des Geräts (zum Beispiel durch Bereitstellen des geräteigenen universellen eindeutigen Identifikators (Device Universal Unique Identifier - UUID) zu dem Onboarding-Service).Dann kontaktiert das Gerät wieder den Intermediär und stellt die Onboarding-Serveradresse (oder einen anderen Identifikator) gemeinsam mit seinem UUID bereit. Der Intermediär prüft dann unter Verwenden des UUID, dass der Onboarding-Service das Gerät erwartet und versieht die Geräte mit Netzwerkbefugnissen, die ausreichen, um den Onboarding-Service zu kontaktieren (zum Beispiel Befugnisse für ein Sandbox- oder ein sichereres Netzwerk als den vorhergehenden Gäste-Zugang). Das Gerät kann dann den Onboarding-Service unter Verwenden der neuen Wi-Fi-Zugangsbefugnisse kontaktieren und den Onboarding-Prozess abschließen (zum Beispiel unter Verwenden herkömmlicher IoT-Onboarding-Techniken).
Existierende Lösungen sind nicht fähig, ein Produktionsnetzwerk vor böswilligen Geräten, die sich als ein neues Gerät ausgeben, abzusichern. Anders als die hierin beschriebene Technik, können die existierenden Lösungen daher Denial-of-Service- oder Protokollattacken durch ein sich authentifizierendes neues Gerät erlauben. Zusätzliche Einzelheiten und Beispiele sowie Vorteile der sicheren OTM-Gerät-Onboarding-Techniken ergeben sich weiter aus den unten stehenden Beispielen.
Zusätzlich sind in der folgenden Beschreibung Verfahren, Konfigurationen und dazu gehörende Einrichtungen für eine IoT-Gerät-Self-Sovereign-Identity-Prüfung und Registrierung (SSI-Prüfung und Registrierung) durch die Verwendung von Blockchains und kryptografischen Protokollen offenbart. Die hierin beschriebenen Techniken stellen die Fähigkeit bereit, die Privatsphäre eines IoT-Geräts zu wahren, während es von einem Inhaber zu dem anderen bewegt wird; während hinsichtlich der Sicherheitsgewährleistung durch Erlauben prüfbarer Behauptungen, die es erlauben, Vertrauen hinsichtlich der Gerätidentität aufzubauen, kein Kompromiss eingegangen wird. Diese Umsetzung lässt sich auch derart erweitern, dass sie nicht nur auf einer einzigen Gerätidentität arbeitet, sondern auch für andere Werte von Gerätattributen und unterschiedliche Typen von Gerätattributen, wie Ort, Herausgeber, Herstellungsdatum und dergleichen, die für dieses Gerät eindeutig oder nicht eindeutig sein können, verwendet werden kann.
1 veranschaulicht eine beispielhafte Domänentopologie für jeweilige IoT-Netzwerke, die durch Links mit jeweiligen Gateways gekoppelt sind. Das IoT ist ein Konzept, bei dem eine große Anzahl von Computing-Geräten miteinander (und mit dem Internet) verschaltet ist, um Funktionalität und Datenerfassung an sehr niedrigen Niveaus bereitzustellen. Wie hierin verwendet, kann ein IoT-Gerät daher ein halbautomatisches Gerät aufweisen, das eine Funktion wie, unter anderem, ein Abtasten oder Steuern, in Kommunikation mit anderen IoT-Geräten und einem weiteren Netzwerk, wie dem Internet, ausführt.
IoT-Geräte sind oft hinsichtlich des Speichers, der Größe oder Funktionalität eingeschränkt, was es erlaubt, größere Anzahlen für ähnliche Kosten zu kleineren Anzahlen größerer Geräte bereitzustellen. Ein IoT-Gerät kann jedoch ein Smartphone, Laptopcomputer, Tablet-Computer oder PC oder ein anderes größeres Gerät sein. Ferner kann ein IoT-Gerät ein virtuelles Gerät sein, wie eine Anwendung auf einem Smartphone oder ein anderes Computing-Gerät. IoT-Geräte können IoT-Gateways beinhalten, die verwendet werden, um IoT-Geräte mit anderen IoT-Geräten sowie mit Cloud-Anwendungen zur Datenspeicherung, Prozesssteuerung und dergleichen zu koppeln.
Netzwerke aus IoT-Geräten können kommerzielle und Heimautomatisierungsgeräte, wie Wasserverteilungssysteme, Verteilungssysteme elektrischer Leistung, Rohrleitungssteuersysteme, Werksteuersysteme, Lichtschalter, Thermostate, Schlösser, Kameras, Alarme, Bewegungssensoren und dergleichen beinhalten. Die IoT-Geräte können durch entfernte Computer, Server und andere Systeme zugänglich sein, um zum Beispiel Systeme zu steuern oder auf Daten zuzugreifen.
Das zukünftige Wachstum des Internets und ähnlicher Netzwerke kann sehr große Anzahlen von IoT-Geräten involvieren. Folglich befasst sich in dem Kontext der Techniken, die hierin besprochen sind, eine Anzahl von Innovationen für solches zukünftiges Networking mit dem Bedarf für alle diese Schichten, ungehindert zu wachsen, angeschlossene Ressourcen zu erkennen und zugänglich zu machen und die Fähigkeit zu unterstützen, angeschlossene Ressourcen zu verbergen und abzuschotten. Eine beliebige Anzahl von Netzwerkprotokollen und Kommunikationsstandards kann verwendet werden, wobei jedes Protokoll und jeder Standard konzipiert ist, um sich mit spezifischen Zielsetzungen auseinanderzusetzen. Ferner gehören die Protokolle zu dem Fabric, das die für Menschen zugänglichen Dienste unterstützt, die ungeachtet des Orts, der Zeit oder des Raums arbeiten. Die Innovationen beinhalten Dienstbereitstellung und dazu gehörende Infrastruktur, wie Hardware und Software; Sicherheitsverbesserungen; und die Beschaffung von Diensten, die auf Servicequalitätbedingungen (Quality of Service - QoS) basieren, die in Serviceniveau- und Servicebereitstellungsvereinbarungen spezifiziert sind. Wie man versteht, weist die Verwendung von IoT-Geräten und -Netzwerken, wie denjenigen, die in den 1 und 2 eingeführt werden, eine Anzahl neuer Herausforderungen in einem heterogenen Konnektivitätsnetzwerk, das eine Kombination verdrahteter und drahtloser Technologien umfasst, auf.
1 stellt spezifisch eine vereinfachte Zeichnung einer Domänentopologie bereit, die für eine Anzahl von IoT-Netzwerken, die die IoT-Geräte 104 umfassen, mit den IoT-Netzwerken 156, 158, 160, 162, die durch Backbone-Links 102 mit jeweiligen Gateways 154 gekoppelt sind, verwendet werden kann. Eine Anzahl von IoT-Geräten 104 kann zum Beispiel mit einem Gateway 154 kommunizieren und miteinander durch das Gateway 154. Um die Zeichnung zu vereinfachen, wurde nicht jedes IoT-Gerät 104 oder jeder Kommunikationslink (zum Beispiel die Links 116, 122, 128 oder 132) bezeichnet. Die Backbone-Links 102 können eine beliebige Anzahl verdrahteter oder drahtloser Technologien beinhalten, einschließlich optischer Netzwerke, und können Teil eines Local-Area-Networks (LAN), eines Wide-Area-Network (WAN) oder des Internets sein. Zusätzlich erleichtern solche Kommunikationslinks optische Signalwege sowohl unter den IoT-Geräten 104 als auch den Gateways 154, einschließlich der Verwendung von MUXing-/deMUXing-Komponenten, die die Vernetzung diverser Geräte erleichtern.
Die Netzwerktopologie kann eine beliebige Anzahl von IoT-Netzwerk-Typen beinhalten, wie ein Maschennetzwerk, das mit dem Netzwerk 156 bereitgestellt ist, unter Verwendung von Bluetooth-Low-Energy-Links (BLE-Links) 122. Andere Typen von IoT-Netzwerken, die anwesend sein können, beinhalten ein drahtloses Local-Area-Network (Wireless Local Area Network - WLAN) 158, das verwendet wird, um mit den IoT-Geräten 104 durch IEEE 802.11-Links (Wi-Fi®) 128 zu kommunizieren, ein zelluläres Netzwerk 160, das verwendet wird, um mit IoT-Geräten 104 durch ein zelluläres LTE/LTE-A-Netzwerk (4G) oder 5G-Netzwerk zu kommunizieren, und ein Low-Power-Wide-Area-Netzwerk (LPWA-Netzwerk) 162, zum Beispiel ein LPWA-Netzwerk, das mit der LoRaWan-Spezifikation kompatibel ist, die von der LoRa-Allianz veröffentlicht wird, oder ein IPv6 über Low-Power-Wide-Area-Networks-Netzwerk (LPWAN-Netzwerk), das mit einer Spezifikation kompatibel ist, die von der Internet Engineering Task Force (IETF) veröffentlicht wird. Ferner können die jeweiligen IoT-Netzwerke mit einem externen Netzwerk-Provider (zum Beispiel einem Tier-2- oder Tier-3-Provider) kommunizieren, indem eine beliebige Anzahl von Kommunikationslinks verwendet wird, wie ein zellulärer LTE-Link, ein LPWA-Link oder ein Link basierend auf dem IEEE 802.15.4-Standard, wie Zigbee®. Die jeweiligen IoT-Netzwerke können auch unter Verwendung einer Vielfalt von Netzwerk- und Internetanwendungsprotokollen, wie das Constrained Application Protocol (CoAP) arbeiten. Die jeweiligen IoT-Netzwerke können auch mit Koordinatorgeräten integriert werden, die eine Reihe von Links bereitstellen, die einen Cluster-Tree vernetzter Geräte und Netzwerke bildet.
Jedes dieser IoT-Netzwerke kann Gelegenheiten für neue technische Merkmale, wie die hierin beschriebenen, bereitstellen. Die verbesserten Technologien und Netzwerke können exponentielles Wachstum von Geräten und Netzwerken, einschließlich der Verwendung von IoT-Netzwerken in „Fog“-Geräten oder -Systemen ermöglichen. Mit der Zunahme der Verwendung solcher verbesserter Technologien, können die IoT-Netzwerke zum Selbstmanagement, zur funktionalen Entwicklung und Zusammenarbeit entwickelt werden, ohne einen direkten menschlichen Eingriff zu benötigen. Die verbesserten Technologien können es IoT-Netzwerken sogar ermöglichen, ohne zentralisierte gesteuerte Systeme zu funktionieren. Die hierin beschriebenen verbesserten Technologien können folglich verwendet werden, um Netzwerkmanagement- und Betriebsfunktionen weit über aktuelle Umsetzungen hinaus zu automatisieren und zu verbessern.
Bei einem Beispiel können die Kommunikationen zwischen den IoT-Geräten 104, wie über die Backbone-Links 102, durch ein dezentralisiertes System zur Authentifizierung, Zulassung und Kontenführung (Authentication, Authorization, and Accounting - AAA) geschützt werden. In einem dezentralisierten AAA-System können verteilte Zahlungs-, Kredit-, Audit-, Zulassungs- und Authentifizierungssysteme über eine vernetzte heterogene Netzwerkinfrastruktur umgesetzt werden. Das ermöglicht es Systemen und Netzwerken, sich zu autonomen Vorgängen zu bewegen. Bei diesen Typen autonomer Vorgänge können Maschinen sogar Personalverträge abschließen und Partnerschaften mit anderen Maschinennetzwerken aushandeln. Das kann das Verwirklichen gegenseitiger Zielsetzungen und ausgewogener Servicebereitstellung gegen umrissene, geplante Serviceniveauvereinbarungen ermöglichen sowie Lösungen beisteuern, die Zählung, Messung, Rückverfolgbarkeit und Verfolgbarkeit erzielen können. Das Schaffen neuer Bereitstellungskettenstrukturen und Verfahren kann es ermöglichen, ohne menschliche Beteiligung eine Vielzahl von Diensten zu schaffen, nach Wert zu durchforschen und zu kollabieren.
Solche IoT-Netzwerke können ferner durch die Integration sensorischer Technologien, wie Schall, Licht, elektronischer Austausch, Gesichts- und Mustererkennung, Geruch, Schwingung, in die autonomen Organisationen unter den IoT-Geräten verbessert werden. Die Integration sensorischer Systeme kann systematische und autonome Kommunikation und Koordination von Servicebereitstellung gegen vertragliche Servicezielsetzungen, Orchestrierung und QoS-basiertes Schwärmen und Fusion von Ressourcen ermöglichen. Einige der individuellen Beispiele netzwerkbasierter Ressourcenverarbeitung beinhalten Folgendes.
Das Maschennetzwerk 156 kann zum Beispiel durch Systeme verbessert werden, die Inline-Daten-zu-Informationsumwandlungen ausführen. Sich selbst bildende Ketten aus Verarbeitungsressourcen, die ein Multi-Link-Netzwerk umfassen, können zum Beispiel die Umwandlung von Rohdaten in Informationen auf eine effiziente Art und die Fähigkeit, unter Werten und Ressourcen und dem assoziierten Management jedes zu unterscheiden, bereitstellen. Des Weiteren können die zweckdienlichen Komponenten von Infrastruktur und auf Ressourcen basierenden Vertrauens- und Serviceindizien eingefügt werden, um die Datenintegrität, -qualität und -gewährleistung zu verbessern und eine Metrik der Datenvertrauenswürdigkeit bereitzustellen.
Das WLAN-Netzwerk 158 kann zum Beispiel Systeme verwenden, die Standard-Umwandlung ausführen, um Multi-Standard-Konnektivität bereitzustellen, was es IoT-Geräten 104 ermöglicht, unterschiedliche Protokolle zum Kommunizieren zu verwenden. Weitere Systeme können nahtlose gegenseitige Vernetzbarkeit über eine Multi-Standard-Infrastruktur, die sichtbare Internet-Ressourcen und verborgene Internet-Ressourcen umfasst, bereitstellen.
Kommunikationen in dem zellularen Netzwerk 160 können zum Beispiel durch Systeme verbessert werden, die Daten transferieren, Kommunikationen zu entfernteren Geräten erweitern oder beides. Das LPWA-Netzwerk 162 kann Systeme beinhalten, die Nicht-Internet-Protokoll (IP-Protokoll) zu IP-Verbindungen, Adressieren und Routen ausführen. Ferner kann jedes der IoT-Geräte 104 den entsprechenden Transceiver für Wide-Area-Kommunikationen mit diesem Gerät beinhalten. Ferner kann jedes IoT-Gerät 104 andere Transceiver zum Kommunizieren unter Verwenden zusätzlicher Protokolle und Frequenzen beinhalten. Das wird in Bezug auf die Kommunikationsumgebung und Hardware eines IoT-Verarbeitungsgeräts, das in den 19 und 20 abgebildet ist, weiter besprochen.
Schließlich können Cluster aus IoT-Geräten ausgestattet sein, um mit anderen IoT-Geräten sowie mit einem Cloud-Netzwerk zu kommunizieren. Das kann es den IoT-Geräten ermöglichen, ein Ad-Hoc-Netzwerk zwischen den Geräten zu bilden, das es ihnen erlaubt, als ein einziges Gerät zu funktionieren, das ein Fog-Gerät, eine Fog-Plattform oder ein Fog-Netzwerk genannt werden kann. Diese Konfiguration ist unten unter Bezugnahme auf 2 weiter besprochen.
2 veranschaulicht ein Cloud-Computing-Netzwerk in Kommunikation mit einem Maschennetzwerk aus IoT-Geräten (Geräte 202), das als eine Fog-Plattform in einem vernetzten Szenario arbeitet. Das Maschennetzwerk aus IoT-Geräten kann ein Fog-Netzwerk 220 genannt werden, das aus einem Netzwerk von Geräten, die an der Edge der Cloud 200 arbeiten, gebildet ist. Um das Diagramm zu vereinfachen, wurde nicht jedes IoT-Gerät 202 markiert.
Das Fog-Gerät 220 kann als ein massiv verschaltetes Netzwerk betrachtet werden, wobei eine Anzahl von IoT-Geräten 202 miteinander in Kommunikation steht, zum Beispiel durch die Funkverbindungen 222. Das Fog-Netzwerk 220 kann eine horizontale, physische oder virtuelle Ressourcenplattform bilden, die als zwischen IoT-Edge-Geräten und Cloud- oder Datencentern resident betrachtet werden kann. Ein Fog-Netzwerk kann bei einigen Beispielen vertikal isolierte, latenzempfindliche Anwendungen durch geschichtetes, föderiertes oder verteiltes Computing, Speichern und Netzwerkkonnektivitätsvorgänge unterstützen. Ein Fog-Netzwerk kann jedoch auch verwendet werden, um Ressourcen und Dienste an und unter Edge und der Cloud zu verteilen. Verweise in dem vorliegenden Dokument auf „Edge“, „Fog“ und „Cloud“ sind nicht zwingend diskret oder einander ausschließend.
Als ein Beispiel kann das Fog-Netzwerk 220 erleichtert werden, indem eine Vernetzungsspezifikation verwendet wird, die von der Open Connectivity Foundation™ (OCF) herausgegeben wurde. Dieser Standard erlaubt es Geräten, einander zu erkennen und Kommunikationen für Vernetzen aufzubauen. Andere Vernetzungsprotokolle können auch verwendet werden, einschließlich unter anderen, zum Beispiel das Optimized Link State Routing-Protokoll (OLSR-Protokoll), das Better Approach To Mobile Ad-Hoc Networking-Routingprotokoll (B.A.T.M.A.N.-Routingprotokoll) oder das OMA Lightweight M2M-Protokoll (LWM2M-Protokoll).
Drei Typen von IoT-Geräten 202 sind in diesem Beispiel gezeigt, Gateways 204, Datenaggregatoren 226 und Sensoren 228, obwohl beliebige Kombinationen aus IoT-Geräten 202 und Funktionalität verwendet werden können. Die Gateways 204 können Edge-Geräte sein, die Kommunikationen zwischen der Cloud 200 und dem Fog-Netzwerk 220 bereitstellen, und die auch Backend-Prozessfunktion für Daten bereitstellen können, die von Sensoren 228 erhalten werden, wie Bewegungsdaten, Flussdaten, Temperaturdaten und dergleichen. Die Datenaggregatoren 226 können Daten aus einer beliebigen Anzahl von Sensoren 228 sammeln und die Backend-Prozessfunktion für die Analyse ausführen. Die Resultate, Rohdaten oder beide können zu der Cloud 200 durch die Gateways 204 weitergegeben werden. Die Sensoren 228 können Voll-IoT-Geräte 202 sein, die zum Beispiel sowohl zum Sammeln von Daten als auch zum Verarbeiten der Daten fähig sind. In einigen Fällen können die Sensoren 228 in ihrer Funktionalität eingeschränkter sein, zum Beispiel Sammeln der Daten und Ermöglichen für die Datenaggregatoren 226 oder Gateways 204, die Daten zu verarbeiten.
Kommunikationen von einem IoT-Gerät 202 können entlang einem zweckdienlichen Weg (zum Beispiel einem zweckdienlichsten Weg) zwischen beliebigen der IoT-Geräte 202 weitergegeben werden, um die Gateways 204 zu erreichen. In diesen Netzwerken stellt die Anzahl von Vernetzungen substantielle Redundanz bereit, was das Warten der Kommunikationen sogar mit dem Verlust von einer Anzahl von IoT-Geräten 202 ermöglicht. Ferner kann die Verwendung eines Maschennetzwerks IoT-Geräten 202, die sehr niedrige Leistungsaufnahme aufweisen oder sich in einer Entfernung von der Infrastruktur, die zu verwenden ist, befinden, ermöglichen, da der Bereich zum Verbinden mit einem anderen IoT-Gerät 202 viel kleiner sein kann als der Bereich zum Verbinden der Gateways 204.
Das Fog-Netzwerk 220, das von diesen IoT-Geräten 202 bereitgestellt wird, kann Geräten in der Cloud 200, wie einem Server 206, als ein einziges Gerät präsentiert werden, das sich an dem Edge der Cloud 200 befindet, zum Beispiel ein Fog-Netzwerk, das als ein Gerät oder eine Plattform arbeitet. Bei diesem Beispiel können Warnungen, die von der Fog-Plattform kommen, gesendet werden, ohne als von einem spezifischen IoT-Gerät 202 innerhalb des Fog-Netzwerks 220 kommend identifiziert zu werden. Auf diese Art kann das Fog-Netzwerk 220 als eine verteilte Plattform betrachtet werden, die Computing- und Speicherressourcen bereitstellt, um Verarbeitung oder datenintensive Aufgaben auszuführen wie, unter anderen, Datenanalyse, Datenaggregation und Machine Learning.
Bei einigen Beispielen können die IoT-Geräte 202 unter Verwenden eines zwingenden Programmstils konfiguriert werden, zum Beispiel mit jedem IoT-Gerät 202, das eine spezifische Funktion und Kommunikationspartner aufweist. Die IoT-Geräte 202, die die Fog-Vorrichtung bilden, können jedoch in einem deklarativen Programmierstil programmiert sein, der es den IoT-Geräten 202 erlaubt, ihre Vorgänge und Kommunikationen neu zu konfigurieren, um zum Beispiel erforderliche Ressourcen als Reaktion auf Bedingungen, Abfragen und Geräteausfälle zu bestimmen. Als ein Beispiel kann eine Abfrage von einem Benutzer, der sich an dem Server 206 befindet, über die Vorgänge eines Subsatzes von Ausstattung, die von den IoT-Geräten 202 überwacht wird, darin resultieren, dass in dem Fog-Netzwerk-Gerät 220 die IoT-Geräte 202 wie besondere Sensoren 228, die erforderlich sind, um die Abfrage zu beantworten. Die Daten aus diesen Sensoren 228 können dann durch eine beliebige Kombination der Sensoren 228, Datenaggregatoren 226 oder Gateways 204 aggregiert und analysiert werden, bevor sie von dem Fog-Netzwerk 220 zu dem Server 206 zur Beantwortung der Abfrage gesendet werden. Bei diesem Beispiel können IoT-Geräte 202 in dem Fog-Netzwerk 220 die verwendeten Sensoren 228 basierend auf der Abfrage auswählen, wie Hinzufügen von Daten aus den Flusssensoren oder Temperatursensoren. Falls ferner einige der IoT-Geräte 202 nicht betriebsfähig sind, können andere IoT-Geräte 202 in dem Fog-Netzwerk 220 analoge Daten, falls verfügbar, bereitstellen.
In einer OCF-Netzwerkarchitektur können physische Entitäten in der wirklichen Welt (zum Beispiel ein Temperatursensor) als Ressourcen exponiert werden. Wechselwirkungen mit Entitäten werden durch Ressourcendarstellungen umgesetzt, die Vorgänge verwenden, die die Representational-State-Transfer-Architekturen (REST-Architekturen) einhalten, z. B. RESTful-Wechselwirkungen. Die Entitäten werden daher als Ressourcen dargelegt, jeweils mit ihren eindeutigen Identifikatoren (URIs) und Unterstützungsschnittstellen, die RESTful-Vorgänge auf ihren Ressourcen ermöglichen. Ein Client initiiert einen RESTful-Vorgang auf einem Server. Der Client ist der Initiator und der Server ist ein Responder. Ein beliebiges Gerät kann als ein Client wirken, um einen RESTful-Vorgang zu initiieren, oder irgendeine andere Vorrichtung, die als ein Server dient. Daher kann die Aufgabe eines Geräts als ein Client oder Server unter vielen Umständen austauschbar sein. Jedes Gerät, das eine Ressource exponiert, ist definitionsgemäß ein Server. Jeder RESTful-Vorgang enthält alle Informationen, die erforderlich sind, um den Kontext des Vorgangs zu verstehen, und wird von einem Satz generischer Vorgänge unterstützt (zum Beispiel ANLEGEN, ABRUFEN, AKTUALISIEREN, LÖSCHEN UND VERSTÄNDIGEN (CREATE, RETRIEVE, UPDATE, DELETE and NOTIFY - CRUDN)).
Wie hierin besprochen, können die folgenden Techniken in Zusammenhang mit der Verwendung diverser OCF-Dienste und Transaktionen umgesetzt werden, einschließlich DOTS (auch als DOXS, Device Owner Transfer Service (Gerätinhabertransferdienst) bekannt). Bei einem weiteren Beispiel können die folgenden Techniken in Verbindung mit Onboarding-Funktionalität, die von einem OCF-Onboarding-Tool (OBT) bereitgestellt wird, umgesetzt werden. In dem Kontext einer OCF-Umsetzung ist ein OBT eine logische Entität innerhalb eines spezifischen IoT-Netzwerks, die Inhaberschaft für ein spezifisches Gerät erstellt und hilft, das Gerät innerhalb dieses Netzwerks in einen Betriebszustand zu bringen. Ein typisches OBT kann zum Beispiel DOTS, AMS (Access Management Service - Zugangsmanagementdienst) und CMS-Funktionalität (Credential Management Service - Befugnis-Management Service) umsetzen.
In den folgenden Absätzen werden Beispiele eines Zero-Touch-Onboarding-Verfahrens (eines Inhabertransferverfahrens) besprochen, das es einem neuen Gerät ermöglicht, mit einem Mediator (zum Beispiel einem OCF-Mediator) in Wechselwirkung zu treten, um Netzwerkdetails (zum Beispiel Wi-Fi-Easy-Setup-Values) zu erhalten. Diese Netzwerkdetails werden dann verwendet, um es dem Gerät zu ermöglichen, die Verbindung mit einem Cloud-Service herzustellen, der eine Rendezvous-Stelle ist, an der das neue Gerät und der erwartete Inhaber (OCF DOTS) Verbindungsinformation vereinbaren, die es dem Gerät und dem Onboarding-Service erlaubt, sich direkt zu verbinden. Ferner kann ein Inhabermanifest von dem Gerät verwendet werden, um zu prüfen, dass die Inhaberdomäne (zum Beispiel die DOTS-Domäne) der beabsichtigte Gerätinhaber ist.
Bei diesen Beispielen können SDO und OCF-OTM-Ansätze unter Verwenden eines Ansatzes in zwei Schritten zum Einführen des neuen Geräts bei dem Inbetriebnahmeserver integriert werden. Bei einer Umsetzung besteht der erste Schritt darin, ein teilweises OCF-Onboarding auszuführen, das verfügbaren eingebetteten PIN, Herstellerzertifikat oder einfach „Just Works“-Diffie-Hellman-Austausch nutzt, um eine sichere Verbindung unter Verwenden einer Softwarezugangspunktverbindung (SoftAP-Verbindung) zu einem mobilen (zum Beispiel nicht vertrauenswürdigen) Mediator herzustellen. Der Mediator stellt Wi-Fi-Einstellungen, die für das Erwerben eines „Gast“-Zugangs zu dem Internet geeignet sind, bereit. Das Gastnetzwerk ist von dem Produktionsnetzwerk isoliert. Mit Zugang zu dem Internet wird der SDO-Rendezvous-Service verwendet, um die Onboarding-Absicht des Geräts zu registrieren; das Gerät weiß jedoch nicht, welchen Onboarding-Server es verwenden soll. Die SDO-Komponenten liefern eine IP-Adresse des beabsichtigten Onboarding-Servers, wenn der Onboarding-Server seine Verfügbarkeit bei dem Rendezvous-Service kundtut. Das Gerät kennt auch seinen Plattform-UUID, der in dem Gerät von dem Gerätehersteller eingebettet wurde. Das Gerät verwendet dann (bei dem zweiten unten stehenden Schritt) diese IP-Adresse und UUID, um ein zweites Mal bei dem Mediator-Service zu authentifizieren, der prüft, dass der Onboarding-Server eine Verbindung von dem neuen Gerät erwartet.
Der zweite Schritt kann dann involvieren, dass das Gerät einen SoftAP aktiviert, um es dem Mediator zu ermöglichen, sich mit dem Gerät zu verbinden, um die IP-Adresse und Plattform-UUID zu erheben. Der Mediator kann die SoftAP-Verbindung trennen und eine sichere Verbindung zu dem AP des Netzwerks öffnen (oder kann zum Verbinden eine zweite Verbindung-Ressource verwenden). Der Mediator verständigt den Onboarding-Server (zum Beispiel unter Verwenden der IP-Adresse, um eine Route zu dem Host zu finden) und prüft, dass sich der Plattform-UUID unter denen, die von dem Rendezvous-Service beschrieben werden, befindet.
Mit dieser Umsetzung kann der Mediator das Gerät konfigurieren, um mit einem Sandbox-Netzwerk (zum Beispiel Local-Area-Network, LAN) zu verbinden, das von dem Produktionsnetzwerk isoliert aber für den Onboarding-Server verfügbar ist. Das neue Gerät verwendet die IP-Adresse, die von dem Rendezvous-Service erhalten wird, um sich mit dem Onboarding-Server zu verbinden. Das SDO-Protokoll kann verwendet werden, um den Inhabertransfer abzuschließen, aber an diesem Punkt ist eventuell die Beschaffung noch nicht abgeschlossen. Der Onboarding-Server stellt dann lokale Befugnisse bereit, die es dem Gerät ermöglichen, sich wieder mit dem Produktionsnetzwerk zu verbinden, wo die Gerät-Bereitstellung sicher abgeschlossen werden kann.
Diese Technik ermöglicht es dem neuen Gerät, sicheren Zugang zu einem (zum Beispiel Isolations-) Gast-Wi-Fi-Netzwerk zu erhalten, indem verhindert wird, dass das sich möglicherweise fehlverhaltende neue Gerät eine Bedrohung für das Produktionsnetzwerk (indem es eine Inbetriebnahme versucht) darstellt. Ein zweiter Versuch, die Verbindung mit einem Isolations-Wi-Fi-Netzwerk herzustellen, wird gestattet, nachdem das Gerät die richtige IP-Adresse und Plattform-UUID bei einem Mediator bereitgestellt hat, der diese Information ebenfalls kennt. Der Mediator konfiguriert die Wi-Fi-Parameter zu dem zweiten Isolationsnetzwerk. Das neue Gerät hat keinen Zugang zu dem Produktionsnetzwerk, kann aber Zugang zu dem Onboarding-Server erhalten. Falls jedoch das neue Gerät die erwartete UUID und die richtige IP-Adresse nicht hat, kann der Onboarding-Server diese Anfrage handhaben (indem er zum Beispiel die Anfrage wie eine mögliche Denial-of-Service-Attacke behandelt). Beim Abschließen des zweiten Schritts erhält das Gerät neue Befugnisse und Wi-Fi-Konfigurationsdetails, die für eine sichere Verbindung mit dem Produktions-Wi-Fi-Netzwerk erforderlich sind. Bei einem Beispiel kann eine Zufalls-Nonce zu dem Rendezvous-Service geliefert werden, wobei das neue Gerät die 3-Tupel (UUID, IP-Adresse, Nonce) als die Antwort auf eine Authentifizierungs-Challenge präsentiert, um die Sicherheit weiter zu erhöhen.
3 veranschaulicht ein Blockschaltbild von Komponenten, die an Zero-Touch-Gerät-Onboarding beteiligt sind, gemäß einem ersten Beispiel. Die Komponentenkonfiguration, die in 3 veranschaulicht ist, kann eine erste Umsetzung einer Zero-Touch-Inhabertransferverfahren-Onboarding-Technik (ZTOTM-Onboarding-Technik) genannt werden, die spezifische Schnittstellen (A, B und C, die unten besprochen sind) einsetzt. Es ist klar, dass die diversen Dienste und Entitäten auf demselben oder getrennten Knoten bei diversen Typen eines Edge-, Fog- oder IoT-Netzwerks instanziiert werden können, wobei die Knoten Hardware- und Softwareinstanzen, die konfiguriert sind, um den Service zu leisten, beinhalten.
Bei einem Beispiel konfiguriert der Mediator-Service 320 ein Neues Gerät 310 mit Wi-Fi-Konfigurationsparametern (oder anderen Konfigurationsparametern eines verdrahteten oder drahtlosen Netzwerks), die es dem Neuen Gerät 310 ermöglichen, sich direkt mit einem Netzwerkzugangspunkt (nicht gezeigt) zu verbinden. Der Mediator-Service 320 beruht zum Beispiel auf einer SoftAP-Technologie (oder einer ähnlichen Technologie), die in dem Neuen Gerät 310 verfügbar ist, die es dem Mediator-Service 320 ermöglicht, das Neue Gerät 310 zu verbinden, während vermieden wird, dass er in dem Nachrichtenpassageweg oder Datenweg des Neuen Geräts 310 involviert wird. Das Neue Gerät 310 führt dann eine Kombination von Secure-Device-Onboard-Vorgängen (SDO-Vorgängen) und OCF-Inhabertransferverfahrensvorgängen (OTM-Vorgängen) aus (zum Beispiel über den Device Owner Transfer Service (DOTS) 330), um den „Zero-Touch“-Onboarding-Prozess abzuschließen.
Bei einem Beispiel beinhaltet die ZTOTM-Architektur, die in 3 abgebildet ist, das Neue Gerät 310, drei Dienste (DOTS 330, Mediator-Service 320 und Rendezvous-Service 340), fünf Schnittstellen (IF_A 305, IF_B 315, IF_C 325, IF_WES 345, and ZTOTM 335) sowie eine Manifestdatei 350, die von dem Gerätehersteller oder der Bereitstellungskette 360 erhalten wird. Jedes Element der Architektur ist wie folgt beschrieben:
Neues Gerät 310 - Die physische Plattform, die das Gerät (zum Beispiel ein OCF-Gerät) für das Onboarding hostet.
Mediator-Service (MS) 320 - Der Netzwerkdienst (zum Beispiel OCF-Service), der das neue Gerät mit Konnektivitätsparametern konfiguriert.
Gerätinhabertransferdienst (DOTS) 330 - Der Netzwerkdienst (zum Beispiel OCF-Service), der die Zero-Touch-OTM-Vorgänge umsetzt und mit dem Rendezvous-Service 340 und dem Neuen Gerät 310 eine Schnittstelle bildet.
Rendezvous-Service 340 - Der noch nicht vertrauenswürdige Cloudgehostete Service wirkt als ein Treffpunkt für das Neue Gerät 310 und den DOTS 330. Der Rendezvous-Service 340 koordiniert das Herstellen einer direkten Verbindung zwischen dem Neuen Gerät 310 und dem DOTS 330. Der Rendezvous-Service 340 führt das Abbilden von Plattform-UUIDs und Domäneninhabern.
Manifest 350 - Die Datei, die eine Reihe digitaler Signaturen enthält, die die Herkunft der Bereitstellungskette der Plattform, die das Neue Gerät 310 hostet, bescheinigt. Bei diversen Beispielen kann das Manifest als eine Datei (oder Dateien) auf einem oder mehreren Knoten gespeichert (oder bereitgestellt) werden.
Schnittstelle A (IF A) 305 - Die Schnittstelle zwischen dem DOTS 330 und dem Rendezvous-Service 340, die: (1) es dem DOTS 330 erlaubt, sich selbst bei dem Rendezvous-Service 340 zu identifizieren; (2) verwendet wird, um die DOTS-Konnektivitätskonfiguration, die von dem Neuen Gerät 310 zu verwenden ist, zu registrieren, um den Onboarding-Prozess abzuschließen; und (3) es dem DOTS 330 erlaubt, den Plattform-UUID zu erhalten, der dem Gerät, das eingegliedert werden soll, entspricht (zum Beispiel Neues Gerät 310).
Schnittstelle B (IF_B) 315 - Die Schnittstelle zwischen dem Neuen Gerät 310 und dem Rendezvous-Service 340, die: (1) es dem Neuen Gerät 310 erlaubt, sich selbst bei dem Rendezvous-Service 340 unter Verwenden seines Plattform-UUID zu identifizieren; und (2) es dem Neuen Gerät 310 erlaubt, DOTS-Konnektivitätskonfigurationsinformation von dem Rendezvous-Service 340 zu erhalten, die Verbindungsparameter zum Verbinden mit dem DOTS 330 beschreibt.
Schnittstelle C (IF_C) 325 - Die Schnittstelle zwischen dem Neuen Gerät 310 und dem DOTS 330, die: (1) Vertrauen in das Neue Gerät 310 durch den DOTS 330 basierend auf einem vom Hersteller eingebetteten Schlüssel herstellt; (2) Vertrauen in den DOTS 330 durch das Neue Gerät 310 basierend auf einem Manifest herstellt, das von der Bereitstellungskette 360 aufgebaut wird; und (3) lokale Befugnisse erstellt, die zum Abschließen des Onboarding verwendet werden.
Schnittstelle WES (IF WES) 345 - Die Schnittstelle zwischen dem Neuen Gerät 310 und dem Mediator-Service 320, die lokalisierte Netzwerkkonnektivitätsparameter konfiguriert, die ausreichen, um es dem Neuen Gerät 310 zu ermöglichen, eine noch nicht vertrauenswürdige Verbindung mit dem Rendezvous-Service 340 herzustellen. Mit Verwendung der IF_WES-Schnittstelle 345 wird das Neue Gerät 310 von dem Mediator-Service 320 erkannt und unter Verwenden der Soft-Zugangspunktschnittstelle (SoftAP) des Geräts verbunden. Der Mediator-Service 320 erkennt, dass das Gerät die Zero-Touch-OTM-Vorgehensweise unterstützt, und konfiguriert Einstellungen, die es dem Gerät ermöglichen, sich mit dem Rendezvous-Service 340 zu verbinden.
ZTOTM-Schnittstelle 335 - Die Schnittstelle zwischen dem Neuen Gerät 310 (zum Beispiel in der Kapazität eines OCF-Geräts) und dem DOTS 330, die das Onboarding und anfängliche Bereitstellung (zum Beispiel OCF-Onboarding und anfängliche Bereitstellung) abschließt.
Bei dem Beispiel, das in 3 abgebildet ist, hängt die ZTOTM-Vorgehensweise von dem erfolgreichen Abschluss von Kommunikationen über die IF_C-Schnittstelle ab, die weiter von erfolgreichem Abschluss der Kommunikationen über die IF_A- 305, IF_B- 315 und IF_WES-Schnittstelle 345 abhängt. Unter Rückkehr zu dem Datenfluss, der in 3 abgebildet ist, mit Verwendung der ZTOTM-Schnittstelle 335, verwendet das Neue Gerät 310 Information, die von der IF_WES-Schnittstelle 345 geliefert wird, um die IF_B-Schnittstelle 315 aufzurufen. Beim Abschließen der IF_B-Kommunikation kontaktiert das Neue Gerät 310 den DOTS 330 über die IF_C-Schnittstelle 325. Der DOTS 330 verwendet die IF_A-Schnittstelle 305, um es der IF_B-Schnittstelle 315 zu ermöglichen, abzuschließen und den Onboarding-UUID zu erhalten, der dem Neuen Gerät 310 entspricht. Das Neue Gerät 3 10 kontaktiert den DOTS 330 über die IF_C-Schnittstelle 325, wenn die Kommunikationen der IF_A-Schnittstelle 305 und der IF_B-Schnittstelle 315 abgeschlossen sind.
Während der IF_C-Kommunikationen stellt der Domäneninhaber Vertrauen in die Plattform, die das Neue Gerät 310 hostet, her, und das Neue Gerät 310 stellt Vertrauen in den Domäneninhaber her. Vor dem Abschließen der IF C-Kommunikationen, erstellt der Inhaber Befugnisse für IF_ZTOTM-Schnittstelle 335. Diese können symmetrisch, asymmetrisch oder beides sein. Die IF_C-Schnittstelle 325 schließt dann ab (schließt zum Beispiel).
Das Neue Gerät 310 geht auf den RF_OTM-Gerätzustand (falls erforderlich) über. Der DOTS 330 erkennt das neue Gerät durch Finden aller neuen Geräte, die Zero-Touch-OTM unterstützen. Der DOTS 330 wählt Zero-Touch-OTM aus und stellt eine sichere Verbindung unter Verwenden der Befugnisse her, die während der IF_C-Kommunikationen erstellt wurden. Bei einem Beispiel kann das Neue Gerät 310 den Zero-Touch-Onboarding-UUID, der mit dem Manifest 350 geliefert wird, als seine zeitweilige deviceuuid verwenden.
4 veranschaulicht ein Blockschaltbild von Komponenten, die an Zero-Touch-Gerät-Onboarding beteiligt sind, gemäß einem zweiten Beispiel. Die Komponentenkonfiguration, die in 4 veranschaulicht ist, kann eine zweite Umsetzung einer ZTOTM-Onboarding-Technik genannt werden, die Interoperabilität durch spezifische Schnittstellen (WES- und ZTOTM), die unten besprochen sind, bereitstellt.
Bei diesem Beispiel sind die Schnittstellen IF_A 405, IF_B 445 und IF_C 425 nicht ausdrücklich definiert oder auf OCF-Interoperabilität beschränkt. (Stattdessen kann Interoperabilität durch Referenzcode oder andere Mechanismen erzielt werden). Bei diesem Beispiel ermöglichen jedoch die Schnittstellen IF_WES 445 und ZTOTM 435 OCF-Interoperabilität basierend auf den folgenden Merkmalen:
Die Schnittstelle WES (IF_WES) 445. Bei einem Beispiel wird das Neue Gerät 410 von einem Mediator-Service 420 (zum Beispiel einem OCF-Mediator-Service) erkannt, der das Neue Gerät 410 unter Verwenden der Softzugangspunkt-Schnittstelle (SoftAP-Schnittstelle) verbindet. Der Mediator-Service 420 erkennt, dass das Neue Gerät 410 Zero-Touch-OTM unterstützt, und konfiguriert Einstellungen, die es dem Gerät ermöglichen, sich mit dem Rendezvous-Service 440 zu verbinden.
Die Schnittstelle ZTOTM 435. Bei einem Beispiel verwendet das Neue Gerät 410 Information, die von der IF_WES 445 geliefert wird, um die IF_B-Schnittstelle 445 aufzurufen. Bei Abschluss der IF B 445, kontaktiert das Gerät den DOTS 430 über die IF_C 425. Der DOTS 430 verwendet die IF_A 405, um es der IF_B 445 zu ermöglichen, abzuschließen und den Onboarding-UUID zu erhalten, der dem Neuen Gerät 410 entspricht. Das Neue Gerät 410 kontaktiert den DOTS 430 über die IF_C 425, wenn die IF_A 405 und die IF_B 445 abgeschlossen sind. Das Neue Gerät 410 geht dann auf den RF_OTM-Gerätzustand (falls erforderlich) über. Der DOTS 430 erkennt das neue Gerät 410 durch Finden aller neuen Geräte, die die Zero-Touch-OTM-Vorgehensweise unterstützen. DOTS 430 wählt Zero-Touch-OTM aus und stellt eine sichere Verbindung unter Verwenden der Befugnisse her, die während der IF_C-Kommunikationen 425 erstellt wurden. Das Neue Gerät 410 kann den Zero-Touch-Onboarding-UUID, der mit dem Manifest 450 geliefert wird, zum Beispiel als seine zeitweilige Gerät-UUID verwenden.
Bei einem Beispiel spielt der Mediator-Service 420 die Rolle eines „Proxy“, wobei Meldungen, die mit den diversen Schnittstellen assoziiert sind (zum Beispiel IF_B 445, IF_C 425, ZTOTM 435) zwischen dem Neuen Gerät 410 und den anderen Diensten durch den Mediator-Service 420 vermittelt werden. Der Mediator-Service 420 setzt das Erleichtern der Handhabung des Netzwerkzugangspunkts 400 durch Spezifizieren eines Typs von Netzwerkisolationsfähigkeit fort. Ein Gast-Netzwerk 402 kann zum Beispiel Zugang zu dem Internet ermöglichen, während es diese Geräte in einem drahtlosen Produktions-LAN (WLAN) isoliert hält. Ein Sandbox-Netzwerk 404 kann eine dedizierte Verbindung (zum Beispiel virtuelles privates Netzwerk (VPN)) mit einem internen Service aufrechterhalten, der bei Zero-Touch-Onboarding unterstützt, aber von dem Produktionsnetzwerk 406 isoliert ist. Der Mediator-Service 420 kann auch einen SoftAP-Service hosten, der es dem Neuen Gerät 410 ermöglicht, sich mit dem Mediator-Service 420 zu verbinden, ohne das verdächtige Neue Gerät 410 irgendeinem verfügbaren AP zu exponieren, bis das Onboarding abgeschlossen ist.
Bei einem Beispiel strahlt der Mediator-Service 420 seine Baken unter Verwenden von SoftAP aus, um es dem Neuen Gerät 410 zu ermöglichen, den richtigen Mediator zu erkennen, der festgelegt ist, um das Onboarding zu handhaben. Die Familie der IEEE 802.11u-Standards beschreibt ein Verfahren zum Codieren in einer Erkennungsbake einer Extension-IE, die angibt, dass der AP ANQP/11u-Fähigkeit unterstützt. Das Neue Gerät 410 kann dann im Anschluss den SoftAP ohne A-Priori-Assoziation mit dem SoftAP abfragen, und ohne den Service-Set-Identifikator (SSID) zu besitzen. 802.1 1u stellt die Fähigkeit bereit, Eigenschaften und Attribute wie die folgenden zu erkennen: (1) Netzwerktyp, Gast, privat usw.; (2) Netzwerkauthentifizierungstyp, Anmeldungsoptionen; (3) IP-Adresstyp; (4) NAT-Typ; (5) EAP-Verfahren, erforderliche Befugnisse; (6) Domänennamen, die dem Inhaber gehören; und (7) Verkäufer-Extensions.
Das Neue Gerät 410 kann seinen „Manifest-UUID“-Wert (der zum Beispiel in der SDO-fähigen Plattform eingebettet ist) einsetzen, um die 802.11u-Bake zu erkennen, die den UUID enthält. Das ermöglicht es dem Neuen Gerät 410, Onboarding-Vorgänge gemäß dem beabsichtigten Mediator-Service (zum Beispiel Mediator-Service 420) selbst auszuwählen und selbst hinsichtlich der Last auszugleichen. Falls mehrere Mediator-Dienste SoftAP an demselben allgemeinen Ort wie mehrere Geräte, die eingegliedert werden sollen, hosten, kann das Neue Gerät 410 hinsichtlich der Auswahl des Mediator-Service verwirrt sein, oder, in dem Fall der ersten Umsetzung (in 3 gezeigt), wie oben besprochen, können mehrere Mediatoren hinsichtlich des neuen Geräts, das sie für Onboarding auswählen sollen, verwirrt sein. Bei anderen Beispielen, falls IEEE 802.11u nicht unterstützt wird, kann ein SoftAP den „Manifest-UUID“ in der SSID des Geräts codieren, wobei das Neue Gerät 410 dann den SoftAP mit dem UUID-Wert, der dem Manifest-UUID-Wert entspricht, auswählt.
802.1 1u kann auf andere Arten verwendet werden, um Onboarding-Effizienz zu verbessern und das „Berühren“ des Geräts zu reduzieren. Der Zugangspunkt 400 kann zum Beispiel den Uniform Resource Identifier (URI) oder die IP-Adresse für den Rendezvous-Service 440 oder den Onboarding-Server über einen Access-Network-Query-Protocol- (ANQP)/Generic Advertisement Service - (GAS) -Kanal als eine Alternative für das Gerät bereitstellen. Das kann insbesondere bei der ersten ZTOTM-Umsetzung (in 3 gezeigt) hilfreich sein, wobei das Gerät sich direkt mit den Onboarding- oder Rendezvous-Diensten verbinden kann. Bei einem Beispiel, falls der ANQP/GAS von 802.11u unterstützt wird, strahlt der AP 400 11u-Fähigkeiten aus, die der Client dann verwenden kann, um Eigenschaften oder Merkmale des Netzwerks zu erkennen, um sich an einen beabsichtigten Mediator (oder einen akzeptablen Mediator aus der Vielzahl von Mediatoren) anzuschließen.
5A bis 5E veranschaulichen ein „Swim-Lane“-Nachrichtenübermittlungsdiagramm für Zero-Touch-Gerät-Onboarding gemäß einem Beispiel. Die Meldungen, die in den 5A bis 5E veranschaulicht sind, entsprechen der ersten ZTOTM-Umsetzung, die oben unter Bezugnahme auf 3 beschrieben ist. Wie gezeigt, wird eine Reihe von Kommunikationen unter den Entitäten 310, 320, 330, 340, 360 ausgetauscht, um die erste ZTOTM Umsetzung auszuführen. Die Vorgänge, die in den 5A bis 5E abgebildet sind, stellen daher weitere Umsetzungsdetails dieser Vorgänge, die oben für 3 besprochen sind, bereit.
6A bis 6D veranschaulichen ein „Swim-Lane“-Nachrichtenübermittlungsdiagramm für Zero-Touch-Gerät-Onboarding gemäß einem Beispiel. Die Meldungen, die in den 6A bis 6D veranschaulicht sind, entsprechen der zweiten ZTOTM-Umsetzung, die oben unter Bezugnahme auf 4 beschrieben ist. Wie gezeigt, wird eine Reihe von Kommunikationen unter den Entitäten 400, 410, 420, 430, 440, 460 ausgetauscht, um die zweite ZTOTM Umsetzung auszuführen. Die Vorgänge, die in den 6A bis 6D abgebildet sind, stellen daher weitere Umsetzungsdetails dieser Vorgänge, die oben für 4 besprochen sind, bereit.
Die „ALT“-Flüsse, die in der zweiten ZTOTM-Umsetzung in den 6A bis 6D abgebildet sind, veranschaulichen, wie ein Rendezvous-Service 440 in einem Internet-Cloud-Service gehostet werden kann. Es ist eventuell nicht wünschenswert, das Überwachen der Gerätbereitstellungsaktivität über das Internet oder einen Cloud-Hosting-Provider zu aktivieren. Diese Konfiguration ermöglicht es dem Mediator-Service 420, eine standortspezifische Strategie für das Netzwerk, in dem der Rendezvous-Service 440 gehostet ist, anzuwenden.
Bei einem Beispiel kann der Onboarding-Prozess, der in den 6A bis 6D abgebildet ist, eine Bedingung antreffen und stillstehen, wobei Restart zum Abschließen verwendet wird. Falls diese Bedingung auftritt, kann im Anschluss an Meldung 22 in dem Fluss (in 6C abgebildet) das ZTOTM ohne erneutes Onboarding des Neuen Geräts 410 unter Verwenden eines Manifests (aus der Bereitstellungskette 460) oder des Rendezvous-Service 440 sicher wieder hergestellt werden. Das wird durch Bereitstellen von ZTOTM-Befugnissen als Teil der IF_C-Interaktionen verwirklicht. Die ZTOTM-Onboarding-Schritte können normalerweise durch Kapseln dieser Meldungen innerhalb des IF_C-Message-Containers verwirklicht werden. Falls jedoch der IF_C-Kontext verloren geht, startet das Onboarding erneut. Ein zusätzlicher Vorteil des Bereitstellens von ZTOTM-Befugnissen während IF_C besteht darin, dass solche Befugnisse auch als „Inhaber“-Befugnisse des Neuen Geräts 410 und Onboarding-Service 430 verwendet werden können (zum Beispiel zur Verwendung in dem OCF-Netzwerk). Diese Befugnisse können anschließend verwendet werden, um andere Gerätmanagementvorgänge zu verwirklichen.
7 veranschaulicht ein Swim-Lane-Nachrichtenübermittlungsdiagramm für eine beispielhafte Vorgehensweise für das Erkennen neuer Geräte. Bei diesem Beispiel wird diese Vorgehensweise von einem Onboarding-Service 710 (zum Beispiel DOTS) ausgeführt, um neue Geräte zu erkennen, die ZTOTM-Fähigkeiten unterstützen, da der Onboarding-Service 710 Identifikationsinformationen von relevanten Geräten, wie dem Neuen Gerät 720, fordert. Bei einer OCF-Umsetzung, nachdem der DOTS Manifeste, die Geräten entsprechen, die Zero-Touch-Onboarding unterstützen, erhalten hat, kann der DOTS zum Beispiel Geräterkennen abändern, um nur Geräte auszuwählen, die die ZTOTM-Vorgehensweise unterstützen. Der DOTS kann auch nur Geräte auswählen, deren deviceuuid der der Onboarding-UUID ist, der sich in seiner Manifest-Datei befindet.
Bei einer ersten Kommunikation, die in 7 abgebildet ist, erkennt der Onboarding-Service 710 (ein) neue(s) Gerät(e), die die ZTOTM-Vorgehensweise unterstützen. Bei einem Beispiel kann das Erkennen auf ein spezifisches Gerät abzielen, indem der Onboarding-UUID-Wert, der aus seiner Manifest-Datei erhalten wird, spezifiziert wird. Bei der zweiten Kommunikation, die in 7 abgebildet ist, antwortet das Neue Gerät 720 mit einem Identifikator, der als Antwort auf die erste Kommunikationsanfrage bereitgestellt wird. Dieser Identifikator sollte mit dem UUID übereinstimmen, der von einem Rendezvous-Service erhalten wird. Bei einem Beispiel gibt das Neue Gerät 720 eine Ressource (zum Beispiel /doxm-Ressource) mit Parametern zurück, die beim Bestimmen, ob das Gerät noch nicht eingegliedert ist, hilfreich sind. Falls das Gerät einen zeitweiligen Identifikator umsetzt und Zero-Touch-Onboarding unterstützt, ist der deviceuuid-Wert derselbe wie der Onboarding-UUID, der die Plattform für das OCF-Gerät verfügbar macht. Bei diversen Beispielen können diese und andere Kommunikationen TLS-Austausche als Teil eines HTTPS- oder COAPS-Protokolls sein, das eine Anbindung für Object Security for Constrained RESTful Environments (OSCORE) aufweist. Ferner können solche Kommunikationen über einen OSCORE-Tunnel durch ein oder mehrere Netzwerke und Domänen auftreten.
Bei einem Beispiel, im Anschluss an IF_C, kann dem Neuen Gerät 720 ein asymmetrischer oder symmetrischer Schlüssel (oder beide) bereitgestellt worden sein, mit dem die ZTOTM-Vorgehensweise auszuführen ist. Eine keyid wird verwendet, um den Schlüssel (oder das Schlüsselpaar), der während der Herstellung der ZTOTM-Session verwendet wird, zu referenzieren. Die keyid wird zu einem TLS HelloVerify()-Hint-Parameter geliefert, der es dem Onboarding-Service 710 ermöglicht, den korrekten Schlüssel, der zum Schützen der ClientHello()-Meldung verwendet wird, zu orten. Der Onboarding-Service 710 wählt den Schlüsseltyp (symmetrisch oder asymmetrisch) implizit aus, wenn der ClientHello()-Algorithmus ausgewählt wird. Die 8 und 9 zeigen daher ZTOTM-Abfolgen jeweils sowohl für asymmetrische als auch symmetrische Schlüsseltypen.
8 veranschaulicht ein „Swim-Lane“-Nachrichtenübermittlungsdiagramm für eine beispielhafte Vorgehensweise des Ausführens einer Zero-Touch-Inhabertransfertechnik, die in einer OCF-Umsetzung, die asymmetrische Schlüssel involviert, angewandt wird. Bei der ersten und der zweiten Kommunikation, die in 8 abgebildet sind, wählt der Onboarding-Service 720 das Zero-Touch-OTM durch Aktualisieren der oxmsel-Eigenschaft der /doxm-Ressource aus. Bei der dritten und der sechsten Kommunikation wählt der Onboarding-Service 720 eine asymmetrische CipherSuite aus, die das Gerät verwendet, um den asymmetrischen Schlüssel zu identifizieren, der während IF_C bereitgestellt wurde. Die CertificateRequest enthält den Onboarding-Service 720 oder seine lokale Root-CA in der certificate_authorities-Liste. Schließlich liefert der Onboarding-Service 710 bei der siebten und der achten Kommunikation sein selbstsigniertes Zertifikat oder die Zertifikatkette, die die lokale Root CA enthält.
9 veranschaulicht ein „Swim-Lane“-Nachrichtenübermittlungsdiagramm für eine beispielhafte Vorgehensweise des Ausführens einer Zero-Touch-Inhabertransfertechnik, die in einer OCF-Umsetzung, die symmetrische Schlüssel involviert, angewandt wird. Bei der ersten und der zweiten Kommunikation, die in 9 abgebildet sind, wählt der Onboarding-Service 710 die ZTOTM-Vorgehensweise durch Aktualisieren der oxmsel-Eigenschaft der /doxm-Ressource aus. Bei der dritten und der achten Kommunikation wählt der Onboarding-Service eine symmetrische CipherSuite aus, die das Gerät verwendet, um den symmetrischen PSK zu identifizieren, der während IF_C bereitgestellt wurde. Der psk_identity-value ist ein Schlüsselidentifikator, der von beiden Seiten verwendet wird, um den PSK zu orten, der während des ZTOTM verwendet werden soll.
Bei diversen Beispielen ist der Hersteller für das sichere Einbetten des Platform-Attestation-Private-Key, des Onboarding-UUID und den Schutz von Signierungs- und Prüfvorgängen in Zusammenhang mit der ZTOTM-Vorgehensweise mit einem ausreichenden Gewährleistungsgrad, dass diese Werte und Vorgänge nicht kompromittiert werden können, zuständig. Um das zu verwirklichen, gibt ein Plattform-Hersteller das Onboarding-Zertifikat aus und signiert das Manifest, das den öffentlichen Entitätsschlüssel der Bereitstellungskette, die für das Aufbauen des nächsten Manifest-Eintrags zuständig ist, enthält. Hersteller und Bereitstellungskettenentitäten sind für den Schutz ihrer jeweiligen Privatschüssel, die beim Signieren des Manifests verwendet werden, zuständig.
Bei einem Beispiel können die ZTOTM-Vorgehensweisen, die hierin besprochen sind, eine Vielfalt der folgenden Typen von (D)TLS-CipherSuiten verwenden, wie:

TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8,
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8,
TLS_ECDHE_ECDSA_WITH_AES_128_CCM, oder
TLS_ECDHE_ECDSA_WITH_AES_256_CCM

10 veranschaulicht ein Ablaufdiagramm 1000 eines beispielhaften Verfahrens zum Ausführen einer Onboarding-Technik. Die Vorgänge des Ablaufdiagramms 1000 können durch Aspekte eines Mediator-Service (zum Beispiel Intermediär/Proxy-Gerät, das einen Mediator-Service betreibt), einen Rendezvous-Service (zum Beispiel einen Server, der einen Rendezvous-Server betreibt), oder ein Onboarding-Tool (zum Beispiel einen Server, der einen Gerätinhabertransferdienst betreibt) einer Netzwerkplattform ausgeführt werden. Bei einem Beispiel, funktioniert diese Netzwerkplattform gemäß einer Open-Connectivity-Foundation-Spezifikation (OCF-Spezifikation) (zum Beispiel basierend auf der OCF-Spezifikation Version 2.0 vom 21. Juni 2018 oder einer äquivalenten früheren oder später freigegebenen Versionskonfiguration). Insbesondere werden die unten beschriebenen Vorgänge unter Verweis auf den Mediator-Service und Rendezvous-Server bereitgestellt, es ist jedoch klar, dass andere Entitäten und Dienste solche Aktionen ebenfalls ausführen oder koordinieren können.
Das Ablaufdiagramm 1000 beginnt mit Vorgängen bei 1010, um eine Anfrage von einem neuen Gerät um vorübergehenden Netzwerkzugang zu empfangen. Diese Anfrage kann zum Beispiel anfragen, eine Onboarding-Vorgehensweise mit einer Netzwerkplattform/einem Netzwerk-Service zu beginnen oder zu starten. Als Reaktion auf diese Anfrage werden vorübergehende Netzwerkzugangsbefugnisse zu dem neuen Gerät bei 1020 übertragen. Bei einem Beispiel können diese Befugnisse als Teil von Rendezvous-Service-Information bereitgestellt werden, die zu dem neuen Gerät übertragen wird, da die Rendezvous-Service-Information von dem neuen Gerät verwendet werden kann, um sich mit dem Rendezvous-Service über das erste Netzwerk zu verbinden. Ferner werden bei einem Beispiel die erste Anfrage, die erste Rendezvous-Service-Information und die Befugnisse des ersten Netzwerks in sicheren Kommunikationen unter Verwenden eines Software-Zugangspunkts, der von dem neuen Gerät gehostet wird, ausgetauscht. Bei einem anderen Beispiel werden die erste Anfrage, die erste Rendezvous-Service-Information und die Befugnisse des ersten Netzwerks in der Erkennungsbake unter Verwenden eines Software-Zugangspunkts, der von dem Mediator-Service-Gerät gehostet wird, ausgetauscht.
Das Ablaufdiagramm 1000 setzt mit Vorgängen 1030 bis 1050 aus der Sicht des Rendezvous-Servers fort, was Folgendes involviert: Empfangen einer Anfrage bei 1030, wobei die Anfrage die Absicht des neuen Geräts angibt, sich in die Netzwerkplattform einzugliedern; Übertragen anfänglicher Onboarding-Information zu dem neuen Gerät bei 1040; und Verständigen eines Onboarding-Service (zum Beispiel Onboarding-Servers) der Netzwerkplattform bei 1050 über die Absicht des neuen Geräts, eingegliedert zu werden, und über die Identifikation dieses Geräts. Bei einem Beispiel beinhaltet die anfängliche Onboarding-Information, die zu dem neuen Gerät bereitgestellt wird, eine Adresse des Onboarding-Servers. Bei einem Beispiel wird auch die anfängliche Onboarding-Information zwischen dem Onboarding-Server und dem Rendezvous-Service ausgetauscht. Bei noch einem weiteren Beispiel ist der Rendezvous-Service ein Cloud-gehosteter Service, der ein Manifest einsetzt, um einen Gerätinhaber für die Onboarding-Vorgehensweise zu identifizieren, wie um das zweckdienliche Onboarding-Tool oder den Dienst, für den das Onboarden des neuen Geräts erfolgen soll, zu identifizieren.
Das Ablaufdiagramm 1000 setzt mit Vorgängen aus der Sicht des Mediator-Service oder einer Intermediärentität fort, was Folgendes involviert: Empfangen einer zweiten Onboarding-Anfrage von einem neuen Gerät bei 1060, die die anfängliche Onboarding-Information enthält; Prüfen der anfänglichen Onboarding-Information von dem neuen Gerät bei 1070; und Bereitstellen aktualisierter Netzwerkzugangsbefugnisse zu dem neuen Gerät bei 1080, um Befugnisse eines zweiten Netzwerks zu dem neuen Gerät zu übertragen. Das zweite Netzwerk wird seinerseits für das neue Gerät verwendbar, um sich mit einem Onboarding-Server zu verbinden und die Onboarding-Vorgehensweise mit der Netzwerkplattform auszuführen (oder abzuschließen). Bei einem Beispiel beinhaltet die anfängliche Onboarding-Information, die von dem Mediator-Service identifiziert wird, den Identifikator des neuen Geräts und ein Nonce, wie für Identifikator und Nonce, die auch zwischen dem Rendezvous-Service und dem Onboarding-Service ausgetauscht werden.
Bei einem Beispiel umfassen die Befugnisse des ersten Netzwerks und des zweiten Netzwerks jeweilige Einstellungen für Kommunikationen über drahtlose Netzwerke, die gemäß einer Wi-Fi-Netzwerkspezifikation (zum Beispiel einer Spezifikation der Familie der IEEE 802.11-Standards) arbeiten. Bei einem Beispiel werden der Netzwerkzugang zum Beginnen der Onboarding-Vorgehensweise und der Netzwerkzugang zum Fortsetzen der Onboarding-Vorgehensweise auch über das Mediator-/Zwischengerät geführt, das als ein Proxy für das erste Netzwerk und das zweite Netzwerk arbeitet.
Bei einem weiteren Beispiel ist das erste Netzwerk ein nicht vertrauenswürdiges Netzwerk, das von dem zweiten Netzwerk isoliert ist, und der Rendezvous-Service prüft Identifikationsinformationen in Zusammenhang mit dem neuen Gerät, bevor er dem neuen Gerät die anfängliche Onboarding-Information bereitstellt. Bei einem weiteren Beispiel ist das zweite Netzwerk außerdem ein Sandbox-Netzwerk, das verwendet wird, um die Onboarding-Vorgehensweise mit der Netzwerkplattform abzuschließen; der Onboarding-Server stellt jedoch Befugnisse eines dritten Netzwerks für Produktionsnetzwerkzugang für das neue Gerät bereit, um Gerät-Servicevorgänge innerhalb der Netzwerkplattform auszuführen.
11 bildet ein beispielhaftes Szenario für das Onboarding eines betreffenden Geräts 1110 ab, das mit einem Inhabergerät 1120, Befugnis-Service 1130 und Zugangs-Service 1140 ausgeführt wird. Ein Onboarding-Prozess, der bei einer IoT-Bereitstellung (zum Beispiel in einer OCF-Netzwerkbereitstellung) ausgeführt wird, wird oft ähnlich wie die Art, die in 11 abgebildet ist, umgesetzt. Wie gezeigt, kann das Inhabergerät 1120 den eindeutigen Gerät-UUID von dem neuen Gerät 1110 abrufen und prüfen, dass keine Duplikate bestehen. Dann legt das Inhabergerät 1120 einen benutzerfreundlichen Gerätnamen an und assoziiert den Gerätidentifikator mit dem soeben empfangenen. Diese Information wird zu den Diensten, die mit dem IoT-Gerät assoziiert sind, wie Befugnisdiensten 1130 oder Zugangsdiensten 1140 vermittelt. Als ein Resultat kann sich das neue Gerät 1110 mit den Diensten mit der beanspruchten Identität verbinden.
Ein wichtiges Problem mit dem System, das in 11 abgebildet ist, ist die Authentizität und Gültigkeit des Original-Gerätidentifikators, selbst wenn die Privatsphäre dieses Identifikators nicht gewahrt wird. Wie hierin besprochen, können solche Onboarding-Ansätze (und andere IoT-Netzwerksystemvorgänge) durch die Verwendung eines Blockchain-Ansatzes zur Aufrechterhaltung einer selbstverwalteten Identität verbessert werden.
12 veranschaulicht ein Blockchain-Umsetzungssystem gemäß einem Beispiel. Wie man versteht, ist eine Blockchain eine verteilte Datenbank (zum Beispiel ein verteilter Ledger), die eine wachsende Liste von Datenaufzeichnungen führt, die vor Manipulation und Revision geschützt sind. Eine Blockchain (zum Beispiel die Kette 1210) beinhaltet „Blöcke“, die Daten oder sowohl Daten als auch Programme enthalten. Jeder Block enthält Serien individueller „Transaktionen“ zwischen Blockchain-Teilnehmern. Jeder Block beinhaltet einen Zeitstempel und Verknüpfungsinformation (gewöhnlich einen Hash-Wert), die den aktuellen Block mit dem vorhergehenden Block verlinkt; die Verknüpfungsinformation gestattet das Durchqueren der Blockchain (in beide Richtungen).
Die Integrität von Blockchain-Transaktionen wird unter Verwenden eines verteilten Hashing-Algorithmus geschützt, der erfordert, dass jeder Transaktionsprozessor (zum Beispiel „Miner“, wie mit den Minern 1221, 1222, 1223, 1224 gezeigt) dem nächsten Block in der Blockchain (zum Beispiel als ein Resultat einer Transaktion durch den Teilnehmer 1225 bereitgestellt) zustimmt. Integrität wird durch einen Konsens mehrerer Miner 1221, 1222, 1223 oder 1224 erzielt, wobei jeder Miner 1221, 1222, 1223 oder 1224 Zugang zu seiner eigenen Kopie der Blockchain 1210 besitzt, die auch ein verteilter Ledger genannt wird. Falls die Mehrheit der Miner 1221, 1222, 1223 oder 1224 dem Inhalt des Ledgers zustimmt, wird der vereinbarte Inhalt die „Wahrheit“ für den Ledger; die Miner 1221, 1222, 1223 oder 1224, die nicht zustimmen, akzeptieren die Wahrheit der Mehrheit (ansonsten würden sie nicht funktionieren können). Integrität ist nachweisbar, weil ein Angreifer eine Mehrheit von Minern kompromittieren und ihre Kopien des Ledgers modifizieren müsste, was extrem schwierig (wenn nicht sogar unmöglich) ist.
13 bildet ein beispielhaftes Verwendungsfallszenario ab, das eine Blockchain und eine Self Sovereign Identity (SSI) involviert. Wie gezeigt, kann ein Gerät 310 in ein oder mehrere Fog-Netzwerke 1320, 1330 eingegliedert werden, da diese Fog-Netzwerke die Inhaberschaft der SSI prüfen. Nachdem das Gerät 1310 seine SSI bei der Blockchain 1340 registriert hat (Vorgang 1), werden diese Identität und Registrierungsinformationen später für beide Fog-Netzwerke 1320, 1330 lesbar und prüfbar.
14 veranschaulicht ein Ablaufdiagramm, das SSI-Registrierung des neuen Geräts 1110 bei einer Blockkette 1150 veranschaulicht. Wie in 14 veranschaulicht, ist das neue Gerät 1110 selbst für das Signieren mit seinem privaten Signierungscode und der beanspruchten Gerätidentität sowie dem assoziierten öffentlichen Schlüssel zuständig. Die Blockchain 1150 prüft auf Duplikatidentitäten und fügt die Identität zu einem neuen Block hinzu. Dann ruft das Inhabergerät 1120 als Teil des Onboarding-Prozesses die Signatur und Information ab, um die Gerätidentität von der Blockchain 1150 abzufragen. An diesem Punkt kann das Inhabergerät 1120 die Authentizität des Identitätsanspruchs des neuen Geräts prüfen und, ähnlich wie bei dem Fluss oben, die Blockchain 1150 informiert relevante Dienste (zum Beispiel den Befugnis-Service 1130) über diese neue Gerätidentität, die zum Kommunizieren mit dem neuen Gerät 1110 verwendet werden kann. Falls ein Duplikat vorhanden ist, prüft das Inhabergerät 1120 bei der Blockkette 1150 nach und prüft auch bezüglich der Authentizität dieser Signaturen. Nach der Lösung des Konflikts erhält das neue Gerät 1110 die aktualisierte Inhabergerätinformation und kann sich dann mit Diensten verbinden.
Die Gerät-ID in 14 stellt ein Beispiel eines Identitätsattributs bereit, das für Korrelationsangriffe verwendet werden kann. Man versteht, dass die Privatsphäre des Inhabers/Nutzers kompromittiert werden kann, falls die Gerät-ID verwendet wird, um Transaktionen, die dem Inhaber/Nutzer gehören, zu korrelieren. Sogar falls der Inhaber bei der Verwendung der Gerät-ID sorgsam umgeht, ist es möglich, dass ein zweiter Inhaber desselben Geräts dieselbe Gerät-ID behalten könnte, die missbraucht oder für illegale Zwecke verwendet wird. Anschließend können alle legitimen Transaktionen des ersten Inhabers in Frage gestellt werden, weil sie nun mit illegalen Transaktionen des zweiten Inhabers korreliert und assoziiert werden können, was bedeutet, dass die zwei Inhaber an einem Punkt eine Verbindung miteinander hatten (zum Beispiel eine Geschäftsinteraktion, die in dem Inhaberwechsel des Geräts resultiert hat).
Das Gerät kann daher potenziell Inhaber nach Inhaber mitverfolgt werden, was die Privatsphäre kompromittiert sowie auch potentielle Sicherheitsrisiken einführt (Datenvertraulichkeit, Malware usw.), mit gezielten Angriffen auf spezifische Inhaber „neuer Geräte“. Wie weiter in den folgenden Absätzen besprochen wird, kann die Blockchain-Umsetzung der 13 und 14 ausgedehnt werden, um IoT-Transaktionen zu involvieren, die unter Teilnehmern ausgeführt werden, um die Verwendung von Zero-Knowledge-Commitments zu ermöglichen, und Zero-Knowledge-Proof von Kenntnis von Prüfung, Verwendung von Informationen, die in der Blockchain 1150 stehen.
Die Verwendung der folgenden Verfahren und kryptografischen Protokolle gestattet ein die Privatsphäre wahrendes Onboarding von IoT-Geräten derart, dass die Geräte zwischen mehreren Inhabern nicht mitverfolgt werden können, gestatten gleichzeitig aber Prüfung mit hoher Gewährleistung der Identität des IoT-Geräts und anderer, um sicheres Onboarding durch den neuen Inhaber zu gestatten. Das stellt auch die Richtigkeit und Duplikaterkennung sicher, selbst wenn die private Information nicht in Klarschrift aufgedeckt werden.
Bei einem Beispiel basiert dieser Sicherheitsansatz auf der Fähigkeit, Zero-Knowledge-Proof gegenüber den herkömmlichen RSA- oder Elliptic-Curve-Signaturen auszuführen, um über eine Privatsphären-geschützte Registrierung der neuen Geräte zu verfügen. Typischerweise besteht ein Zero-Knowledge-Proof aus 2 Schritten - (1) Commitment geheimer Daten (zum Beispiel Gerätidentifikator, es könnten aber auch andere Attribute sein, wie Gruppenmitgliedschaft, Ort, Herstellungsjahr usw.) und (2) Proof der Kenntnis der geheimen Daten. Das kryptografische Protokoll ist unten zuerst beschrieben, gefolgt von einer Beschreibung vom Anfang bis zum Ende eines die Privatsphäre schützenden Registrierungsflusses unter Verwenden dieser kryptografischen Primitiven.
Bei einem Beispiel können Zero-Knowledge-Commitments wie folgt eingesetzt werden: Um fähig zu sein, einen Proof bezüglich eines Identifikators m zu schaffen, schafft das Gerät ein Pedersen'sches Commitment mit der Form $M = g_{1}^{m} h_{1}^{r},$
wobei r ein Zufallswert ist, der von dem Benutzer ausgewählt wird, und g₁ und h₁ öffentliche Parameter des Registrars sind. Dieses Commitment wird bei der Blockchain angemeldet. Bei der Anmeldung signiert die Blockchain das Commitment M, um σ=M^χ als die Signatur auszugeben, wobei χ der geheime Schlüssel der Blockchain ist (zum Beispiel eine Semi-Permissioned-Blockchain, wie eine ChainAnchor-Umsetzung).
Bei einem weiteren Beispiel ermöglicht es eine Semi-Permissioned-Blockchain einem Gerät, durch etwas Sicherheitsprüfung zu der Blockchain-Gemeinschaft zugelassen zu werden, erlaubt es Geräten jedoch, anonym zu bleiben, indem sie eine Befugnis präsentieren, um sicherzustellen, dass die Geräte ein Mitglied der Gemeinschaft sind (während sie anonym bleiben). Transaktionen können daher mit einem Schlüssel signiert werden, der allen Mitgliedern der Kette Anonymität verleiht. Das geht davon aus, dass die Gemeinschaft ausreichend groß ist, dass es unpraktisch wäre, eine erschöpfende Suche nach allen Transaktionen auszuführen, die mit der Gemeinschaft korreliert sind, und dadurch die Identität eines seiner Mitglieder abzuleiten.
Bei einem Beispiel kann die Zero-Knowledge-Kenntnisnachweis-(Zero-Knowledge-Proof of Knowledge - ZKPK) oder Prüfvorgehensweise eine Prüfung wie folgt ausführen. Es werden Signaturen σ₁, σ₂, .., σ₃, die den Identifikatoren entsprechen, die von dem Gerät zu dem neuen Gerätinhaber nachgewiesen werden müssen, angenommen. Zu dem Zeitpunkt der Registrierung aggregiert das Gerät die Signaturen in $σ= \prod_{i = 1}^{t} σ_{i}$
, wobei σi die Signatur des Commitmentwerts $M_{i} = g_{1}^{m_{i}} h_{1}^{r_{i}}$
ist.
Als ein weiteres Beispiel kann dies nur eine Signatur beinhalten, falls nur ein geheimer Gerätidentifikator oder eine Gruppenmitgliedschaft nachgewiesen werden muss. Diese Technik kann jedoch auf einen Satz von Attributen für Fälle verallgemeinert werden, in welchen die Registrierung nicht nur eine Gerätidentität, sondern auch andere Attribute des Geräts erfordert. Diese Attribute sind als Teil des Zero-Knowledge-Proof enthalten, um ein Datenleck zu vermeiden, während die Registrierungsbetrachtungen erfüllt werden.
Das neue Gerät berechnet dann $M - \prod_{i = 1}^{t} M_{i} = g_{1}^{m_{1} + \dots + m_{t_{h_{1}}} r_{1} + \dots r_{t}} \cdot$
Der Benutzer sendet σ, M, Mi, 1 ≤ i ≤t zu dem Verifier (der der Gerätinhaber ist).
Als einen nächsten Schritt führen das neue Gerät und der Verifier das folgende ZKPK-Protokoll (unter Verwenden einer Vereinbarung, bei der griechische Buchstaben die Mengen bezeichnen, deren Kenntnis nachgewiesen wird, während alle anderen Parameter zu dem Verifier gesendet werden): $P K {(α, β) : m = g_{1}^{α} h_{1}^{β}, α,β \in z_{q}}$
Nachdem der Verifier den Zero-Knowledge-Proof des Commitments akzeptiert hat, prüft der Verifier, ob die folgenden Prüfungen erfolgreich sind: $\begin{matrix} M - & \prod_{i = l}^{t} M; und \begin{matrix} e (a, g_{2}) & = e (M, v) \end{matrix} \end{matrix}$
wobei g₂ ein öffentlicher Parameter ist, v der öffentliche Schlüssel des Registrars ist und e ein bilineares Mapping ist. Falls der letzte Schritt erfolgreich ist, akzeptiert der Verifier den ZKPK der signierten Commitments.
15 veranschaulicht einen Privatsphären-geschützten SSI-Registrierungsfluss, der das oben beschriebene kryptografisches Protokoll umsetzt. Wie gezeigt, schafft das erste neue Gerät 1110 das signierte Commitment. Bei diesem Beispiel wird nur ein signiertes Attribut berücksichtigt, dass der Gerätidentifikator („A71C3“) ist. Dieses Commitment wird der Blockchain 1150 als ein neuer Block unterbreitet.
Nach dem Hinzufügen zu der Blockchain 1150, ist der Gerätinhaber 1120 der Verifier dieses Commitments, wenn das neue Gerät 1110 Inhaberschaft des Commitments beansprucht. Der Einfachheit halber zeigt 15 den Gerätinhaber 1120, der das Commitment von der Blockchain 1110 abruft, da das Commitment aber signiert ist, kann diese Information potentiell von dem neuen Gerät 1110 selbst bereitgestellt werden (wie bei einem Szenario, bei dem die Blockchain-Information offline ist). Dieses Commitment kann auf Duplikate innerhalb des Systems des Gerätinhabers geprüft werden. Nachdem das Commitment geprüft wurde, ist das Inhabergerät 1120 der Verifier und führt das ZKPK-Protokoll aus, um sicherzustellen, dass der geheime Identifikator dem neuen Gerät bekannt ist und dass es Inhaberschaft mit der Signaturprüfung nachweisen kann. Diese Prüfung ist für unterschiedliche Inhaber unterschiedlich und kann nicht verwendet werden, um unterschiedliche Transaktionen (Registrierungen) zu verknüpfen, so dass die Privatsphäre gewahrt und auch Authentizität sichergestellt wird.
Bei einem weiteren Beispiel kann mehr als ein Attribut verwendet werden, um zu prüfen und mit einem Gerät auf eine ähnliche Art zu assoziieren. Das gestattet ein umfassendes feinkörniges Onboarding von IoT-Geräten und diverser Edge-Typen, Multi-Access-Edge-Computing (MFC), Cloud und vernetzter Entitäten, die die Bereitstellung hergestellter „Smart“-Artikel involvieren, während die Privatsphäre aller Attribute, die als Teil des Prozesses geprüft werden, gewahrt wird.
Bei weiteren Beispielen können die hierin besprochenen Blockchain-Ansätze auch an Verwendungsfälle angewandt werden, die SSI-Konfliktlösung involvieren. Bei einem Beispiel illustriert 16 ein Ablaufdiagramm, in dem SSI-Konfliktlösung an einer Blockchain auftritt, ohne einen Privatsphären-Fluss (zum Beispiel ohne die Verwendung von Zero-Knowledge-Proof). 17 veranschaulicht ein Szenario, bei dem SSI-Konfliktlösung auftritt, aber mit einer Privatsphäre-geschützten Variation (zum Beispiel mit Verwendung eines Zero-Knowledge-Proof). Die Blockchain- und die Zero-Knowledge-Techniken, die hierin besprochen sind, können daher an einer Vielfalt von IoT-Informationsmanagementmerkmalen angewandt werden.
Bei noch weiteren Beispielen können die hierin besprochenen Techniken in Verbindung mit einem Sigma-Protokoll verwendet werden, das umgesetzt wird, um die Verwendung von Gerätidentifikationsrückruf (zum Beispiel EPID-Rückruf) zu verwenden. Information zum Identifizieren und Führen einer Rückrufliste (oder einer anderen Information in Zusammenhang mit dem Rückruf von Befugnissen oder Identifikatoren) kann auf einer Blockchain unter Verwenden der hierin besprochenen Techniken gespeichert werden. Darüber hinaus kann eine Anzahl von Techniken zum Ermöglichen von Information in Zusammenhang mit Rückruf, Assoziation, Registrierung oder Gerätinhaberschaft-Management auf einer Blockchain auf eine Privatsphären-geschützte Art unter Verwenden der hierin besprochenen Techniken gespeichert und geprüft werden.
18 ist ein Ablaufdiagramm 1800 eines Verfahrens für Geräteattributregistrierung und -prüfung unter Verwenden einer Blockchain. Bei einem Beispiel können die Vorgänge des Ablaufdiagramms 1800 von einem Inhabergerät ausgeführt werden, wie in Verbindung mit der Gerätregistrierung oder Gerätmanagementdiensten in Szenarien wie den oben besprochenen. Alle oder ein Abschnitt der Vorgänge des Ablaufdiagramms 1800 können jedoch durch andere Entitäten in einer vernetzten Umgebung zum Zweck der Informationsprüfung ausgeführt werden, während die Privatsphäre geschützt wird.
In dem Ablaufdiagramm 1800 beinhalten Vorabbedingungsvorgänge das Schaffen eines signierten Commitments von einem oder mehreren Attributen des betreffenden Geräts (Vorgang 1810) und das Hinzufügen des signierten Commitments zu einem Blockchain-Ledger (Vorgang 1820). Dieses Commitment kann wie in den oben stehenden Beispielen vorgeschlagen, hergestellt und registriert werden.
Das Ablaufdiagramm 1800 setzt dann mit Anfrage-Prüfvorgängen basierend auf dem Commitment fort. Zunächst fordert das prüfende Gerät (zum Beispiel ein Inhabergerät) die Attribute des betreffenden Geräts von einer Entität, wie dem betreffenden Gerät an (Vorgang 1830) und empfängt die angebotenen Attribute des betreffenden Geräts von der angefragten Entität, wie von dem betreffenden Gerät (Vorgang 1840). Dann erhält das prüfende Gerät ein Commitment von einer Blockchain (Vorgang 1850) oder, alternativ, erhält es ein signiertes Commitment, wie von dem betreffenden Gerät oder einer anderen zugänglichen Entität angeboten.
Das Ablaufdiagramm 1800 geht dann weiter zum Ausführen einer Prüfung der Attribute des betreffenden Geräts unter Verwenden des Commitments innerhalb eines Zero-Knowledge-Protokolls (Vorgang 1860). Basierend auf dieser Prüfung kann das prüfende Gerät bestimmen, ob die angeforderten/empfangenen Gerätattribute gültig sind, ohne dass das Gerätattribut öffentlich verfügbar gemacht oder angekündigt wird. Schließlich können Netzwerkvorgänge unter Verwenden der Attribute des betreffenden Geräts basierend auf einem erfolgreichen Prüfungsresultat ausgeführt werden (Vorgang 1870).
Bei diversen Beispielen können die Vorgänge und Funktionalität, die oben unter Bezugnahme auf die 3 bis 18 beschrieben sind, von einer IoT-Gerätmaschine in der beispielhaften Form eines elektronischen Verarbeitungssystems verkörpert werden, in dem gemäß einer beispielhaften Ausführungsform ein Satz oder eine Abfolge von Anweisungen ausgeführt werden kann, um das elektronische Verarbeitungssystem zu veranlassen, eine der Methodologien, die hierin besprochen sind, auszuführen. Die Maschine kann ein IoT-Gerät oder ein IoT-Gateway sein, einschließlich einer Maschine , die von Aspekten eines Personal Computers (PC), eines Tablet-PC, eines Personal Digital Assistant (PDA), eines Mobiltelefons oder Smartphones, oder irgendeiner Maschine, die fähig ist, Anweisungen (seien sie sequenziell oder anderswie) auszuführen, die Maßnahmen spezifizieren, die diese Maschine zu treffen hat, verkörpert wird.
Obwohl nur eine einzige Maschine in den oben stehenden Beispielen abgebildet und referenziert ist, muss ferner auch davon ausgegangen werden, dass eine solche Maschine eine Sammlung von Maschinen beinhaltet, die individuell oder gemeinsam einen Satz (oder mehrere Sätze) von Anweisungen ausführen, um eine oder mehrere der hier besprochenen Methodologien auszuführen. Ferner muss davon ausgegangen werden, dass diese und ähnliche Beispiele eines auf Prozessor basierenden Systems einen Satz aus einer oder mehreren Maschinen beinhalten, die von einem Prozessor, Satz von Prozessoren oder Verarbeitungsschaltungen (zum Beispiel einem Computer) gesteuert oder betrieben werden, um individuell oder gemeinsam Anweisungen umzusetzen, um eine oder mehrere der hierin besprochenen Methodologien umzusetzen. Bei diversen Beispielen können folglich anwendbare Mittel zum Verarbeiten (zum Beispiel Verarbeiten, Kontrollieren, Erzeugen, Bewerten usw.) durch solche Verarbeitungsschaltungen verkörpert werden.
19 veranschaulicht eine Zeichnung eines Cloud-Computing-Netzwerks oder einer Cloud 1900 in Kommunikation mit einer Anzahl von Geräten des Internets der Dinge (IoT). Die Cloud 1900 kann das Internet darstellen oder kann ein Local Area Network (LAN) oder ein Wide Area Network (WAN), wie ein proprietäres Netzwerk für ein Unternehmen sein. Die IoT-Geräte können eine Anzahl unterschiedlicher Typen von Geräten, die in diversen Kombinationen gruppiert sind, beinhalten. Zum Beispiel kann eine Verkehrssteuergruppe 1906 IoT-Geräte entlang von Straßen in einer Stadt beinhalten. Diese IoT-Geräte können Ampeln, Verkehrsflussmonitore, Kameras, Wettersensoren und dergleichen beinhalten. Die Verkehrssteuergruppe 1906 oder andere Untergruppen können mit der Cloud 1900 durch verdrahtete oder drahtlose Links 1908, wie LPWA-Links, optische Links und dergleichen in Kommunikation stehen. Ferner kann es ein verdrahtetes oder drahtloses Unternetzwerk 1912 den IoT-Geräten erlauben, miteinander wie durch ein Local Area Network, ein drahtloses Local Area Network und dergleichen zu kommunizieren. Die IoT-Geräte können ein anderes Gerät verwenden, wie ein Gateway 1910 oder 1928, um mit entfernten Orten, wie der Cloud 1900 zu kommunizieren; die IoT-Geräte können auch einen oder mehrere Server 1930 verwenden, um Kommunikation mit der Cloud 1900 oder mit dem Gateway 1910 zu erleichtern. Der eine oder die mehreren Server 1930 können zum Beispiel als ein Zwischennetzwerkknoten arbeiten, um eine lokale Edge-Cloud oder Fog-Umsetzung unter einem Local Area Network zu unterstützen. Ferner kann das Gateway 1928, das abgebildet ist, in einer Konfiguration aus Cloud-zu-Gateway-zu vielen-Edge-Geräten arbeiten, wie mit den diversen IoT-Geräten 1914, 1920, 1924, die dynamisch oder beschränkt auf eine Zuweisung und Verwendung von Ressourcen in der Cloud 1900 sind.
Andere beispielhafte Gruppen von IoT-Geräten können entfernte Wetterstationen 1914, lokale Informationsendgeräte 1916, Alarmsysteme 1918, Geldautomaten 1920, Alarmtafeln 1922 oder sich bewegende Fahrzeuge, wie Einsatzfahrzeuge 1924 oder andere Fahrzeuge 1926 unter vielen anderen aufweisen. Jedes dieser IoT-Geräte kann mit anderen IoT-Geräten, mit Server 1904, mit einer anderen IoT-Fog-Plattform oder einem anderen IoT-Fog-System (nicht gezeigt, aber in 2 abgebildet) oder einer Kombination davon in Kommunikation stehen. Die Gruppen von IoT-Geräten können in diversen Heim-, Geschäfts- und industriellen Umgebungen (einschließlich sowohl privater als auch öffentlicher Umgebungen) bereitgestellt sein.
Wie aus 19 ersichtlich ist, kann eine große Anzahl von IoT-Geräten durch die Cloud 1900 in Kommunikation stehen. Dies kann es unterschiedlichen IoT-Geräten erlauben, Informationen bei anderen Vorrichtungen autonom anzufordern oder zu diesen bereitzustellen. Eine Gruppe von IoT-Geräten (zum Beispiel die Verkehrssteuergruppe 1906) kann zum Beispiel eine aktuelle Wettervorhersage von einer Gruppe entfernter Wetterstationen 1914 anfordern, die die Vorhersage ohne menschlichen Eingriff bereitstellen können. Ferner kann ein Einsatzfahrzeug 1924 durch einen Geldautomaten 1920 gewarnt werden, dass ein Einbruch im Gange ist. Während sich das Einsatzfahrzeug 1924 zu dem Geldautomaten 1920 begibt, kann es auf die Verkehrssteuergruppe 1906 zugreifen, um Räumung zu dem Ort anzufordern, indem zum Beispiel die Ampeln auf Rot gestellt werden, um Querverkehr an einer Kreuzung rechtzeitig zu blockieren, so dass das Einsatzfahrzeug 1924 unbehinderte Zufahrt zu der Kreuzung hat.
Cluster von IoT-Geräten, wie die entfernten Wetterstationen 1914 oder die Verkehrssteuergruppe 1906 können ausgestattet sein, um mit anderen IoT-Geräten sowie mit der Cloud 1900 zu kommunizieren. Dies kann es den IoT-Geräten erlauben, ein Ad-Hoc-Netzwerk zwischen den Vorrichtungen zu bilden, das es ihnen erlaubt, als ein einziges Gerät zu funktionieren, das eine Fog-Plattform oder ein Fog-System genannt werden kann (zum Beispiel wie oben unter Bezugnahme auf 2 besprochen).
20 ist ein Blockschaltbild eines Beispiels von Komponenten, die in einem IoT-Gerät 2050 zur Umsetzung der hierin beschriebenen Techniken anwesend sein können. Das IoT-Gerät 2050 kann beliebige Kombinationen von Komponenten, die in dem Beispiel gezeigt sind oder die in der oben stehenden Offenbarung referenziert sind, beinhalten. Diese Komponenten können als ICs, Abschnitte davon, als getrennte elektronische Geräte oder andere Module, Logik, Hardware, Software, Firmware oder eine Kombination davon, die in dem IoT-Gerät 2050 angepasst ist, oder als Komponenten, die anderswie innerhalb eines Chassis eines größeren Systems eingebaut sind, umgesetzt werden. Zusätzlich soll das Blockschaltbild der 20 eine Ansicht hohen Niveaus der Komponenten des IoT-Geräts 2050 zeigen. Einige der Komponenten, die gezeigt sind, können jedoch weggelassen werden, zusätzliche Komponenten können vorhanden sein, und unterschiedliche Anordnungen der gezeigten Komponenten können bei anderen Umsetzungen auftreten.
Das IoT-Gerät 2050 kann Verarbeitungsschaltungen in der Form eines Prozessors 2052 beinhalten, der ein Mikroprozessor, ein Multikern-Prozessor, ein Multithreaded Prozessor, ein Ultra-Low-Spannungs-Prozessor, ein eingebetteter Prozessor oder ein anderes bekanntes Verarbeitungselement sein kann. Der Prozessor 2052 kann ein Teil eines Systems auf einem Chip (System on a Chip - SoC) sein, wobei der Prozessor 2052 und andere Komponenten in eine einzige integrierte Schaltung oder ein einziges Package gebildet sind, wie die Edison™- oder Galileo™-SoC-Platten von Intel. Als ein Beispiel kann der Prozessor 2052 einen auf Intel® Architecture Core™ basierenden Prozessor, wie einen Quark™-, einen Atom™-, einen i3-, einen i5-, einen i7-Prozessor oder einen Prozessor der MCU-Klasse oder einen anderen solchen Prozessor, der bei Intel® Corporation, Santa Clara, Kalifornien, erhältlich ist, beinhalten. Eine beliebige Anzahl anderer Prozessoren kann jedoch verwendet werden, wie die, die bei Advanced Micro Devices, Inc. (AMD) in Sunnyvale, Kalifornien, erhältlich sind, ein auf MIPS basierendes Design von MIPS Technologies, Inc. in Sunnyvale, Kalifornien, ein auf ARM basierendes Design unter Lizenz von ARM Holdings, Ltd. oder eines Kunden davon, oder ihrer Lizenznehmer und Adopter. Die Prozessoren können Einheiten wie einen A5-A12-Prozessor von Apple® Inc., einen Snapdragon™-Prozessor von Qualcomm® Technologies, Inc., oder einen OMAP™-Prozessor von Texas Instruments, Inc. beinhalten.
Der Prozessor 2052 kann mit einem Systemspeicher 2054 über einen Interconnect 2056 (zum Beispiel einen Bus) kommunizieren, wobei eine beliebige Anzahl von Speichergeräten verwendet werden kann, um eine gegebene Menge an Systemspeicher bereitzustellen. Als Beispiele kann der Speicher ein Direktzugriffsspeicher (Random Access Memory - RAM) in Übereinstimmung mit einem Joint-Electron-Devices-Engineering-Council-Design (JEDEC-Design), wie dem DDR- oder dem Mobile-DDR-Standard (zum Beispiel LPDDR, LPDDR2, LPDDR3 oder LPDDR4) sein. Bei diversen Umsetzungen können die individuellen Speichergeräte eine beliebige Anzahl unterschiedlicher Package-Typen sein, wie Single Die Package (SDP), Dual Die Package (DDP) oder Quad Die Package (Q17P). Diese Geräte können bei einigen Beispielen direkt auf eine Hauptplatine gelötet werden, um eine Lösung mit niedrigerem Profil bereitzustellen, während die Bauteile bei anderen Beispielen als ein oder mehrere Speichermodule konfiguriert sind, die mit der Hauptplatine durch einen gegebenen Steckverbinder koppeln. Eine beliebige Anzahl anderer Speicherumsetzungen kann verwendet werden, wie andere Typen von Speichermodulen, zum Beispiel Dual Inline Memory Modules (DIMMs) unterschiedlicher Arten, einschließlich, ohne darauf beschränkt zu sein, MicroDIMMs oder MiniDIMMs.
Zum Bereitstellen persistenter Speicherung von Informationen wie Daten, Anwendungen, Betriebssystemen usw., kann ein Massenspeicher 2058 auch den Prozessor 2052 über den Interconnect 2056 koppeln. Bei einem Beispiel kann der Speicher 2058 über ein Solid-State-Festplattenlaufwerk (Solid State Disk Drive SSDD) umgesetzt werden. Andere Geräte, die für den Speicher 2058 verwendet werden können, weisen Flash-Speicherkarten, wie SD-Karten, MicroSD-Karten, xD-Bildkarten und dergleichen sowie USB-Flash-Laufwerke auf. Bei Niederleistungsumsetzungen kann der Speicher 2058 ein Speicher auf Die oder Registern, die mit dem Prozessor 2052 assoziiert sind, sein. Bei einigen Beispielen kann der Speicher 2058 jedoch unter Verwenden eines Mikro-Festplattenlaufwerks (Hard Disk Drive-HDD) umgesetzt werden. Ferner kann eine beliebige Anzahl neuer Technologien für den Speicher 2058 zusätzlich zu den oder an Stelle der beschriebenen Technologien verwendet werden, wie, unter anderen, Widerstandswechselspeicher, Phasenwechselspeicher, holographische Speicher oder chemische Speicher.
Die Komponenten können über den Interconnect 2056 kommunizieren. Der Interconnect 2056 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. Der Interconnect 2056 kann ein proprietärer Bus sein, der zum Beispiel in einem auf SoC basierenden System verwendet wird. Andere Bussysteme können enthalten sein, wie, unter anderen, eine I2C-Schnittstelle, eine SPI-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Leistungsbus.
Der Interconnect 2056 kann den Prozessor 2052 mit einem Mesh-Transceiver 2062 für Kommunikationen mit anderen Mesh-Geräten 2064 koppeln. Der Mesh-Transceiver 2062 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie unter anderen 2,4-Gigahertz-(GHz)-Übertragungen gemäß dem IEEE-802.15.4-Standard, unter Verwenden unter anderen des Bluetooth®-Low-Energy-(BLE)-Standards, wie von der Bluetooth® Special Interest Group definiert, oder des ZigBee®-Standards. Eine beliebige Anzahl von Funkgeräten, die für ein bestimmtes drahtloses Kommunikationsprotokoll konfiguriert sind, kann für die Verbindungen mit den Mesh-Geräten 2064 verwendet werden. Eine WLAN-Einheit kann zum Beispiel zum Umsetzen von Wi-Fi™-Kommunikationen in Übereinstimmung mit dem Standard 802.11 des Institute of Electrical and Electronics Engineers (IEEE) verwendet werden. Zusätzlich können drahtlose Wide-Area-Kommunikationen zum Beispiel gemäß einem zellulären oder anderen drahtlosen Wide-Area-Protokoll über eine WWAN-Einheit erfolgen.
Der Mesh-Transceiver 2062 kann unter Verwenden mehrerer Standards oder Funkgeräte für Kommunikationen in unterschiedlichem Bereich kommunizieren. Das IoT-Gerät 2050 kann zum Beispiel mit nahen Vorrichtungen kommunizieren, zum Beispiel innerhalb von etwa 10 Metern, unter Verwenden eines lokalen Transceivers basierend auf BLE oder einem anderen Niederleistung-Funkgerät zum Sparen von Strom. Weiter entfernte Mesh-Geräte 2064, zum Beispiel innerhalb von etwa 50 Metern, können über ZigBee oder andere Funkgeräte mittlerer Leistung erreicht werden. Beide Kommunikationstechniken können über ein einziges Funkgerät mit unterschiedlichen Leistungspegeln stattfinden, oder können über separate Transceiver stattfinden, zum Beispiel über einen lokalen Transceiver, der BLE verwendet, und einen separaten Mesh-Transceiver, der ZigBee verwendet.
Ein drahtloser Netzwerk-Transceiver 2066 kann enthalten sein, um mit Geräten oder Diensten in der Cloud 2000 über lokale oder Wide-Area-Network-Protokolle zu kommunizieren. Der drahtlose Netzwerk-Transceiver 2066 kann ein LPWA-Transceiver sein, der unter anderen dem Standard IEEE 802.15.4 oder IEEE 802.15.4g entspricht. Das IoT-Gerät 2050 kann über ein weites Gebiet unter Verwenden des LoRaWAN™ (Long Range Wide Area Network), das von Semtech und LoRa Alliance entwickelt wurde, kommunizieren. Die hierin beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl anderer Cloud-Transceiver, die Langstreckenkommunikationen mit niedriger Bandbreite, wie Sigfox, und andere Technologien umsetzen, verwendet werden. Ferner können andere Kommunikationstechniken, wie Time Slotted Channel Hopping, das in IEEE 802.15.4e beschrieben ist, verwendet werden.
Eine beliebige Anzahl anderer Funkkommunikationen und Protokolle kann zusätzlich zu den Systemen, die für den Mesh-Transceiver 2062 und drahtlose Netzwerk-Transceiver 2066 erwähnt sind, wie hierin beschrieben verwendet werden. Die Funktransceiver 2062 und 2066 können zum Beispiel einen LTE- oder anderen zellulären Transceiver aufweisen, der Spread-Spectrum-Kommunikationen (SPA/SAS-Kommunikationen) zum Umsetzen von Hochgeschwindigkeitskommunikationen verwendet. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie Wi-Fi®-Netzwerke für Kommunikationen mit mittlerer Geschwindigkeit und Bereitstellung von Netzwerkkommunikationen.
Die Funktransceiver 2062 und 2066 können Funkgeräte aufweisen, die mit einer beliebigen Anzahl von 3GPP-Spezifikationen (Third Generation Partnership Project-Spezifikationen) kompatibel sind, insbesondere Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A) und Long Term Evolution-Advanced Pro (LTE-A Pro). Zu bemerken ist, dass Funkgeräte, die mit einer beliebigen Anzahl anderer stationärer, mobiler oder Satellitenkommunikationstechnologien und -standards kompatibel sind, ausgewählt werden können. Diese können zum Beispiel beliebige Cellular-Wide-Area-Funkkommunikationstechnologie beinhalten, die zum Beispiel Kommunikationssysteme fünfter Generation (5G), eine Global System for Mobile Communications (GSM) Funkkommunikationstechnologie, eine General Packet Radio Service (GPRS) Funkkommunikationstechnologie oder eine Enhanced Data Rates for GSM Evolution (EDGE) Funkkommunikationstechnologie, eine UMTS-Kommunikationstechnologie (Universal Mobile Telecommunications System) beinhalten kann. Zusätzlich zu den oben erwähnten Standards kann eine beliebige Anzahl von Satelliten-Uplink-Technologien für den drahtlosen Netzwerk-Transceiver 2066 verwendet werden, einschließlich zum Beispiel Funkgeräte, die mit Standards übereinstimmen, die unter anderem von ITU (International Telecommunication Union) oder ETSI (European Telecommunications Standards Institute) herausgegeben werden. Die hierin bereitgestellten Beispiele werden daher als an diverse andere Kommunikationstechnologien, sowohl existierende als auch bisher noch nicht formulierte, anwendbar verstanden.
Ein Netzwerk-Schnittstellen-Controller (Network Interface Controller - NIC) 2068 kann enthalten sein, um eine verdrahtete Kommunikation mit der Cloud 2000 oder anderen Geräten, wie den Mesh-Geräten 2064, bereitzustellen. Die verdrahtete Kommunikation kann eine Ethernet-Verbindung bereitstellen oder kann auf anderen Netzwerktypen basieren, wie, unter vielen anderen, Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS oder PROFINET. Ein zusätzlicher NIC 2068 kann enthalten sein, um den Anschluss an ein zweites Netzwerk zu erlauben, zum Beispiel ein NIC 2068, der Kommunikationen zu der Cloud über Ethernet bereitstellt, und ein zweiter NIC 2068, der Kommunikationen zu anderen Geräten über einen beliebigen Netzwerktyp bereitstellt.
Angesichts der Vielfalt geltender Kommunikationstypen von dem Gerät zu einer anderen Komponente oder einem anderen Netzwerk, können anwendbare Kommunikationsschaltungen, die von dem Gerät verwendet werden, eine oder mehrere der Komponenten 1262, 1266, 1268 oder 1270 beinhalten oder von ihnen verkörpert werden. Bei diversen Beispielen können folglich anwendbare Mittel zum Kommunizieren (zum Beispiel Empfangen, Übertragen usw.) durch solche Kommunikationsschaltungen verkörpert werden.
Der Interconnect 2056 kann den Prozessor 2052 mit einer externen Schnittstelle 2070 koppeln, die verwendet wird, um externe Geräte oder Subsysteme anzuschließen. Die externen Geräte können Sensoren 2072 beinhalten, wie Beschleunigungsmesser, Pegelsensoren, Durchflusssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, Sensoren eines Global Positioning System (GPS), Drucksensoren, Luftdruckfühler und dergleichen. Die externe Schnittstelle 2070 kann ferner kann zum Verbinden des IoT-Geräts 2050 mit Aktuatoren 2074, wie Stromschaltern, Ventilaktuatoren und einem Generator hörbaren Tons, einer visuellen Warnvorrichtung und dergleichen verwendet werden.
Bei einigen optionalen Beispielen können diverse Eingangs-/Ausgangs-(E/A)-Vorrichtungen innerhalb des IoT-Geräts 2050 anwesend oder mit ihm verbunden sein. Ein Display oder ein anderes Ausgabegerät 2084 kann zum Beispiel enthalten sein, um Informationen, wie Sensorablesungen oder Aktuatorposition, zu zeigen. Eine Eingabevorrichtung 2086, wie ein Touchscreen oder ein Tastenfeld, kann zum Akzeptieren von Eingabe enthalten sein. Ein Ausgabegerät 2084 kann eine beliebige Anzahl von Formen von Audio- oder visueller Anzeige beinhalten, einschließlich einfache visuelle Ausgaben, wie binäre Statusindikatoren (zum Beispiel LEDs), und visuelle Mehrzeichenausgaben oder komplexere Ausgaben, wie Anzeigebildschirme (zum Beispiel LCD-Bildschirme), mit der Ausgabe von Zeichen, Grafiken, Multimediaobjekten und dergleichen, die aus dem Betrieb des IoT-Geräts 2050 erzeugt oder produziert wird.
Eine Batterie 2076 kann das IoT-Gerät 2050 mit Strom versorgen, obwohl bei Beispielen, bei welchen das IoT-Gerät 2050 an einem stationären Ort montiert ist, es eine Stromversorgung aufweisen kann, die mit einem Stromnetz gekoppelt ist. Die Batterie 2076 kann eine Lithium-Ionen-Batterie, eine Metall-Luft-Batterie, wie eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen sein.
Ein Batteriemonitor / -auflader 2078 kann in dem IoT-Gerät 2050 enthalten sein, um den Ladezustand (State of Charge - SoCh) der Batterie 2076 zu verfolgen. Der Batteriemonitor / -auflader 2078 kann verwendet werden, um andere Parameter der Batterie 2076 zu überwachen, um Ausfallvorhersage bereitzustellen, wie den Gesundheitszustand (State of Health - SoH) und den Funktionszustand (State of Function - SoF) der Batterie 2076. Der Batteriemonitor / -auflader 2078 kann eine integrierte Schaltung zur Batterieüberwachung, wie eine LTC4020 oder eine LTC2990 von Linear Technologies, eine ADT7488A von ON Semiconductor, in Phoenix Arizona, oder eine IC der UCD90xxx-Familie von Texas Instruments in Dallas, TX, beinhalten. Der Batteriemonitor / -auflader 2078 kann die Information über die Batterie 2076 zu dem Prozessor 2052 über den Interconnect 2056 kommunizieren. Der Batteriemonitor / -auflader 2078 kann auch einen Analog-Digital-Wandler (ADC) beinhalten, der es dem Prozessor 2052 erlaubt, die Spannung der Batterie 2076 oder den Stromfluss von der Batterie 2076 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Aktionen zu bestimmen, die das IoT-Gerät 2050 ausführen kann, wie Übertragungsfrequenz, Mesh-Netzwerkbetrieb, Abtastfrequenz und dergleichen.
Ein Leistungsblock 2080 oder eine andere Leistungsversorgung, die mit einem Stromnetz gekoppelt ist, kann mit dem Batteriemonitor / -auflader 2078 gekoppelt sein, um die Batterie 2076 aufzuladen. Bei einigen Beispielen kann der Leistungsblock 2080 mit einem drahtlosen Leistungsempfänger ersetzt werden, um die Leistung drahtlos zu erhalten, zum Beispiel durch eine Ringantenne in dem IoT-Gerät 2050. Eine drahtlose Batterieladeschaltung, wie, unter anderen, ein LTC4020-Chip von Linear Technologies in Milpitas, Kalifornien, kann in dem Batteriemonitor / -auflader 2078 enthalten sein. Die ausgewählten spezifischen Ladeschaltungen hängen von der Größe der Batterie 2076 und daher von dem erforderlichen Strom ab. Das Laden kann unter Verwenden unter anderen des Airfuel-Standards, der von Airfuel Alliance vertrieben wird, des drahtlosen Qi-Ladestandards, der von Wireless Power Consortium vertrieben wird, des Rezence-Ladestandards, der von der Alliance for Wireless Power vertrieben wird, ausgeführt werden.
Der Speicher 2058 kann Anweisungen 2082 in der Form von Software, Firmware oder Hardware-Befehlen beinhalten, um die hierin beschriebenen Techniken umzusetzen. Obwohl solche Anweisungen 2082 als Codeblöcke, die in dem Speicher 2054 und dem Speicher 2058 enthalten sind, gezeigt sind, versteht man, dass beliebige Codeblöcke durch verdrahtete Schaltungen, die zum Beispiel in einer anwendungsspezifischen integrierten Schaltung (Application-Specific Integrated Circuit - ASIC) eingebaut sind, ersetzt werden können.
Bei einem Beispiel können die Anweisungen 2082, die über den Speicher 2054, den Speicher 2058 oder den Prozessor 2052 bereitgestellt werden, als ein nicht flüchtiges, maschinenlesbares Medium 2060 verkörpert werden, das Code beinhaltet, um den Prozessor 2052 anzuweisen, elektronische Vorgänge in dem IoT-Gerät 2050 auszuführen. Der Prozessor 2052 kann auf das nichtflüchtige maschinenlesbare Medium 2060 über den Interconnect 2056 zugreifen. Das nichtflüchtige, maschinenlesbare Medium 2060 kann zum Beispiel durch Geräte verkörpert werden, die für den Speicher 2058 beschrieben sind, oder kann spezifische Speichereinheiten, wie optische Platten, Flash-Laufwerke oder eine beliebige Anzahl anderer Hardwaregeräte beinhalten. Das nichtflüchtige, maschinenlesbare Medium 2060 kann Anweisungen beinhalten, um den Prozessor 2052 anzuweisen, eine spezifische Abfolge oder einen Fluss von Aktionen auszuführen, wie zum Beispiel unter Bezugnahme auf das (die) Ablaufdiagramm(e) und Blockschaltbild(er) für Vorgänge und Funktionalität, die oben abgebildet sind, beschrieben.
Bei einem spezifischen Beispiel können die Anweisungen 2088 auf dem Prozessor 2052 (separat oder kombiniert mit den Anweisungen 2088 des maschinenlesbaren Mediums 2060) Ausführung oder Betrieb einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment - TEE) 2090 konfigurieren. Bei einem Beispiel arbeitet die TEE 2090 als ein geschützter Bereich, der für den Prozessor 2052 zur sicheren Ausführung von Anweisungen und zum sicheren Datenzugriff zugänglich ist. Diverse Umsetzungen der TEE 2090 und ein begleitendes sicheres Gebiet in dem Prozessor 2052 oder dem Speicher 2054 kann zum Beispiel durch Verwendung von Erweiterungen wie Intel® Software Guard (SGX) oder ARM® TrustZone® Hardware Security, IntelC® Management Engine (ME) oder Intel® Converged Security Manageability Engine (CSME) bereitgestellt werden.. Andere Aspekte von Sicherheitsverschärfung, Hardware-Roots-of-Trust und vertrauenswürdigen oder geschützten Vorgängen können in dem Gerät 2050 durch die TEE 2090 und den Prozessor 2052 umgesetzt werden.
Bei weiteren Beispielen beinhaltet das maschinenlesbare Medium auch ein beliebiges konkretes Medium, das fähig ist, Anweisungen zur Ausführung durch eine Maschine zu speichern, zu codieren oder zu tragen, und das die Maschine veranlassen kann, eine oder mehrere der Methodologien in der vorliegenden Offenbarung auszuführen, oder das fähig ist, Datenstrukturen, die von solchen Anweisungen eingesetzt oder mit ihnen assoziiert sind, zu speichern, zu codieren oder zu tragen. Ein „maschinenlesbares Medium“ kann daher, ohne darauf beschränkt zu sein, Festkörperspeicher und optische und magnetische Medien beinhalten. Spezifische Beispiele maschinenlesbarer Medien beinhalten nichtflüchtigen Speicher, einschließlich, ohne darauf beschränkt zu sein, beispielhaft Halbleiterspeichergeräte (zum Beispiel elektrisch programmierbarer Nurlesespeicher (Erasable Programmable Read-Only Memory - EPROM), elektrisch löschbarer programmierbarer Nurlesespeicher (Electrically Erasable Programmable Read-Only Memory - EEPROM)) und Flash-Speichergeräte; magnetische Platten, wie interne Festplatten und Wechselplatten; magneto-optische Platten; und CD-ROM- und DVD-ROM-Platten. Die Anweisungen, die von einem maschinenlesbaren Medium verkörpert werden, können ferner über ein Kommunikationsnetzwerk unter Verwenden eines Übertragungsmediums über ein Netzwerkschnittstellengerät unter Verwenden eines beliebigen einer Anzahl von Transferprotokollen (zum Beispiel HTTP) übertragen und empfangen werden.
Es ist klar, dass Funktionseinheiten oder Fähigkeiten, die in dieser Spezifikation beschrieben sind, Komponenten oder Module genannt wurden, um insbesondere ihre Umsetzungsunabhängigkeit zu betonen. Solche Komponenten können durch eine beliebige Anzahl von Software- oder Hardwareformen verkörpert werden. Eine Komponente oder ein Modul kann zum Beispiel als Hardware-Schaltung umgesetzt werden, die customisierte Very-Large-Scale-Integration-Schaltungen (VLSI-Schaltungen) oder Gate-Arrays, im Handel erhältliche Halbleiter, wie Logik-Chips, Transistoren oder andere separate Komponenten umfasst. Eine Komponente oder ein Modul kann auch in programmierbaren Hardware-Geräten umgesetzt werden, wie feldprogrammierbare Gate-Arrays, programmierbare Array-Logik, programmierbare Logikgeräte oder dergleichen. Komponenten oder Module können auch in Software zur Ausführung durch diverse Typen von Prozessoren umgesetzt werden. Eine identifizierte Komponente oder ein identifiziertes Modul ausführbaren Codes kann zum Beispiel einen oder mehrere physische oder logische Blöcke von Computeranweisungen umfassen, die zum Beispiel als ein Objekt, eine Vorgehensweise oder eine Funktion organisiert sind. Die ausführbaren Programme einer identifizierten Komponente oder eines identifizierten Moduls brauchen dennoch nicht physisch an demselben Ort zu sein, können aber disparate Anweisungen umfassen, die an unterschiedlichen Orten gespeichert sind, die, wenn sie logisch vereint werden, die Komponente oder das Modul umfassen und den genannten Zweck für die Komponente oder das Modul erzielen.
Eine Komponente oder ein Modul mit ausführbarem Code kann nämlich eine einzige Anweisung oder viele Anweisungen sein, und kann sogar über mehrere unterschiedliche Codesegmente, unter unterschiedlichen Programmen und über mehrere Speichergeräte oder Verarbeitungssysteme hinweg verteilt sein. Insbesondere können einige Aspekte des beschriebenen Prozesses (wie Code-Umschreiben und Code-Analyse) auf einem unterschiedlichen Verarbeitungssystem stattfinden (zum Beispiel in einem Computer in einem Datenzentrum), als das, auf dem der Code bereitgestellt ist (zum Beispiel in einem Computer, der in einem Sensor oder Roboter eingebettet ist). Auf ähnliche Art können Betriebsdaten hierin innerhalb von Komponenten oder Modulen identifiziert und veranschaulicht sein, und können in einer beliebigen zweckdienlichen Form verkörpert und innerhalb eines zweckdienlichen Datenstrukturtyps organisiert werden. Die Betriebsdaten können als ein einziger Datensatz gesammelt sein oder können über unterschiedliche Orte verteilt sein, einschließlich über unterschiedliche Speichergeräte, und können, wenigstens teilweise, lediglich als elektronische Signale auf einem System oder Netzwerk existieren. Die Komponenten oder Module können passiv oder aktiv sein, einschließlich Agenten, die betreibbar sind, um gewünschte Funktionen auszuführen.
Zusätzliche Beispiele des hiermit beschriebenen Verfahrens, Systems und der Gerätausführungsformen beinhalten die folgenden nicht einschränkenden Konfigurationen. Jedes der folgenden nicht einschränkenden Beispiele ist eigenständig oder kann in einer beliebigen Permutation oder Kombination mit einem oder mehreren der anderen Beispiele, die unten und durch die vorliegende Offenbarung hindurch bereitgestellt werden, kombiniert werden.
Beispiel 1 ist ein Gerät, das Folgendes umfasst: Kommunikationsschaltungen; Verarbeitungsschaltungen; und ein Speichergerät, das Anweisungen darauf verkörpert beinhaltet, wobei die Anweisungen, wenn sie von den Verarbeitungsschaltungen ausgeführt werden, die Verarbeitungsschaltungen konfigurieren, um Vorgänge auszuführen, die Folgendes umfassen: Empfangen einer ersten Anfrage von einem neuen Gerät um Netzwerkzugang, um eine Onboarding-Vorgehensweise mit einer Netzwerkplattform zu beginnen; Übertragen von Befugnissen eines ersten Netzwerks zu dem neuen Gerät, wobei ein Rendezvous-Service für das neue Gerät über das erste Netzwerk zugänglich ist, und wobei der Rendezvous-Service von dem neuen Gerät verwendet werden kann, um anfängliche Onboarding-Information in Zusammenhang mit der Netzwerkplattform zu erhalten; und Empfangen einer zweiten Anfrage von dem neuen Gerät um Netzwerkzugang, um die Onboarding-Vorgehensweise fortzusetzen, wobei die zweite Anfrage die anfängliche Onboarding-Information beinhaltet; und Übertragen von Befugnissen eines zweiten Netzwerks zu dem neuen Gerät, wobei ein Onboarding-Server der Netzwerkplattform über das zweite Netzwerk zugänglich ist, wobei der Onboarding-Server von dem neuen Gerät verwendet werden kann, um die Onboarding-Vorgehensweise mit der Netzwerkplattform auszuführen.
Bei Beispiel 2 beinhaltet der Gegenstand des Beispiels 1, dass die Befugnisse des ersten Netzwerks und des zweiten Netzwerks in jeweiligen Umgebungen für Kommunikationen über drahtlose Netzwerke, die gemäß einer Spezifikation der Familie der IEEE 802.11-Standards arbeiten, bereitgestellt werden.
Bei Beispiel 3 beinhaltet der Gegenstand des Beispiels 2: Übertragen von Rendezvous-Service-Information zu dem neuen Gerät, wobei die Rendezvous-Service-Informationen von dem neuen Gerät verwendet werden können, um sich an den Rendezvous-Service über das erste Netzwerk anzuschließen; wobei die erste Anfrage, die Rendezvous-Service-Information und die Befugnisse des ersten Netzwerks in sicheren Kommunikationen unter Verwenden eines Software-Zugangspunkts, der von dem neuen Gerät gehostet wird, ausgetauscht werden.
Bei Beispiel 4 beinhaltet der Gegenstand der Beispiele 2-3: Übertragen von Rendezvous-Service-Information zu dem neuen Gerät unter Verwenden einer Erkennungsbake, wobei die Rendezvous-Service-Informationen von dem neuen Gerät verwendet werden können, um sich an den Rendezvous-Service über das erste Netzwerk anzuschließen; wobei die erste Anfrage, die Rendezvous-Service-Information und die Befugnisse des ersten Netzwerks in der Erkennungsbake unter Verwenden eines Software-Zugangspunkts, der von dem Gerät gehostet wird, bereitgestellt werden.
Bei Beispiel 5 beinhaltet der Gegenstand der Beispiele 1 bis 4, dass der Netzwerkzugang die Onboarding-Vorgehensweise beginnt, und der Netzwerkzugang die Onboarding-Vorgehensweise, die über das Gerät, das als ein Proxy für das erste Netzwerk und das zweite Netzwerk arbeitet, geleitet wird, fortgesetzt wird.
Bei Beispiel 6 beinhaltet der Gegenstand der Beispiele 1 bis 5, dass das zweite Netzwerk ein Sandbox-Netzwerk ist, das verwendet wird, um die Onboarding-Vorgehensweise mit der Netzwerkplattform abzuschließen, wobei der Onboarding-Server ferner Befugnisse eines dritten Netzwerks für Netzwerkzugang zum Fortsetzen der Gerät-Servicevorgänge innerhalb der Netzwerkplattform bereitstellt.
Bei Beispiel 7 beinhaltet der Gegenstand der Beispiele 1 bis 6, dass die anfängliche Onboarding-Information eine Adresse des Onboarding-Servers beinhaltet, wobei ein Identifikator des neuen Geräts von dem Rendezvous-Service zu dem Onboarding-Service bereitgestellt wird.
Bei Beispiel 8 beinhaltet der Gegenstand des Beispiels 7, dass die anfängliche Onboarding-Information ferner den Identifikator des neuen Geräts und eine Nonce beinhaltet, wobei die anfängliche Onboarding-Information von dem Gerät verwendet wird, um die zweite Anfrage um Netzwerkzugang zu validieren, um die Onboarding-Vorgehensweise fortzusetzen.
Bei Beispiel 9 beinhaltet der Gegenstand der Beispiele 1 bis 8, dass der Rendezvous-Service ein Cloud-gehosteter Service ist, wobei der Rendezvous-Service ein Manifest einsetzt, um einen Gerätinhaber für die Onboarding-Vorgehensweise zu prüfen.
Bei Beispiel 10 beinhaltet der Gegenstand der Beispiele 1 bis 9, dass das erste Netzwerk ein nicht vertrauenswürdiges Netzwerk ist, das von dem zweiten Netzwerk isoliert ist, wobei der Rendezvous-Service Identifikationsinformation in Zusammenhang mit dem neuen Gerät prüft, bevor er dem neuen Gerät die anfängliche Onboarding-Information bereitstellt.
Bei Beispiel 11 beinhaltet der Gegenstand der Beispiele 1 bis 10, dass Vorgänge als Vorgänge eines Mediator-Service ausgeführt werden, wobei der Onboarding-Server als ein Gerätinhabertransferservice (DOTS) arbeitet, und wobei die Netzwerkplattform gemäß einer Open Connectivity Foundation-Spezifikation (OCF-Spezifikation) arbeitet.
Bei Beispiel 12 beinhaltet der Gegenstand der Beispiele 1 bis 11, dass die Vorgänge der Onboarding-Vorgehensweise in Verbindung mit Validierung des neuen Geräts durch den Onboarding-Server unter Verwenden einer Self-Sovereign-Identity-Blockchain ausgeführt werden.
Beispiel 13 ist ein Verfahren für ein Zero-Touch-Inhabertransferverfahren des Onboardings, das Vorgänge verwendet, die von einem Gerät ausgeführt werden, die Folgendes umfassen: Empfangen einer ersten Anfrage von einem neuen Gerät um Netzwerkzugang, um eine Onboarding-Vorgehensweise mit einer Netzwerkplattform zu beginnen; Übertragen von Befugnissen eines ersten Netzwerks zu dem neuen Gerät, wobei ein Rendezvous-Service für das neue Gerät über das erste Netzwerk zugänglich ist, und wobei der Rendezvous-Service von dem neuen Gerät verwendet werden kann, um anfängliche Onboarding-Information in Zusammenhang mit der Netzwerkplattform zu erhalten; und Empfangen einer zweiten Anfrage von dem neuen Gerät um Netzwerkzugang, um die Onboarding-Vorgehensweise fortzusetzen, wobei die zweite Anfrage die anfängliche Onboarding-Information beinhaltet; und Übertragen von Befugnissen eines zweiten Netzwerks zu dem neuen Gerät, wobei ein Onboarding-Server der Netzwerkplattform über das zweite Netzwerk zugänglich ist, wobei der Onboarding-Server von dem neuen Gerät verwendet werden kann, um die Onboarding-Vorgehensweise mit der Netzwerkplattform auszuführen.
Bei Beispiel 14 beinhaltet der Gegenstand des Beispiels 13, dass die Befugnisse des ersten Netzwerks und des zweiten Netzwerks in jeweiligen Umgebungen für Kommunikationen über drahtlose Netzwerke, die gemäß einer Spezifikation der Familie der IEEE 802.11-Standards arbeiten, bereitgestellt werden.
Bei Beispiel 15 beinhaltet der Gegenstand des Beispiels 14 das Übertragen von Rendezvous-Service-Information zu dem neuen Gerät, wobei die Rendezvous-Service-Information von dem neuen Gerät verwendet werden kann, um sich an den Rendezvous-Service über das erste Netzwerk anzuschließen; wobei die erste Anfrage, die Rendezvous-Service-Information und die Befugnisse des ersten Netzwerks in sicheren Kommunikationen unter Verwenden eines Software-Zugangspunkts, der von dem neuen Gerät gehostet wird, ausgetauscht werden.
Bei Beispiel 16 beinhaltet der Gegenstand der Beispiele 14-15 das Übertragen von Rendezvous-Service-Information zu dem neuen Gerät unter Verwenden einer Erkennungsbake, wobei die Rendezvous-Service-Information von dem neuen Gerät verwendet werden kann, um sich an den Rendezvous-Service über das erste Netzwerk anzuschließen; wobei die erste Anfrage, die Rendezvous-Service-Information und die Befugnisse des ersten Netzwerks in der Erkennungsbake unter Verwenden eines Software-Zugangspunkts, der von dem Gerät gehostet wird, bereitgestellt werden.
Bei Beispiel 17 beinhaltet der Gegenstand der Beispiele 13 bis 16, dass der Netzwerkzugang die Onboarding-Vorgehensweise beginnt, und der Netzwerkzugang die Onboarding-Vorgehensweise, die über das Gerät, das als ein Proxy für das erste Netzwerk und das zweite Netzwerk arbeitet, geleitet wird, fortgesetzt wird.
Bei Beispiel 18 beinhaltet der Gegenstand der Beispiele 13 bis 17, dass das zweite Netzwerk ein Sandbox-Netzwerk ist, das verwendet wird, um die Onboarding-Vorgehensweise mit der Netzwerkplattform abzuschließen, wobei der Onboarding-Server ferner Befugnisse eines dritten Netzwerks für Netzwerkzugang zum Fortsetzen der Gerät-Servicevorgänge innerhalb der Netzwerkplattform bereitstellt.
Bei Beispiel 19 beinhaltet der Gegenstand der Beispiele 13 bis 18, dass die anfängliche Onboarding-Information eine Adresse des Onboarding-Servers beinhaltet, wobei ein Identifikator des neuen Geräts von dem Rendezvous-Service zu dem Onboarding-Service bereitgestellt wird.
Bei Beispiel 20 beinhaltet der Gegenstand des Beispiels 19, dass die anfängliche Onboarding-Information ferner den Identifikator des neuen Geräts und eine Nonce beinhaltet, und wobei die anfängliche Onboarding-Information von dem Gerät verwendet wird, um die zweite Anfrage um Netzwerkzugang zu validieren, um die Onboarding-Vorgehensweise fortzusetzen.
Bei Beispiel 21 beinhaltet der Gegenstand der Beispiele 13 bis 20, dass der Rendezvous-Service ein Cloud-gehosteter Service ist, und wobei der Rendezvous-Service ein Manifest einsetzt, um einen Gerätinhaber für die Onboarding-Vorgehensweise zu prüfen.
Bei Beispiel 22 beinhaltet der Gegenstand der Beispiele 13 bis 21, dass das erste Netzwerk ein nicht vertrauenswürdiges Netzwerk ist, das von dem zweiten Netzwerk isoliert ist, und wobei der Rendezvous-Service Identifikationsinformation in Zusammenhang mit dem neuen Gerät prüft, bevor er dem neuen Gerät die anfängliche Onboarding-Information bereitstellt.
Bei Beispiel 23 beinhaltet der Gegenstand der Beispiele 13 bis 22, dass Vorgänge als Vorgänge eines Mediator-Service ausgeführt werden, wobei der Onboarding-Server als ein Gerätinhabertransferservice (DOTS) arbeitet, und wobei die Plattform gemäß einer Open Connectivity Foundation-Spezifikation (OCF-Spezifikation) arbeitet.
Bei Beispiel 24 beinhaltet der Gegenstand der Beispiele 13 bis 23, dass die Vorgänge der Onboarding-Vorgehensweise in Verbindung mit Validierung des neuen Geräts durch den Onboarding-Server unter Verwenden einer Self-Sovereign-Identity-Blockchain ausgeführt werden.
Beispiel 25 ist ein maschinenlesbares Speichermedium, das Anweisungen beinhaltet, wobei die Anweisungen, wenn sie von Verarbeitungsschaltungen eines Geräts ausgeführt werden, die Verarbeitungsschaltungen veranlassen, Vorgänge eines der Beispiele 13 bis 24 auszuführen.
Beispiel 26 ist ein Gerät, das Folgendes umfasst: Mittel zum Empfangen einer ersten Anfrage von einem neuen Gerät um Netzwerkzugang, um eine Onboarding-Vorgehensweise mit einer Netzwerkplattform zu beginnen; Mittel zum Übertragen von Befugnissen eines ersten Netzwerks zu dem neuen Gerät, wobei ein Rendezvous-Service für das neue Gerät über das erste Netzwerk zugänglich ist, und wobei der Rendezvous-Service von dem neuen Gerät verwendet werden kann, um anfängliche Onboarding-Information in Zusammenhang mit der Netzwerkplattform zu erhalten; und Mittel zum Empfangen einer zweiten Anfrage von dem neuen Gerät um Netzwerkzugang, um die Onboarding-Vorgehensweise fortzusetzen, wobei die zweite Anfrage die anfängliche Onboarding-Information beinhaltet; und Mittel zum Übertragen von Befugnissen eines zweiten Netzwerks zu dem neuen Gerät, wobei ein Onboarding-Server der Netzwerkplattform über das zweite Netzwerk zugänglich ist, wobei der Onboarding-Server von dem neuen Gerät verwendet werden kann, um die Onboarding-Vorgehensweise mit der Netzwerkplattform auszuführen.
Bei Beispiel 27 beinhaltet der Gegenstand des Beispiels 26 Mittel zum Zugreifen und Identifizieren der Befugnisse des ersten Netzwerks und des zweiten Netzwerks, wobei die Befugnisse jeweilige Umgebungen für Kommunikationen über drahtlose Netzwerke umfassen, die gemäß einer Spezifikation der Familie der IEEE 802.11-Standards arbeiten.
Bei Beispiel 28 beinhaltet der Gegenstand des Beispiels 27 Mittel zum Übertragen von Rendezvous-Service-Information zu dem neuen Gerät, wobei die Rendezvous-Service-Information von dem neuen Gerät verwendet werden kann, um sich an den Rendezvous-Service über das erste Netzwerk anzuschließen; wobei die erste Anfrage, die Rendezvous-Service-Information und die Befugnisse des ersten Netzwerks in sicheren Kommunikationen unter Verwenden eines Software-Zugangspunkts, der von dem neuen Gerät gehostet wird, ausgetauscht werden.
Bei Beispiel 29 beinhaltet der Gegenstand der Beispiele 27 bis 28 Mittel zum Übertragen von Rendezvous-Service-Information zu dem neuen Gerät unter Verwenden einer Erkennungsbake, wobei die Rendezvous-Service-Information von dem neuen Gerät verwendet werden kann, um sich an den Rendezvous-Service über das erste Netzwerk anzuschließen;
wobei die erste Anfrage, die Rendezvous-Service-Information und die Befugnisse des ersten Netzwerks in der Erkennungsbake unter Verwenden eines Software-Zugangspunkts, der von der Einrichtung gehostet wird, bereitgestellt werden.
Bei Beispiel 30 beinhaltet der Gegenstand der Beispiele 26 bis 29 Mittel zum Betreiben eines Proxy für das erste Netzwerk und das zweite Netzwerk, wobei der Netzwerkzugang zum Beginnen der Onboarding-Vorgehensweise und der Netzwerkzugang zum Fortsetzen der Onboarding-Vorgehensweise über das Gerät, das als der Proxy arbeitet, geleitet werden.
Bei Beispiel 31 beinhaltet der Gegenstand der Beispiele 26 bis 30, dass das zweite Netzwerk ein Sandbox-Netzwerk ist, das verwendet wird, um die Onboarding-Vorgehensweise mit der Netzwerkplattform abzuschließen, wobei der Onboarding-Server ferner Befugnisse eines dritten Netzwerks für Netzwerkzugang zum Fortsetzen der Gerät-Servicevorgänge innerhalb der Netzwerkplattform bereitstellt.
Bei Beispiel 32 beinhaltet der Gegenstand der Beispiele 26 bis 31, dass die anfängliche Onboarding-Information eine Adresse des Onboarding-Servers beinhaltet, wobei ein Identifikator des neuen Geräts von dem Rendezvous-Service zu dem Onboarding-Service bereitgestellt wird.
Bei Beispiel 33 beinhaltet der Gegenstand des Beispiels 32, dass die anfängliche Onboarding-Information ferner den Identifikator des neuen Geräts und eine Nonce beinhaltet, wobei die anfängliche Onboarding-Information von dem Gerät verwendet wird, um die zweite Anfrage um Netzwerkzugang zu validieren, um die Onboarding-Vorgehensweise fortzusetzen.
Bei Beispiel 34 beinhaltet der Gegenstand der Beispiele 26 bis 33, dass der Rendezvous-Service ein Cloud-gehosteter Service ist, wobei der Rendezvous-Service ein Manifest einsetzt, um einen Gerätinhaber für die Onboarding-Vorgehensweise zu prüfen.
Bei Beispiel 35 beinhaltet der Gegenstand der Beispiele 26 bis 34, dass das erste Netzwerk ein nicht vertrauenswürdiges Netzwerk ist, das von dem zweiten Netzwerk isoliert ist, wobei der Rendezvous-Service Identifikationsinformation in Zusammenhang mit dem neuen Gerät prüft, bevor er dem neuen Gerät die anfängliche Onboarding-Information bereitstellt.
Bei Beispiel 36 beinhaltet der Gegenstand der Beispiele 26 bis 35, dass das Gerät als ein Mediator-Service arbeitet, wobei der Onboarding-Server als ein Gerätinhabertransferservice (DOTS) arbeitet, und wobei die Netzwerkplattform gemäß einer Open Connectivity Foundation-Spezifikation (OCF-Spezifikation) arbeitet.
Bei Beispiel 37 beinhaltet der Gegenstand der Beispiele 26 bis 36, dass die Vorgänge der Onboarding-Vorgehensweise in Verbindung mit Validierung des neuen Geräts durch den Onboarding-Server unter Verwenden einer Self-Sovereign-Identity-Blockchain ausgeführt werden.
Beispiel 38 ist ein Open Connectivity Foundation-Gerät (OCF-Gerät), das als ein Server, ein Client oder ein Intermediär gemäß einer OCF-Spezifikation konfiguriert ist, das Mittel zum Umsetzen der Vorgänge eines der Beispiele 1 bis 37 umfasst.
Beispiel 39 ist ein Gerätinhabertransferservice-Managementservice, der angepasst ist, um die Vorgänge, die von einem der Beispiele 1 bis 37 abgerufen werden, auszuführen.
Beispiel 40 ist ein Zugangsmanagement-Service, der angepasst ist, um die Vorgänge, die von einem der Beispiele 1 bis 37 abgerufen werden, auszuführen.
Beispiel 41 ist ein Befugnismanagement-Service, der angepasst ist, um die Vorgänge, die von einem der Beispiele 1 bis 37 abgerufen werden, auszuführen.
Beispiel 42 ist eine Internet-der-Dinge-Netzwerktopologie (IoT-Netzwerktopologie), wobei die IoT-Netzwerktopologie jeweilige Kommunikationslinks umfasst, die angepasst sind, um Kommunikationen für die Vorgänge eines der Beispiele 1 bis 37 auszuführen.
Beispiel 43 ist ein Netzwerk, das jeweilige Geräte und Gerätkommunikationsmedien zum Ausführen eines der Vorgänge der Beispiele 1 bis 37 umfasst
Beispiel 44 ist eine Edge-Cloud-Computing-Gerätumsetzung, die Verarbeitungsknoten und Computing-Einheiten umfasst, die zum Ausführen eines der Vorgänge der Beispiele 1 bis 37 angepasst sind.
Beispiel 45 ist eine Edge-Cloud-Netzwerkplattform, die physische und logische Computing-Ressourcen umfasst, die zum Ausführen eines der Vorgänge der Beispiele 1 bis 37 angepasst sind.
Beispiel 46 ist ein Gerät, das Mittel zum Ausführen eines der Vorgänge der Beispiele 1 bis 37 umfasst.
Beispiel 47 ist ein System zum Ausführen der Vorgänge eines der Beispiele 1 bis 37.
Die Vorgänge und Funktionalität, die oben in diesen Beispielen sowie in den spezifischen Ausführungsformen beschrieben sind, die unter Bezugnahme auf die 3 bis 18 beschrieben sind, können in einer Vielfalt von Netzwerkumgebungen, wie IoT-Networking, Edge-Networking, Fog-Networking, Cloud-Networking und allen Hybriden davon gelten. Die Vorgänge und Funktionalität dieser Beispiele und Konfigurationen können auf eine verteilte Art auftreten, einschließlich in verteilten Netzwerkumgebungen, wo ein Aspekt der Funktionalität von einem ersten IoT-Edge-Gerät oder Edge-Netzwerk ausgeführt wird, ein anderer Aspekt der Funktionalität von einem Fog-Netzwerk oder einer Fog-Plattform ausgeführt wird, und noch ein anderer Aspekt der Funktionalität von einem Cloud-Gerät oder Cloud-System ausgeführt wird. Weitere Kombinationen, die diesen gemeinsamen, verteilten oder Gruppierungskonzepten folgen, wie in den Beispielen und Konfigurationen oben angedeutet, können eingesetzt werden. Folglich ist offensichtlich, dass die Funktionalität, die hierin beschrieben ist, umgesetzt werden kann, um innerhalb vieler Permutationen der oben stehenden Beispiele und Konfigurationen und ähnlicher Variationen betreibbar zu sein.
In der oben stehenden ausführlichen Beschreibung können diverse Merkmale gruppiert sein, um die Offenbarung zu rationalisieren. Die Ansprüche legen jedoch eventuell nicht jedes Merkmal dar, das hierin offenbart ist, da Ausführungsformen einen Teilsatz der Merkmale aufweisen können. Ferner können Ausführungsformen weniger Merkmale als diejenigen, die in einem besonderen Beispiel offenbart sind, beinhalten. Die folgenden Ansprüche werden daher hiermit in die ausführliche Beschreibung aufgenommen, wobei jeder Anspruch als eine getrennte Ausführungsform eigenständig ist.
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 62/582134 [0001]

Claims

Gerät, das Folgendes umfasst: Kommunikationsschaltungen; Verarbeitungsschaltungen; und ein Speichergerät, das Anweisungen darauf verkörpert beinhaltet, wobei die Anweisungen, wenn sie von den Verarbeitungsschaltungen ausgeführt werden, die Verarbeitungsschaltungen konfigurieren, um Vorgänge auszuführen, die Folgendes umfassen: Empfangen einer ersten Anfrage von einem neuen Gerät um Netzwerkzugang, um eine Onboarding-Vorgehensweise mit einer Netzwerkplattform zu beginnen; Übertragen von Befugnissen eines ersten Netzwerks zu dem neuen Gerät, wobei ein Rendezvous-Service für das neue Gerät über das erste Netzwerk zugänglich ist, und wobei der Rendezvous-Service von dem neuen Gerät verwendet werden kann, um anfängliche Onboarding-Information, die mit der Netzwerkplattform assoziiert ist, zu erhalten; und Empfangen einer zweiten Anfrage von dem neuen Gerät um Netzwerkzugang, um die Onboarding-Vorgehensweise fortzusetzen, wobei die zweite Anfrage die anfängliche Onboarding-Information beinhaltet; und Übertragen von Befugnissen eines zweiten Netzwerks zu dem neuen Gerät, wobei ein Onboarding-Server der Netzwerkplattform über das zweite Netzwerk zugänglich ist, wobei der Onboarding-Server von dem neuen Gerät verwendet werden kann, um die Onboarding-Vorgehensweise mit der Netzwerkplattform auszuführen.
Gerät nach Anspruch 1, wobei die Befugnisse des ersten Netzwerks und des zweiten Netzwerks jeweilige Umgebungen für Kommunikationen über drahtlose Netzwerke umfassen, die gemäß einer Spezifikation einer Familie der IEEE 802.11-Standards arbeiten.
Gerät nach Anspruch 2, wobei die Vorgänge ferner Folgendes umfassen: Übertragen von Rendezvous-Service-Information zu dem neuen Gerät, wobei die Rendezvous-Service-Information von dem neuen Gerät verwendet werden kann, um sich mit dem Rendezvous-Service über das erste Netzwerk zu verbinden; wobei die erste Anfrage, die Rendezvous-Service-Information und die Befugnisse des ersten Netzwerks in sicheren Kommunikationen unter Verwenden eines Software-Zugangspunkts, der von dem neuen Gerät gehostet wird, ausgetauscht werden.
Gerät nach Anspruch 2, wobei die Vorgänge ferner Folgendes umfassen: Übertragen von Rendezvous-Service-Information zu dem neuen Gerät, unter Verwenden einer Erkennungsbake, wobei die Rendezvous-Service-Information von dem neuen Gerät verwendet werden kann, um sich mit dem Rendezvous-Service über das erste Netzwerk zu verbinden; wobei die erste Anfrage, die Rendezvous-Service-Information und die Befugnisse des ersten Netzwerks in der Erkennungsbake unter Verwenden eines Software-Zugangspunkts, der von dem Gerät gehostet wird, bereitgestellt werden.
Gerät nach Anspruch 1, wobei der Netzwerkzugang zum Beginnen der Onboarding-Vorgehensweise und der Netzwerkzugang zum Fortsetzen der Onboarding-Vorgehensweise über das Gerät geleitet werden, das als ein Proxy für das erste Netzwerk und das zweite Netzwerk arbeitet.
Gerät nach Anspruch 1, wobei das zweite Netzwerk ein Sandbox-Netzwerk ist, das verwendet wird, um die Onboarding-Vorgehensweise mit der Netzwerkplattform abzuschließen; wobei der Onboarding-Server ferner Befugnisse eines dritten Netzwerks für Netzwerkzugang bereitstellt, um Gerät-Servicevorgänge innerhalb der Netzwerkplattform fortzusetzen.
Gerät nach Anspruch 1, wobei die anfängliche Onboarding-Information eine Adresse des Onboarding-Servers beinhaltet, und wobei ein Identifikator des neuen Geräts von dem Rendezvous-Service zu dem Onboarding-Service bereitgestellt wird.
Gerät nach Anspruch 7, wobei die anfängliche Onboarding-Information ferner den Identifikator des neuen Geräts und eine Nonce beinhaltet, und wobei die anfängliche Onboarding-Information von dem Gerät verwendet wird, um die zweite Anfrage um Netzwerkzugang zu validieren, um die Onboarding-Vorgehensweise fortzusetzen.
Gerät nach Anspruch 1, wobei der Rendezvous-Service ein Cloud-gehosteter Service ist, und wobei der Rendezvous-Service ein Manifest einsetzt, um einen Gerätinhaber für die Onboarding-Vorgehensweise zu prüfen.
Gerät nach Anspruch 1, wobei das erste Netzwerk ein nicht vertrauenswürdiges Netzwerk ist, das von dem zweiten Netzwerk isoliert ist, und der Rendezvous-Service Identifikationsinformation in Zusammenhang mit dem neuen Gerät prüft, bevor er dem neuen Gerät die anfängliche Onboarding-Information bereitstellt.
Gerät nach Anspruch 1, wobei die Vorgänge als Vorgänge eines Mediator-Service ausgeführt werden, wobei der Onboarding-Server als ein Gerätinhaberübertragungsservice (DOTS) arbeitet, und wobei die Netzwerkplattform gemäß einer Open Connectivity Foundation-Spezifikation (OCF-Spezifikation) arbeitet.
Gerät nach Anspruch 1, wobei die Vorgänge der Onboarding-Vorgehensweise in Verbindung mit Validierung des neuen Geräts durch den Onboarding-Server unter Verwenden einer Self-Sovereign-Identity-Blockchain ausgeführt werden.
Verfahren für ein Zero-Touch-Inhabertransferverfahren des Onboardings, das Vorgänge verwendet, die von einem Gerät ausgeführt werden, die Folgendes umfassen: Empfangen einer ersten Anfrage von einem neuen Gerät um Netzwerkzugang, um eine Onboarding-Vorgehensweise mit einer Netzwerkplattform zu beginnen; Übertragen von Befugnissen eines ersten Netzwerks zu dem neuen Gerät, wobei ein Rendezvous-Service für das neue Gerät über das erste Netzwerk zugänglich ist, und wobei der Rendezvous-Service von dem neuen Gerät verwendet werden kann, um anfängliche Onboarding-Information, die mit der Netzwerkplattform assoziiert ist, zu erhalten; und Empfangen einer zweiten Anfrage von dem neuen Gerät um Netzwerkzugang, um die Onboarding-Vorgehensweise fortzusetzen, wobei die zweite Anfrage die anfängliche Onboarding-Information beinhaltet; und Übertragen von Befugnissen eines zweiten Netzwerks zu dem neuen Gerät, wobei ein Onboarding-Server der Netzwerkplattform über das zweite Netzwerk zugänglich ist, wobei der Onboarding-Server von dem neuen Gerät verwendet werden kann, um die Onboarding-Vorgehensweise mit der Netzwerkplattform auszuführen.
Verfahren nach Anspruch 13, wobei die Befugnisse des ersten Netzwerks und des zweiten Netzwerks, jeweilige Umgebungen für Kommunikationen über drahtlose Netzwerke umfassen, die gemäß einer Spezifikation einer Familie der IEEE 802.11-Standards arbeiten.
Verfahren nach Anspruch 14, das weiter Folgendes umfasst: Übertragen von Rendezvous-Service-Information zu dem neuen Gerät, wobei die Rendezvous-Service-Information von dem neuen Gerät verwendet werden kann, um sich mit dem Rendezvous-Service über das erste Netzwerk zu verbinden; wobei die erste Anfrage, die Rendezvous-Service-Information und die Befugnisse des ersten Netzwerks in sicheren Kommunikationen unter Verwenden eines Software-Zugangspunkts, der von dem neuen Gerät gehostet wird, ausgetauscht werden.
Verfahren nach Anspruch 14, das weiter Folgendes umfasst: Übertragen von Rendezvous-Service-Information zu dem neuen Gerät, unter Verwenden einer Erkennungsbake, wobei Rendezvous-Service-Information von dem neuen Gerät verwendet werden kann, um sich mit dem Rendezvous-Service über das erste Netzwerk zu verbinden; wobei die erste Anfrage, die Rendezvous-Service-Information und die Befugnisse des ersten Netzwerks in der Erkennungsbake unter Verwenden eines Software-Zugangspunkts, der von dem Gerät gehostet wird, bereitgestellt werden.
Verfahren nach Anspruch 13, wobei der Netzwerkzugang zum Beginnen der Onboarding-Vorgehensweise und der Netzwerkzugang zum Fortsetzen der Onboarding-Vorgehensweise über das Gerät geleitet werden, das als ein Proxy für das erste Netzwerk und das zweite Netzwerk arbeitet.
Verfahren nach Anspruch 13, wobei das zweite Netzwerk ein Sandbox-Netzwerk ist, das verwendet wird, um die Onboarding-Vorgehensweise mit der Netzwerkplattform abzuschließen; wobei der Onboarding-Server ferner Befugnisse eines dritten Netzwerks für Netzwerkzugang bereitstellt, um Gerät-Servicevorgänge innerhalb der Netzwerkplattform fortzusetzen.
Verfahren nach Anspruch 13, wobei die anfängliche Onboarding-Information eine Adresse des Onboarding-Servers beinhaltet, und wobei ein Identifikator des neuen Geräts von dem Rendezvous-Service zu dem Onboarding-Service bereitgestellt wird.
Verfahren nach Anspruch 19, wobei die anfängliche Onboarding-Information ferner den Identifikator des neuen Geräts und eine Nonce beinhaltet, und wobei die anfängliche Onboarding-Information von dem Gerät verwendet wird, um die zweite Anfrage um Netzwerkzugang zu validieren, um die Onboarding-Vorgehensweise fortzusetzen.
Verfahren nach Anspruch 13, wobei der Rendezvous-Service ein Cloud-gehosteter Service ist, und wobei der Rendezvous-Service ein Manifest einsetzt, um einen Gerätinhaber für die Onboarding-Vorgehensweise zu prüfen.
Verfahren nach Anspruch 13, wobei das erste Netzwerk ein nicht vertrauenswürdiges Netzwerk ist, das von dem zweiten Netzwerk isoliert ist, und der Rendezvous-Service Identifikationsinformation in Zusammenhang mit dem neuen Gerät prüft, bevor er dem neuen Gerät die anfängliche Onboarding-Information bereitstellt.
Verfahren nach Anspruch 13, wobei die Vorgänge als Vorgänge eines Mediator-Service ausgeführt werden, wobei der Onboarding-Server als ein Gerätinhaberübertragungsservice (DOTS) arbeitet, und wobei die Netzwerkplattform gemäß einer Open Connectivity Foundation-Spezifikation (OCF-Spezifikation) arbeitet.
Verfahren nach Anspruch 13, wobei die Vorgänge der Onboarding-Vorgehensweise in Verbindung mit Validierung des neuen Geräts durch den Onboarding-Server unter Verwenden einer Self-Sovereign-Identity-Blockchain ausgeführt werden.
Maschinenlesbares Speichermedium, das Anweisungen beinhaltet, wobei die Anweisungen, wenn sie von Verarbeitungsschaltungen eines Geräts ausgeführt werden, die Verarbeitungsschaltungen veranlassen, Vorgänge eines der Ansprüche 13 bis 24 auszuführen.
Einrichtung, die Folgendes umfasst: Mittel zum Empfangen einer ersten Anfrage von einem neuen Gerät um Netzwerkzugang, um eine Onboarding-Vorgehensweise mit einer Netzwerkplattform zu beginnen; Mittel zum Übertragen von Befugnissen eines ersten Netzwerks zu dem neuen Gerät, wobei ein Rendezvous-Service für das neue Gerät über das erste Netzwerk zugänglich ist, und wobei der Rendezvous-Service von dem neuen Gerät verwendet werden kann, um anfängliche Onboarding-Information, die mit der Netzwerkplattform assoziiert ist, zu erhalten; und Mittel zum Empfangen einer zweiten Anfrage von dem neuen Gerät um Netzwerkzugang, um die Onboarding-Vorgehensweise fortzusetzen, wobei die zweite Anfrage die anfängliche Onboarding-Information beinhaltet; und Mittel zum Übertragen von Befugnissen eines zweiten Netzwerks zu dem neuen Gerät, wobei ein Onboarding-Server der Netzwerkplattform über das zweite Netzwerk zugänglich ist, wobei der Onboarding-Server von dem neuen Gerät verwendet werden kann, um die Onboarding-Vorgehensweise mit der Netzwerkplattform auszuführen.
Einrichtung nach Anspruch 26, die ferner Folgendes umfasst: Mittel zum Zugreifen auf die und Identifizieren der Befugnisse des ersten Netzwerks und des zweiten Netzwerks, wobei die Befugnisse jeweilige Umgebungen für Kommunikationen über drahtlose Netzwerke umfassen, die gemäß einer Spezifikation einer Familie der IEEE 802.11-Standards arbeiten.
Einrichtung nach Anspruch 27, die ferner Folgendes umfasst: Mittel zum Übertragen von Rendezvous-Service-Information zu dem neuen Gerät, wobei die Rendezvous-Service-Information von dem neuen Gerät verwendet werden kann, um sich mit dem Rendezvous-Service über das erste Netzwerk zu verbinden; wobei die erste Anfrage, die Rendezvous-Service-Information und die Befugnisse des ersten Netzwerks in sicheren Kommunikationen unter Verwenden eines Software-Zugangspunkts, der von dem neuen Gerät gehostet wird, ausgetauscht werden.
Einrichtung nach Anspruch 27, die ferner Folgendes umfasst: Mittel zum Übertragen von Rendezvous-Service-Information zu dem neuen Gerät, unter Verwenden einer Erkennungsbake, wobei Rendezvous-Service-Information von dem neuen Gerät verwendet werden kann, um sich mit dem Rendezvous-Service über das erste Netzwerk zu verbinden; wobei die erste Anfrage, die Rendezvous-Service-Information und die Befugnisse des ersten Netzwerks in der Erkennungsbake unter Verwenden eines Software-Zugangspunkts, der von dem Gerät gehostet wird, bereitgestellt werden.
Einrichtung nach Anspruch 26, die ferner Folgendes umfasst: Mittel zum Betreiben eines Proxy für das erste Netzwerk und das zweite Netzwerk, wobei der Netzwerkzugang zum Beginnen der Onboarding-Vorgehensweise und der Netzwerkzugang zum Fortsetzen der Onboarding-Vorgehensweise über die Einrichtung, die als der Proxy arbeitet, geleitet werden.
Einrichtung nach Anspruch 26, wobei das zweite Netzwerk ein Sandbox-Netzwerk ist, das verwendet wird, um die Onboarding-Vorgehensweise mit der Netzwerkplattform abzuschließen, wobei der Onboarding-Server ferner Befugnisse eines dritten Netzwerks für Netzwerkzugang bereitstellt, um Gerät-Servicevorgänge innerhalb der Netzwerkplattform fortzusetzen.
Einrichtung nach Anspruch 26, wobei die anfängliche Onboarding-Information eine Adresse des Onboarding-Servers beinhaltet, und wobei ein Identifikator des neuen Geräts von dem Rendezvous-Service zu dem Onboarding-Service bereitgestellt wird.
Einrichtung nach Anspruch 32, wobei die anfängliche Onboarding-Information ferner den Identifikator des neuen Geräts und eine Nonce beinhaltet, und wobei die anfängliche Onboarding-Information von dem Gerät verwendet wird, um die zweite Anfrage um Netzwerkzugang zu validieren, um die Onboarding-Vorgehensweise fortzusetzen.
Einrichtung nach Anspruch 26, wobei der Rendezvous-Service ein Cloud-gehosteter Service ist, und wobei der Rendezvous-Service ein Manifest einsetzt, um einen Gerätinhaber für die Onboarding-Vorgehensweise zu prüfen.
Gerät nach Anspruch 26, wobei das erste Netzwerk ein nicht vertrauenswürdiges Netzwerk ist, das von dem zweiten Netzwerk isoliert ist, und der Rendezvous-Service Identifikationsinformation in Zusammenhang mit dem neuen Gerät prüft, bevor er dem neuen Gerät die anfängliche Onboarding-Information bereitstellt.
Einrichtung nach Anspruch 26, wobei die Einrichtung Vorgänge eines Mediator-Service ausführt, wobei der Onboarding-Server als ein Gerätinhaberübertragungsservice (DOTS) arbeitet, und wobei die Netzwerkplattform gemäß einer Open Connectivity Foundation-Spezifikation (OCF-Spezifikation) arbeitet.
Einrichtung nach Anspruch 26, wobei die Vorgänge der Onboarding-Vorgehensweise in Verbindung mit Validierung des neuen Geräts durch den Onboarding-Server unter Verwenden einer Self-Sovereign-Identity-Blockchain ausgeführt werden.