DE112018006935T5 - Sicherheitsprofile für OCF-Vorrichtungen und vertrauenswürdige Plattformen - Google Patents

Sicherheitsprofile für OCF-Vorrichtungen und vertrauenswürdige Plattformen Download PDF

Info

Publication number
DE112018006935T5
DE112018006935T5 DE112018006935.4T DE112018006935T DE112018006935T5 DE 112018006935 T5 DE112018006935 T5 DE 112018006935T5 DE 112018006935 T DE112018006935 T DE 112018006935T DE 112018006935 T5 DE112018006935 T5 DE 112018006935T5
Authority
DE
Germany
Prior art keywords
platform
manufacturer
certificate
question
trust anchor
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112018006935.4T
Other languages
English (en)
Inventor
Eduardo Cabre
Nathan Heldt-Sheller
Ned M. Smith
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE112018006935T5 publication Critical patent/DE112018006935T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Im Vorliegenden werden verschiedene Systeme und Verfahren zum Erstellen von Sicherheitsprofilen für Internets der Dinge (Internet of Things, IoT) Vorrichtungen und vertrauenswürdige Plattformen unter Einschluss in Einsätzen von OCF-Spezifikationsvorrichtungen erläutert. In einem Beispiel beinhaltet eine Technik zum Onboarding („An Bord Nehmen“) einer betreffenden Vorrichtung zur Verwendung mit einem Sicherheitsprofil: Empfangen einer Anforderung zum Durchführen eines Eigentümerübertragungsverfahrens einer Vorrichtung, die einer Vorrichtungsplattform zugeordnet ist; Verifizieren eines Beglaubigungszeugnisses, das der betreffenden Vorrichtung zugeordnet ist, wobei das Beglaubigungszeugnis durch ein Zertifikat signiert wird, das unter Verwendung eines herstellerseitig eingebetteten Schlüssels erzeugt wird, wobei der Schlüssel von einer vertrauenswürdigen Hardwarekomponente der Vorrichtungsplattform vorgesehen wird; und Durchführen einer Vorrichtungsversorgung der betreffenden Vorrichtung auf der Grundlage des Beglaubigungszeugnisses, da die Vorrichtungsversorgung die betreffende Vorrichtung dazu veranlasst, ein Sicherheitsprofil zu verwenden, das an herstellerseitig eingebettete Schlüssel gebunden ist.

Description

  • PRIORITÄTANSPRUCH
  • Diese Anmeldung beansprucht den Vorteil der Priorität der vorläufigen Patentanmeldung der Vereinigten Staaten mit der Seriennummer 62/621 376, eingereicht am 24. Januar 2018 mit dem Titel „SECURITY PROFILES FOR OCF DEVICES AND TRUSTED PLATFORMS“, auf deren Beschreibung hier zur Gänze Bezug genommen wird.
  • TECHNISCHER BEREICH
  • Die hier beschriebenen Ausführungsformen betreffen im Allgemeinen Datenkommunikation und Netzwerke miteinander verbundener Vorrichtungen und insbesondere Techniken zur Errichtung von Verbindungen und zum Durchführen einer Funktionalität zwischen Vorrichtungen des Internet der Dinge (Internet of Things, IoT) und Vorrichtungsnetzwerken.
  • HINTERGRUND
  • IoT-Vorrichtungen sind physische oder virtualisierte Objekte, die in einem Netzwerk kommunizieren können und Sensoren, Aktoren und sonstige Ein-/Ausgabekomponenten enthalten können, um beispielsweise Daten zu sammeln oder Handlungen in einer realen Umgebung durchzuführen. IoT-Vorrichtungen können beispielsweise Vorrichtungen mit geringer Leistung beinhalten, die in alltägliche Dinge wie Gebäude, Fahrzeuge, Verpackungen und dergleichen eingebettet oder daran befestigt sind, um eine zusätzliche Ebene einer künstlichen sensorischen Wahrnehmung dieser Dinge zu schaffen. In jüngster Zeit sind IoT-Vorrichtungen immer beliebter geworden, so dass Anwendungen, die diese Vorrichtungen verwenden, immer mehr Verbreitung finden.
  • Es wurden verschiedene Standards vorgeschlagen, um IoT-Vorrichtungen und IoT-Netzwerk-Anwendungsfälle wirkungsvoller miteinander zu verbinden und zu betreiben. Dazu gehören die Spezialisierung von Kommunikationsstandards, die von Gruppen wie dem Institute of Electrical and Electronics Engineers (IEEE) verteilt werden, und die Spezialisierung von Anwendungs-Interaktionsarchitektur und Konfigurationsstandards, die von Gruppen wie der Open Connectivity Foundation (OCF) verteilt werden.
  • Figurenliste
  • In den Zeichnungen, die nicht unbedingt maßstabgetreu gezeichnet sind, können in unterschiedlichen Ansichten gleiche Bezugsnummern ähnliche Komponenten bezeichnen. Gleiche Bezugsnummern, die unterschiedliche Buchstabensuffixe aufweisen, können unterschiedliche Ausprägungen ähnlicher Komponenten repräsentieren. Einige Ausführungsformen werden in den Figuren der beiliegenden Zeichnungen beispielhaft und nicht beschränkend dargestellt, in denen:
    • 1 eine Domänentopologie für entsprechende Internet der Dinge (IoT) Netzwerke zeigt, die durch Links mit entsprechenden Gateways gekoppelt sind, gemäß einem Beispiel;
    • 2 ein Cloud-Computernetzwerk in Kommunikation mit einem Maschennetzwerk von IoT-Vorrichtungen zeigt, die als Fog-Vorrichtung an dem Rand des Cloud-Computernetzwerks arbeiten, gemäß einem Beispiel;
    • 3 eine Konfiguration und einen Betrieb von OCF-Vorrichtungen zeigt, die auf einer vertrauenswürdigen Plattform verwaltet werden, gemäß einem Beispiel;
    • 4 ein Flussdiagramm eines Verfahrens zur Vorrichtungskonformität für die Verwendung von Vorrichtungen auf einer vertrauenswürdigen Plattform zeigt, gemäß einem Beispiel;
    • 5 ein Flussdiagramm eines Verfahrens zur Plattformkonformität für die Verwendung einer vertrauenswürdigen Plattform zeigt, gemäß einem Beispiel;
    • 6 ein Flussdiagramm einer vertrauenswürdigen Boot-Sequenz für Vorrichtungen in einer vertrauenswürdigen Plattform zeigt, gemäß einem Beispiel;
    • 7 ein Flussdiagramm eines Verfahrens für ein vertrauenswürdiges oder beglaubigtes Onboarding einer Vorrichtung für Vorrichtungen in einer vertrauenswürdigen Plattform zeigt, gemäß einem Beispiel;
    • 8 ein Flussdiagramm von Operationen von Vorrichtung-zu-Vorrichtung für Vorrichtungen in einer vertrauenswürdigen Plattform zeigt, gemäß einem Beispiel;
    • 9 ein Flussdiagramm eines Verfahrens zum Onboarding einer betreffenden Vorrichtung zur Verwendung mit einem Sicherheitsprofil zeigt, gemäß einem Beispiel;
    • 10 ein Blockdiagramm eines Netzwerks zeigt, das die Kommunikation zwischen einer Reihe von IoT-Vorrichtungen veranschaulicht, gemäß einem Beispiel; und
    • 11 ein Blockdiagramm für eine beispielhafte IoT-Verarbeitungssystemarchitektur zeigt, auf der eine oder mehrere der hier erörterten Techniken (z.B. Operationen, Prozesse, Verfahren und Methodologien) ausgeführt werden können.
  • DETAILLIERTE BESCHREIBUNG
  • In der folgenden Beschreibung werden Verfahren, Konfigurationen und verwandte Einrichtungen für die Verwendung einer vertrauenswürdigen Plattform zur Unterstützung von Sicherheitsprofilen zwischen entsprechenden IoT-Vorrichtungen offenbart. In einem Beispiel, das auf eine OCF-Vorrichtungskonfiguration anwendbar ist, die Public-Key-Infrastruktur(PKI)-Komponenten umfasst, kann eine solche Plattform den Einsatz von OCF-Vorrichtungen und -Diensten ermöglichen, die von einer gemeinsamen Wurzel-Zertifizierungsstelle (Certificate Authority, CA) (z.B. einer CA, die sich im Besitz der OCF oder einer anderen vertrauenswürdigen Organisation befindet oder von ihr betrieben wird) generierte Zertifikate verwenden und gleichzeitig die Gültigkeit der Zertifikate unter Verwendung eines Sicherheitsprofils und einer zugeordneten Beglaubigung sicherstellen.
  • Die Verwendung und Konfiguration einer vertrauenswürdigen Plattform, wie sie hier erörtert wird, kann Aspekte der Trusted Computing Group (TCG) Technologie und die Eingliederung von TCG-Funktionen in einen Einsatz eines OCF- oder ähnlichen IoT-Netzwerks beinhalten. Die folgenden Techniken ermöglichen es, eine OCF-Vorrichtung an eine TCG-regelkonforme Plattform zu binden, z.B. durch ein Verwenden von TCG-Plattform-Zertifikaten zur Verknüpfung mit OCF-Vertrauenszusicherungen. Darüber hinaus kann die Verwendung dieser vertrauenswürdigen Plattform es ermöglichen, Vertrauen direkt zwischen den jeweiligen OCF-Vorrichtungen herzustellen und die Regeleinhaltung mit den veröffentlichten elektronischen Ergebnissen zu prüfen.
  • Die folgenden Techniken können z.B. verwendet werden, um es einer Normen- oder Überwachungsorganisation zu ermöglichen, ein Dokument zu unterzeichnen, das den Status von Regeleinhaltungstests aufnimmt. Die Organisation kann dann feststellen, welchen Vertrauensanker die Organisation verwendet, und diese Informationen an die entsprechenden Onboarding-Tools (OBTs) und Dienste weiterleiten.
  • Die folgenden Techniken ermöglichen es einer Organisation ferner, die von der Organisation ausgewählte CA unter Verwendung einer öffentlichen Blockkette zu veröffentlichen. Die von dem Netzwerkeinsatz verwendeten OBTs können die Blockkette abfragen, um zuverlässig den aktuellsten veröffentlichten Vertrauens anker zu finden. Wenn irgendwelche der Schlüssel, die in der CA-Hierarchie zwischen der Organisation und ihrer gewählten Wurzel gefunden wurden, gefährdet wurden, kann eine seriöse Organisation eine Vertrauensanker-Widerrufsmeldung für die Blockkette veröffentlichen und dadurch den zuvor übergebenen Block, der den Vertrauensanker enthält, entwerten.
  • Weiter können zusätzliche Erweiterungen der gegenwärtigen Techniken die TCG-Spezifikationen für Public Key Infrastructure (PKI) Zertifikate nutzen, um die Vertrauenszusicherungen der Plattform mit den Vorrichtungsqualitätszusicherungen zu verknüpfen, die von der Organisation (z.B. von der OCF-Organisation) verwaltet werden. Diese und andere technische Vorteile können innerhalb von OCF- und ähnlichen IoT-Netzwerkeinsätzen erreicht werden.
  • In einem Beispiel können die gegenwärtigen Techniken und Konfigurationen Aspekte traditioneller und stark eingeschränkter vertrauenswürdiger Umgebungen integrieren, um eine Speicherung einer Vertrauensankerrichtlinie zu unterstützen, wo ein Zugriff auf den Speicher davon abhängt, dass ein Zertifikatspfad-Validierungscode oder eine Logik in einer vertrauenswürdigen Umgebung sicher gestartet wurde. Zu solchen vertrauenswürdigen Umgebungen gehören unter anderem TCG Trusted Platform Module (TPM), Intel Secure Guard Extensions (SGX), Intel Management Engine (ME), Intel Virtualization Technology (VT-X), Intel Trusted Execution Technology (TXT), Intel Memory Controller, Intel 3D CrossPoint oder Optane Memory, Intel Memory Encryption Technology, Intel SMI Transfer Monitor (STM), ARM TrustZone oder andere Hardware-Sicherheitsmodule.
  • In einem Beispiel können die vorliegenden Techniken und Konfigurationen auch die Verwendung eines Netzwerk-Onboarding-Tools (wie es durch die OCF-Spezifikation definiert ist) ermöglichen, um einen Mechanismus der Vertrauensumgebung zu nutzen, um Vertrauensankerrichtlinien zu sichern.
  • Ebenfalls in einem Beispiel, können die gegenwärtigen Techniken und Konfigurationen es einer stark eingeschränkten Plattform ermöglichen, Netzwerk-Onboarding-Aufgaben im Namen eines Netzwerkeigentümers durchzuführen.
  • Ebenfalls in einem Beispiel, können die gegenwärtigen Techniken und Konfigurationen es ermöglichen, ein Geflecht („Mesh“) von vertrauenswürdigen Umgebungen (die Zertifikatspfad-Validierungscode/-logik enthalten) und sicherem Speicher (der eine Vertrauensankerrichtlinie enthält) konsistent zu versorgen. Die derzeitigen Techniken und Konfigurationen können auch die Wirkung vorsehen, jeder Maschen-Plattform zu erlauben, dieselbe Vertrauensankerrichtlinie anzuwenden.
  • In einem Beispiel ermöglichen es die gegenwärtigen Techniken und Konfigurationen ferner jedem Netzwerkknoten, der eine Vertrauensankerrichtlinie aufweist, unter Verwendung der Vertrauensankerrichtlinie zusammen mit anderen Richtlinien, die Kriterien für ein Onboarding und eine Erweiterung eines Netzwerks definieren, andere Nichtmitglied-Knoten an Bord zu nehmen. Diese und andere technische Vorteile, die in einer Reihe von IoT-Netzwerkeinsätzen genutzt werden können, werden in der folgenden Erörterung deutlich.
  • 1 veranschaulicht eine beispielhafte Domänentopologie für entsprechende IoT-Netzwerke, die über Links mit entsprechenden Gateways gekoppelt sind. Das IoT unterstützt Einsätze, bei denen eine große Anzahl von Computervorrichtungen untereinander und mit dem Internet verbunden sind, um auf sehr niedrigen Niveaus Funktionalität und Datenerfassung zu ermöglichen. So kann eine IoT-Vorrichtung in dem hier verwendeten Sinn eine halbautonome Vorrichtung beinhalten, die eine Funktion, wie z.B. Abtastung oder Steuerung und dergleichen, in der Kommunikation mit anderen IoT-Vorrichtungen und einem größeren Netzwerk, wie z.B. dem Internet, ausführt.
  • Oft sind IoT-Vorrichtungen hinsichtlich ihrer Speicher, Größe oder Funktionalität begrenzt, so dass größere Stückzahlen zu ähnlichen Kosten wie kleinere Stückzahlen größerer Vorrichtungen eingesetzt werden können. Allerdings kann eine IoT-Vorrichtung auch ein Smartphone, ein Laptop, ein Tablet oder ein PC oder eine sonstige größere Vorrichtung sein. Darüber hinaus kann eine IoT-Vorrichtung eine virtuelle Vorrichtung sein, z.B. eine Anwendung auf einem Smartphone oder einer anderen Computervorrichtung. IoT-Vorrichtungen können IoT-Gateways beinhalten, die zur Kopplung von IoT-Vorrichtungen mit anderen IoT-Vorrichtungen und mit Cloud-Anwendungen, zur Datenspeicherung, Prozesssteuerung und dergleichen verwendet werden.
  • Netzwerke von IoT-Vorrichtungen können kommerzielle und Hausautomatisierungsvorrichtungen umfassen, wie z.B. Wasserverteilungssysteme, Stromverteilungssysteme, Rohrleitungssteuerungssysteme, Anlagensteuerungssysteme, Lichtschalter, Thermostate, Schlösser, Kameras, Alarme, Bewegungssensoren und dergleichen. Auf die IoT-Vorrichtungen kann über entfernte Computer, Server und andere Systeme zugegriffen werden, beispielsweise um Systeme zu steuern oder auf Daten zuzugreifen.
  • Das zukünftige Wachstum des Internets und ähnlicher Netzwerke kann eine sehr große Anzahl von IoT-Vorrichtungen einbeziehen. Dementsprechend werden im Zusammenhang mit den hier erörterten Techniken eine Reihe von Innovationen für solche zukünftigen Netzwerke die Notwendigkeit ansprechen, dass all diese Schichten ungehindert wachsen, dass verbundene Ressourcen entdeckt und zugänglich gemacht werden und dass die Möglichkeit unterstützt wird, verbundene Ressourcen zu verbergen und abzuschotten. Es kann eine beliebige Anzahl von Netzwerkprotokollen und Kommunikationsstandards verwendet werden, wobei jedes Protokoll und jeder Standard auf bestimmte Ziele ausgerichtet ist. Darüber hinaus sind die Protokolle Teil der Struktur, die für den Menschen zugängliche Dienste unterstützt, die unabhängig von Ort, Zeit und Raum funktionieren. Zu den Neuerungen gehören die Bereitstellung von Diensten und die damit verbundene Infrastruktur, wie Hardware und Software, Sicherheitsverbesserungen und die Versorgung von Diensten auf der Grundlage von QoS-Bedingungen (Quality of Service), die in Vereinbarungen über die Dienstgüte und die Bereitstellung von Diensten spezifiziert sind. Es ist klar, dass die Verwendung von IoT-Vorrichtungen und Netzwerken, wie sie in 1 und 2 eingeführt wurden, eine Reihe neuer Herausforderungen in einem heterogenen Netzwerk von Konnektivität darstellt, das eine Kombination aus drahtgebundenen und drahtlosen Technologien umfasst.
  • 1 veranschaulicht in einer vereinfachten Zeichnung insbesondere eine Domänentopologie, die für eine Reihe von IoT-Netzwerken verwendet werden kann, die IoT-Vorrichtungen 104 aufweisen, wobei die IoT-Netzwerke 156, 158, 160, 162 über Backbone-Links 102 mit den entsprechenden Gateways 154 verbunden sind. Beispielsweise können mehrere IoT-Vorrichtungen 104 mit einem Gateway 154 und untereinander über das Gateway 154 kommunizieren. Zur Vereinfachung der Zeichnung ist nicht jede IoT-Vorrichtung 104 oder Kommunikationsverbindung (z.B. Link 116, 122, 128 oder 132) beschriftet. Die Backbone-Links 102 können eine beliebige Anzahl von drahtgebundenen oder drahtlosen Technologien, einschließlich optischer Netzwerke, umfassen und können Teil eines lokalen Netzwerks (Local Area Network, LAN), eines Weitverkehrsnetzes (Wide Area Network WAN) oder des Internets sein. Zusätzlich vereinfachen solche Kommunikationsverbindungen optische Signalpfade zwischen den beiden IoT-Vorrichtungen 104 und den Gateways 154, beispielsweise die Verwendung von MUXing/DeMUXing-Komponenten, die eine Verbindung der verschiedenen Vorrichtungen untereinander erleichtern.
  • Die Netzwerktopologie kann eine beliebige Anzahl von IoT-Netzwerkarten umfassen, wie z.B. ein vermaschtes Netzwerk, das mit dem Netzwerk 156 versehen ist, das mit geringer Leistung arbeitende Bluetooth (Bluetooth Low Energy, BLE)-Links 122 verwendet. Andere Arten von IoT-Netzwerken, die vorhanden sein können, umfassen ein drahtloses lokales Netzwerk (Wireless Local Area Network, WLAN) 158, das zur Kommunikation mit IoT-Vorrichtungen 104 über IEEE 802.11 (Wi-Fi®) Links 128 verwendet wird, ein zellulares Netzwerk 160, das zur Kommunikation mit IoT-Vorrichtungen 104 über ein zellulares LTE/LTE-A (4G)- oder 5G-Netzwerk verwendet wird, und ein mit niedriger Leistung arbeitendes und eine große Fläche abdeckendes (Low Power Wide-Area, LPWA)-Netzwerk 162, z.B. ein LPWA-Netzwerk, das mit der von der LoRa-Allianz veröffentlichten LoRaWan-Spezifikation kompatibel ist, oder ein IPv6 über Low-Power-Wide-Area-Netzwerke (LPWAN) Netzwerk, das mit einer von der Internet Engineering Task Force (IETF) veröffentlichten Spezifikation kompatibel ist. Darüber hinaus können die jeweiligen IoT-Netzwerke mit einem externen Netzwerkanbieter (z.B. einem Tier-2- oder Tier-3-Provider) über eine beliebige Anzahl von Kommunikationsverbindungen kommunizieren, wie z.B. eine zellulare LTE-Verbindung, eine LPWA-Verbindung oder eine Verbindung, die auf dem IEEE 802.15.4-Standard basiert, wie z.B. Zigbee®. Die jeweiligen IoT-Netzwerke können auch unter Verwendung einer Reihe von Netzwerk- und Internet-Anwendungsprotokollen wie z.B. Constrained Application Protocol (CoAP) betrieben werden. Die jeweiligen IoT-Netzwerke können auch mit Koordinatorvorrichtungen integriert werden, die eine Kette von Verbindungen bilden, die einen Cluster-Baum von verbundenen Vorrichtungen und Netzwerken bilden.
  • Jedes dieser IoT-Netzwerke kann Möglichkeiten für neue technische Merkmale bieten, wie sie hier beschrieben sind. Die verbesserten Technologien und Netzwerke können ein exponentielles Wachstum von Vorrichtungen und Netzwerken ermöglichen, einschließlich der Nutzung von IoT-Netzwerken in „Fog“-Vorrichtungen oder -Systemen. Mit der zunehmenden Verwendung solcher verbesserten Technologien können die IoT-Netzwerke für eine Selbstverwaltung, funktionelle Entwicklung und Zusammenarbeit entwickelt werden, ohne dass ein direktes menschliches Eingreifen erforderlich ist. Die verbesserten Technologien können es sogar ermöglichen, dass IoT-Netzwerke ohne zentral gesteuerte Systeme arbeiten. Dementsprechend können die hier beschriebenen verbesserten Technologien zur Automatisierung und Erweiterung von Netzwerkmanagement- und Betriebsfunktionen weit über die derzeitigen Implementierungen hinaus eingesetzt werden.
  • In einem Beispiel kann die Kommunikation zwischen IoT-Vorrichtungen 104, z.B. über die Backbone-Links 102, durch ein dezentrales System zur Authentifizierung, Autorisierung und Abrechnung (AAA) geschützt werden. In einem dezentralisierten AAA-System können verteilte Zahlungs-, Kredit-, Prüfungs-, Autorisierungs- und Authentifizierungssysteme über eine miteinander verbundene heterogene Netzwerkinfrastruktur implementiert werden. Dies ermöglicht es Systemen und Netzwerken, sich in Richtung eines autonomen Betriebs zu entwickeln. Bei dieser Art von autonomen Operationen können Maschinen sogar Verträge für Personalressourcen abschließen und Partnerschaften mit anderen Maschinennetzwerken aushandeln. Dies kann das Erreichen gemeinsamer Ziele und einer ausgewogene Bereitstellung von Diensten gegenüber skizzierten, geplanten Service Level Agreements (Vereinbarungen auf Dienstebene) ermöglichen sowie Lösungen für Ablesung, Messungen, Rückverfolgbarkeit und Nachverfolgung erzielen. Die Schaffung neuer Lieferkettenstrukturen und -verfahren kann es ermöglichen, eine Vielzahl von Dienstleistungen ohne menschliche Beteiligung zu schaffen, hinsichtlich ihres Wertes zu durchsuchen und kollabieren zu lassen.
  • Solche IoT-Netzwerke können durch die Integration von Sensortechnologien, wie z.B. Ton, Licht, elektronischer Verkehrs-, Gesichts- und Mustererkennung, Geruch oder Vibration, in die autonomen Organisationen unter den IoT-Vorrichtungen noch weiter verbessert werden. Die Integration von Sensorsystemen kann eine systematische und autonome Kommunikation und Koordination einer Dienstbereitstellung im Hinblick auf vertragliche Dienstziele, Orchestrierung und QoS-basiertes Schwärmen und eine Fusion von Ressourcen ermöglichen. Zu einzelnen Beispielen für netzwerkbasierte Ressourcenverarbeitung gehört Folgendes.
  • Das Maschennetzwerk 156 kann beispielsweise durch Systeme verfeinert werden, die Transformationen von Inline-Daten-zu-Informationen durchführen. Beispielsweise können sich selbst bildende Ketten von Verarbeitungsressourcen, die ein Multi-Link-Netzwerk umfassen, die Transformation von Rohdaten in Informationen auf effiziente Weise verteilen, und die Fähigkeit zur Unterscheidung zwischen Anlagen und Ressourcen und der damit verbundenen Verwaltung jeder einzelnen Ressource. Darüber hinaus können die geeigneten Komponenten von infrastruktur- und ressourcenbasierten Vertrauens- und Dienstindizes eingefügt werden, um die Datenintegrität, -qualität und - sicherung zu verbessern und eine Metrik des Datenvertrauens zu liefern.
  • Das WLAN-Netzwerk 158 kann beispielsweise Systeme verwenden, die eine Standardkonvertierung durchführen, um eine Multi-Standard-Konnektivität zu ermöglichen, so dass IoT-Vorrichtungen 104, die verschiedene Protokolle verwenden, miteinander kommunizieren können. Weitere Systeme können eine nahtlose Interkonnektivität über eine Multistandard-Infrastruktur bieten, die sichtbare Internet-Ressourcen und versteckte Internet-Ressourcen umfasst.
  • Die Kommunikation in dem zellularen Netzwerk 160 kann zum Beispiel durch Systeme verbessert werden, die Daten auslagern, die Kommunikation auf entferntere Vorrichtungen ausdehnen oder beides. Das LPWA-Netzwerk 162 kann Systeme umfassen, die Verbindungen zwischen Nicht-Internet-Protokoll (IP) zu IP, Adressierung und Routing durchführen. Weiter kann jedes der IoT-Vorrichtungen 104 den geeigneten Transceiver für eine Weitbereichskommunikation mit dieser Vorrichtung enthalten. Ferner kann jede IoT-Vorrichtung 104 andere Transceiver zur Kommunikation unter Verwendung zusätzlicher Protokolle und Frequenzen enthalten. Dies wird im Hinblick auf die Kommunikationsumgebung und -hardware einer IoT-Verarbeitungsvorrichtung weiter erörtert, die in 10 und 11 dargestellt ist.
  • In noch weiteren Beispielen können Aspekte einer Netzwerkvirtualisierung und eines virtualisierten/softwarebasierten Funktionsmanagements, einschließlich der softwaredefinierten Vernetzung (Software Defined Networking, SDN), mit den Netzwerken 158, 160, 162 oder anderen Einheiten implementiert werden. Beispielsweise kann das SDN ein softwarebasiertes programmierbares Netzwerk vorsehen, das die Steuerungsebene von der Datenebene trennt, um das Netzwerk und die Netzwerkfunktionen flexibler, wendiger und skalierbar und weniger abhängig von einer Netzwerkausrüstung, Anbietern und Dienstanbietern zu machen. Andere Anwendungsfälle von SDN-Funktionen können dynamische Netzwerkkonfigurationen, Überwachung und die Abstraktion von Netzwerkfunktionen in virtualisierten und dynamischen Systemen, mit Blick auf Redundanz, Steuerung und verbesserte Leistung umfassen.
  • Schließlich können Cluster von IoT-Vorrichtungen ausgerüstet werden, um sowohl mit anderen IoT-Vorrichtungen als auch mit einem Cloud-Netzwerk kommunizieren zu können. Hierdurch kann den IoT-Vorrichtungen ermöglicht werden, ein Ad-hoc-Netzwerk zwischen den Vorrichtungen zu bilden, so dass sie in der Lage sind, als eine einzige Vorrichtung zu arbeiten, die als Fog-Vorrichtung, Fog-Plattform oder Fog-Netzwerk bezeichnet werden kann. Diese Konfiguration wird weiter unten mit Bezug auf 2 erörtert.
  • 2 zeigt ein Cloud-Computernetzwerk in Kommunikation mit einem Maschennetzwerk von IoT-Vorrichtungen (Vorrichtungen 202), die in einem vernetzten Szenario als Fog-Plattform arbeiten. Das Maschennetzwerk von IoT-Vorrichtungen kann als Fog-Netzwerk 220 bezeichnet werden, das aus einem Netzwerk von Vorrichtungen an dem Rand der Cloud 200 errichtet ist. Zur Vereinfachung des Diagramms ist nicht jede IoT-Vorrichtung 202 beschriftet.
  • Das Fog-Netzwerk 220 kann als ein massiv vernetztes Netzwerk betrachtet werden, in dem eine Anzahl von IoT-Vorrichtungen 202, z.B. über Funkverbindungen 222, miteinander kommunizieren. Das Fog-Netzwerk 220 kann eine horizontale, physische oder virtuelle Ressourcenplattform errichten, die als zwischen IoT-Rand-Vorrichtungen und Cloud- oder Datenzentren angesiedelt betrachtet werden kann. Ein Fog-Netzwerk kann in einigen Beispielen vertikal isolierte, latenzempfindliche Anwendungen durch geschichtete, verbündete oder verteilte Rechen-, Speicher- und Netzwerkkonnektivitätsoperationen unterstützen. Ein Fog-Netzwerk kann jedoch auch zur Verteilung von Ressourcen und Diensten an dem Rand und zwischen dem Rand und der Cloud verwendet werden. Daher sind die Verweise in diesem Dokument auf den „Edge (Rand)“, den „Fog (Nebel)“ und die „Cloud (Wolke)“ nicht notwendigerweise diskret oder ausschließlich voneinander abhängig.
  • Als Beispiel kann das Fog-Netzwerk 220 durch eine Interconnect-Spezifikation erleichtert werden, die von der Open Connectivity Foundation™ (OCF) veröffentlicht ist. Dieser Standard ermöglicht es Vorrichtungen, sich gegenseitig zu entdecken und die Kommunikation für Interconnects (Verbindungen) zu errichten. Es können auch andere Verbindungsprotokolle verwendet werden, wie z.B. unter anderem das optimierte Link State Routing (OLSR)-Protokoll, das bessere Konzept für das Routing-Protokoll für mobilen Ad-hoc-Netzwerkbetrieb (Better Approach To Mobile Ad-hoc Networking B.A.T.M.A.N.) oder das OMA Lightweight M2M (LWM2M)-Protokoll.
  • In diesem Beispiel werden drei Arten von IoT-Vorrichtungen 202 gezeigt, Gateways 204, Datenaggregatoren 226 und Sensoren 228, wobei beliebige Kombinationen von IoT-Vorrichtungen 202 und Funktionalität verwendet werden können. Die Gateways 204 können Rand-Vorrichtungen sein, die die Kommunikation zwischen der Cloud 200 und dem Fog-Netzwerk 220 vorsehen und auch die Backend-Verarbeitungsfunktion für die von den Sensoren 228 erhaltenen Daten, wie Bewegungsdaten, Durchflussdaten, Temperaturdaten und dergleichen, vorsehen. Die Datenaggregatoren 226 können Daten von einer beliebigen Anzahl der Sensoren 228 sammeln und die Backend-Verarbeitungsfunktion für die Analyse ausführen. Die Ergebnisse, Rohdaten oder beides können über die Gateways 204 an die Cloud 200 weitergeleitet werden. Die Sensoren 228 können z.B. vollständige IoT-Vorrichtungen 202 sein, die sowohl Daten sammeln als auch die Daten verarbeiten können. In einigen Fällen können die Sensoren 228 in ihrer Funktionalität stärker eingeschränkt sein, z.B. beim Sammeln der Daten und beim Verarbeiten der Daten durch die Datenaggregatoren 226 oder die Gateways 204.
  • Die Kommunikation von jeder IoT-Vorrichtung 202 kann auf einem bequemen Weg (z.B. einem bequemsten Weg) zwischen jedem der IoT-Vorrichtungen 202 weitergeleitet werden, um die Gateways 204 zu erreichen. In diesen Netzwerken sieht die Anzahl der Verbindungen eine erhebliche Redundanz vor, so dass die Kommunikation auch bei Ausfall einer Anzahl von IoT-Vorrichtungen 202 aufrechterhalten werden kann. Darüber hinaus kann die Verwendung eines Maschennetzwerks die Verwendung von IoT-Vorrichtungen 202 ermöglichen, die eine sehr geringe Leistung haben oder sich in einer Entfernung von der Infrastruktur befinden, da die Reichweite für eine Verbindung mit einer anderen IoT-Vorrichtung 202 wesentlich geringer sein kann als die Reichweite für eine Verbindung mit den Gateways 204.
  • Das von diesen IoT-Vorrichtungen 202 vorgesehene Fog-Netzwerk 220 kann Vorrichtungen in der Cloud 200, wie z.B. einem Server 206, als einzelne Vorrichtung präsentiert werden, die sich an dem Rand der Cloud 200 befindet, z.B. ein Fog-Netzwerk, das als eine Vorrichtung oder Plattform arbeitet. In diesem Beispiel können die von der Fog-Plattform kommenden Warnungen gesendet werden, ohne dass sie als von einer bestimmten IoT-Vorrichtung 202 innerhalb des Fog-Netzwerks 220 kommend identifiziert werden. Auf diese Weise kann das Fog-Netzwerk 220 als eine verteilte Plattform betrachtet werden, die Rechen- und Speicherressourcen für eine Durchführung von Verarbeitungs- oder datenintensiven Aufgaben wie Datenanalyse, Datenaggregation und maschinelles Lernen und dergleichen vorsieht.
  • In einigen Beispielen können die IoT-Vorrichtungen 202 mit einem imperativen Programmierstil konfiguriert werden, wobei jede IoT-Vorrichtung 202 beispielsweise eine bestimmte Funktion und bestimmte Kommunikationspartner hat. Die IoT-Vorrichtungen 202, die die Fog-Vorrichtung bilden, können allerdings auch in einem deklarativen Programmierstil konfiguriert werden, so dass die IoT-Vorrichtungen 202 ihre Operationen und Kommunikation neu konfigurieren können, beispielsweise um die erforderlichen Ressourcen als Reaktion auf Bedingungen, Anfragen und Vorrichtungsausfälle zu bestimmen. Beispielsweise kann eine Abfrage eines Benutzers, der sich auf einem Server 206 befindet, über die Operationen einer Teilsatz von Vorrichtungen, die von den IoT-Vorrichtungen 202 überwacht werden, dazu führen, dass die Vorrichtung des Fog-Netzwerks 220 die IoT-Vorrichtungen 202, wie z.B. bestimmte Sensoren 228, die zur Beantwortung der Abfrage erforderlich sind, auswählt. Die Daten von diesen Sensoren 228 können dann von einer beliebigen Kombination der Sensoren 228, Datenaggregatoren 226 oder Gateways 204 aggregiert und analysiert werden, bevor sie von der Vorrichtung des Fog-Netzwerks 220 an den Server 206 zur Beantwortung der Abfrage weitergeleitet werden. In diesem Beispiel können die IoT-Vorrichtungen 202 in dem Fog-Netzwerk 220 die verwendeten Sensoren 228 auf der Grundlage der Abfrage, z.B. durch Hinzufügen von Daten von Durchfluss- oder Temperatursensoren, auswählen. Wenn einige der IoT-Vorrichtungen 202 nicht betriebsfähig sind, können andere IoT-Vorrichtungen 202 in dem Fog-Netzwerk 220 ferner analoge Daten liefern, sofern diese verfügbar sind.
  • In einer OCF-Architektur werden Entitäten in der realen physikalischen Welt (z.B. ein Temperatursensor) als Ressourcen dargestellt. Interaktionen mit Entitäten werden durch Ressourcendarstellungen implementiert, die Operationen verwenden, die sich an Representational State Transfer (REST) Architekturen halten, z.B. RESTful-Interaktionen. Als solche werden Entitäten als Ressourcen dargestellt, jede mit ihren eindeutigen Kennungen (Unique Identifiers, URIs) und unterstützenden Schnittstellen, die RESTful-Operationen auf ihren Ressourcen ermöglichen. Ein Client initiiert eine RESTful-Operation auf einem Server. Der Client ist der Initiator und der Server ist ein Responder. Jede Vorrichtung kann als Client arbeiten, um eine RESTful-Operation oder eine beliebige andere Vorrichtung, die als Server arbeitet, zu initiieren. Daher kann die Rolle einer Vorrichtung als Client oder Server in vielen Fällen austauschbar sein. Jede Vorrichtung, die eine Ressource freigibt, ist per Definition ein Server. Jede RESTful-Operation enthält alle Informationen, die zum Verständnis des Kontexts der Operation erforderlich sind, und wird durch eine Reihe von generischen Operationen (z.B. CREATE, RETRIEVE, UPDATE, DELETE und NOTIFY (CRUDN)) unterstützt.
  • Wie hierin erörtert, können die folgenden Techniken in Verbindung mit der Nutzung verschiedener OCF-Dienste, einschließlich DOTS (auch als DOXS, Device Owner Transfer Service bekannt), implementiert werden. In einem weiteren Beispiel können die folgenden Techniken in Verbindung mit einem Onboarding-Tool (OBT) implementiert werden. Im Zusammenhang mit einer OCF-Implementierung ist ein OBT eine logische Entität innerhalb eines speziellen IoT-Netzwerks, die ein Eigentumsrecht für eine bestimmte Vorrichtung begründet und dazu beiträgt, die Vorrichtung innerhalb dieses Netzwerks in einen betriebsfähigen Zustand zu bringen. Ein typisches OBT kann zum Beispiel Funktionen von DOXS, AMS (Access Management Service) und CMS (Credential Management Service) implementieren.
  • In einigen Implementierungen der OCF-Spezifikation kann eine Public Key Infrastructure (PKI) Komponente verwendet werden, die voraussetzt, dass OCF-Vorrichtungen und -Dienste ein Herstellerzertifikat von einer gemeinsamen Root-CA (z.B. einer CA, die der OCF oder einer anderen vertrauenswürdigen Organisation gehört oder von ihr betrieben wird) erhalten. Ein solcher PKI-Ansatz kann unerwünschte Sicherheits- und Betriebsprobleme für Hardwarelieferanten mit sich bringen. Er könnte beispielsweise dazu führen, dass der Hardwareanbieter oder Hersteller OCF-regelkonforme Produkte zurückrufen muss, wenn der Schlüssel der OCF-Stammzertifizierungsstelle gefährdet ist. Die folgenden Techniken und Konfigurationen sind im Zusammenhang mit einem OCF-IoT-Einsatz verwendbar, um Sicherheit im Rahmen dieses PKI-Ansatzes zu gewährleisten.
  • Mit den folgenden Techniken können Anbieter von OCF-Vorrichtungen in einem Szenario, in dem die OCF eine gemeinsame OCF-Root-CA-Infrastruktur für den Sicherheitsbetrieb errichtet, einen OCF-Vertrauensanker in die von ihnen hergestellten Plattformen einbetten und Herstellerzertifikate für eingebettete Herstellerschlüssel erhalten. Eines der Ziele des OCF-PKI-Ansatzes ist es, OCF-Regeleinhaltungserweiterungen in Zertifikate aufzunehmen. Damit kann sichergestellt werden, dass signierte Regeleinhaltungszusicherungen nicht ohne weiteres gefälscht werden können; solche Regeleinhaltungserweiterungen können auch durch Onboarding-Tools verifiziert werden und können standardisiert/interoperabel sein. Diese Ziele können unter Verwendung der derzeit beschriebenen Plattformkonfiguration aufrechterhalten werden.
  • Wie in der folgenden Erörterung verwendet, bezieht sich eine OCF-Vorrichtung auf eine logische Darstellung der von der OCF definierten Funktionalität; eine Plattform bezieht sich auf eine Umgebung, die zum Hosten (Verwalten) von OCF-Vorrichtungen verwendet wird. Auch wenn eine „Plattform“ durch aktuelle OCF-Spezifikationen möglicherweise nicht ausdrücklich oder vollständig definiert ist, bietet die folgende Verwendung einer vertrauenswürdigen Plattform und eines Sicherheitsprofils die Möglichkeit für eine Definition und Verifizierung zusätzlicher Sicherheit.
  • Einige der Sicherheitsprobleme bei aktuellen und vorgeschlagenen PKI-Implementierungen von OCF-Vorrichtungen (oder Einsätzen ähnlicher IoT-Vorrichtungen) beinhalten:
    • a) OCF-Vorrichtungen sind Software (keine vertrauenswürdige Hardware-Plattform). Zusicherungen zur OCF-Regeleinhaltung spezifizieren nicht die Plattformumgebung; und als Folge davon können weniger vertrauenswürdige Plattformen dieselbe OCF-Vorrichtungssoftware verwalten. Als Folge für die Sicherheit erscheinen weniger vertrauenswürdige OCF-Vorrichtungen als gleichermaßen vertrauenswürdig.
    • b) Mehrere OCF-Vorrichtungen können auf derselben Plattform verwaltet werden. Als Folge davon werden Onboarding-Tools eine Wiederverwendung des Herstellerschlüssels für mehrere Onboarding-Ereignisse beobachten. Die Verwendung desselben Herstellerschlüssels für mehrere Onboarding-Vorrichtungen ist eine Angriffssignatur. Als Folge für die Sicherheit hat ein Onboarding-Tool widersprüchliche (ausnutzbare) Voraussetzungen.
    • c) Eine Nicht-OCF-Funktionalität kann von Plattformen verwaltet werden, die OCF-Vorrichtungen verwalten, und ein Herstellungszertifikat muss sowohl für OCF- als auch für Nicht-OCF-Funktionen verwendet werden. Unterschiedliche Ökosysteme sollten sich auf die Vertrauensattribute der Plattform einigen. Als Folge für die Sicherheit kann eine falsch verstandene Vertrauenssemantik von einem irritierten Stellvertreter ausgenutzt werden.
  • Um diesen Sicherheitsbedenken zu begegnen, führen die derzeitigen Techniken und Konfigurationen ein Hosting von OCF-Vorrichtungen in einer interoperablen, vertrauenswürdigen Plattform ein. Als ein Beispiel definiert die Trusted Computing Group (TCG) Spezifikationen für interoperable vertrauenswürdige Plattformen in Form von: (a) TPM - mit Herstellungsschlüsseln, Einbettung, Speicherung, Verwendung (auch als „Beglaubigung“ bezeichnet) und Vertrauen; (b) Vertrauenswürdige Microcontroller-Einheiten (Trusted Microcontroller Units, MCUs) - Vertrauensmerkmale, die auf MCU-Umgebungen angewendet werden; (c) Beglaubigungsprotokolle - Nachweis der Vertrauenswürdigkeit gegenüber einem Netzwerk-Peer; (d) Bindung der vertrauenswürdigen Plattform an Software; und (e) Erweiterbare Zertifikatsprofile: (z.B. einen TPM-Berechtigungsnachweis (der auch als Endorsement-Key, EK bekannt ist) - Bindung des Herstellerschlüssels an das TPM oder die T-MCU, Plattform-Attributsberechtigungsnachweis - Bindung des TPM/der T-MCU an die Plattform oder Zertifikatserweiterungen, die Vertrauens- und Qualitätsattribute erfassen).
  • Die TCG-Spezifikationen werden von der Industrie weitgehend übernommen. Beispielsweise liefern große Computer-ODMs, OEMs, OSVs und ISVs TCG-regelkonforme Produkte und TCG-Berechtigungsnachweise, die von vielen bestehenden CAs ausgestellt werden. Mehrere Open-Source-Software-Implementierungen sind verfügbar. Mit den im Vorliegenden beschriebenen Konfigurationen kann ein OCF-Einsatz dafür eingerichtet sein, mit TCG-regelkonformen Plattformen zusammenzuarbeiten.
  • 3 veranschaulicht eine Konfiguration und den Betrieb von OCF-Vorrichtungen, die auf einer beispielhaften vertrauenswürdigen Plattform 330 verwaltet werden. In diesem Beispiel kann die Plattform 330 einen TCG-Plattform-Berechtigungsnachweis 334 enthalten (z.B. implementiert durch TCG-Funktionen wie TPM, T-MCU, in einer Platform Attribut Cert Instanz), mit Links zur Regeleinhaltungsdokumentation 342. Wie gezeigt, kann die Plattform 330 arbeiten, um die Gültigkeit verschiedener Zertifikate zu bestimmen und einem Onboarding-Tool 310 zu ermöglichen, unter Verwendung eines gültigen Vorrichtungszertifikats fortzufahren. In einem Beispiel kann für jede Instanz einer OCF-Vorrichtung (332) ein entsprechendes Plattform-Zertifikat 334 vorhanden sein, wobei der erste Plattform-Berechtigungsnachweis auf ein erstes OCF Device Doc (z.B. ein erstes Dokument 342) und ein zweiter Plattform-Berechtigungsnachweis auf ein zweites OCF Device Doc (z.B. ein zweites Dokument) verweisen kann. Beide Plattform-Zertifikate können auf dasselbe Endorsement-Key-Zertifikat 336 (EK-Zertifikat) verweisen.
  • Wie gezeigt, ist der TCG-Plattformberechtigungsnachweis 334 der Plattform 330 mit einer Reihe von Plattformmerkmalen, wie Identifikatoren, Konfigurationen, Datenwerten und Sicherheitszusicherungen, verknüpft. Diese Merkmale sind wiederum mit der Dokumentation 342 verknüpft, die von der Website 340 einer Organisation (z.B. einer OCF-Website) vorgesehen wird. Informationen wie Vorrichtungsanbieter, Vorrichtungstyp und Regeleinhaltungsstatus werden in einem signierten Dokument 344 verwaltet. Dieses signierte Dokument 344 ist von einer vertrauenswürdigen Organisation (z.B. OCF) unterzeichnet. Wie ebenfalls gezeigt, können Informationen wie Sicherheitszusicherungen in dem Regeleinhaltungsstatus des signierten Dokuments 344 vorgesehen werden; es können auch Informationen zur Plattformkonfiguration in dem signierten Dokument 344 enthalten sein.
  • Bezogen auf eine gemeinsame Wurzel-CA ist ein TCG-„Verifizierer“, der innerhalb der Plattform 330 arbeitet, nicht stark eingeschränkt. Vielmehr können die TCG-Merkmale (z.B. TPM, T-MCU) zur Bewertung von Plattform- und Endorsement-Key-Berechtigungsnachweisen, Vertrauenszusicherungen, Qualitätszusicherungen verwendet werden, selbst wenn Plattformeigentümer die Plattform aus anderen Gründen bereits verwalten. Außerdem ist die Liste der Vertrauensanker für TCG-CAs im Vergleich zu anderen Vertrauensattributen kurz.
  • In dieser Konfiguration ist das Onboarding-Tool 310 ebenfalls nicht „stark eingeschränkt“. Vielmehr implementiert das Onboarding-Tool 310 alle definierten Eigentümerübertragungsverfahren (Owner Transfer Methods, OTMs) 322 für die jeweiligen Vorrichtungen (z.B. wie in der OCF-Spezifikation definiert), führt eine Liste 314 der „im Eigentum befindlichen“ und vertrauenswürdigen OCF -Vorrichtungen 332 der Plattform 330, versorgt 324 neue Vorrichtungen mit lokalen Berechtigungsnachweisen (z.B. unter Verwendung einer lokalen CA 312) und ACLs, verwaltet viele Aspekte des Lebenszyklus von OCF-Vorrichtungen und kann sogar von mehreren Root-CAs zertifiziert werden.
  • Mit der Konfiguration von 3 ist ein Versorgen von Vertrauensankern für Einsätze von IoT-Vorrichtungen möglich, wie sie unter Verwendung des IETF Trust Anchor Management Protocol (RFC 5934) implementiert werden kann. Das Versorgen von Vertrauensankern hält von der OCF genehmigte Vertrauensanker auf dem neuesten Stand; die OCF-Spezifikation kann auch andere sinnvolle Vorgaben definieren. Zusätzlich können OCF-Vorrichtungen 332 mehrere Roots in einem sicheren Schreib-Lese-Speicher speichern. Plattformanbieter können solche Informationen einbetten, wenn sie dies wünschen.
  • Zusätzlich zu den in 3 dargestellten Vorgängen können verschiedene Betriebsabläufe verwendet werden, um die Konformität von Vorrichtungen, die Konformität der Plattform, ein vertrauenswürdiges Booten, ein vertrauenswürdiges/beglaubigtes Onboarding und den Betrieb von Vorrichtungen zu ermöglichen, wie in den folgenden Flussdiagrammen erörtert.
  • 4 zeigt ein Flussdiagramm eines beispielhaften Verfahrens für die Vorrichtungskonformität zur Verwendung von Vorrichtungen in einer vertrauenswürdigen Plattform. In dem Beispiel von 4 beschreibt dieser Vorgang insbesondere Schritte, denen ein Anbieter folgen muss, um „Qualitätszusicherungen“ für eine Vorrichtung erstellen zu lassen, die auf einer vertrauenswürdigen Plattform verwaltet wird. Ein Bewertungslabor kann Bewertungsergebnisse signieren und einen Signierschlüssel/Zertifikatspfad besitzen, der durch eine CA verwurzelt ist, die sich von jeder anderen CA, auf die diese Erfindung Bezug nehmen könnte, unterscheidet.
  • Das Testlabor zur Bewertung der Vorrichtungskonformität kann ein „Sicherheitsprofil“ identifizieren, mit dem die IoT-Vorrichtung konform ist, wenn die OCF-Vorrichtungssoftware (wie in 5 definiert und weiter unten erörtert) auf einer vertrauenswürdigen Plattform läuft.
  • In einem Beispiel kann ein Verfahren für die Konformität einer Vorrichtung (z.B. wie in 4 dargestellt) Folgendes umfassen:
  • Operation 410: IoT-Vorrichtungsdefinitionsdateien und Software werden auf eine vertrauenswürdige Plattform (z.B. eine von der TCG definierte Plattform) geladen.
  • Operation 420: Die IoT-Vorrichtung und die Plattform sind mit einer Konformitäts-Testeinrichtung und einer Testsuite verbunden, die die Konformität und Regeleinhaltung mit einer Validierungssuite bewertet. Eine solche Einrichtung und Testsuite wird als Bewertungslabor bezeichnet.
  • Operation 430: Das Bewertungslabor erstellt ein elektronisches Dokument (z.B. JSON, XML, HTML, ASN.1 und dergleichen), das Regeleinhaltungsergebnisse und Identifizierungsattribute für die Vorrichtung und die Plattform enthält. (Diese müssen nicht die Instanz, sondern vielmehr den Typ oder das Modell identifizieren).
  • Operation 440: Das Bewertungslabor signiert die Bewertungsergebnisse digital unter Verwendung einer digitalen Signatur und eines signierten Dokuments, wie z.B. einem Zertifikat (z.B. RFC5280), einem zugewiesenen Zertifikat (z.B. RFC3281), einem signierten Dokument (z.B. RFC8152, Object Security for Constrained RESTful Environments (OSCORE) Internet-Draft, RFC5652) oder einem Manifest.
  • Operation 450: Die Ergebnisse des Bewertungslabors werden veröffentlicht (z.B. auf einer Website veröffentlicht, in einem Zertifikat veröffentlicht und/oder einer öffentlichen Blockkette beigesteuert).
  • Operation 460: Der öffentliche Signierschlüssel des Bewertungslabors kann veröffentlicht (wie in Operation 450 durchgeführt) oder in einer Zertifikatskette gespeichert werden, die durch einen Vertrauensanker abgeschlossen wird.
  • 5 veranschaulicht in einem Flussdiagramm ein beispielhaftes Verfahren für die Plattformkonformität zur Verwendung einer vertrauenswürdigen Plattform. In dem Beispiel von 5 beschreibt dieser Vorgang insbesondere die (weitgehend von der TCG festgelegten) Operationen, denen ein Plattformanbieter folgt, um Vertrauen in einer Plattformkonfiguration herzustellen. Eine solche Plattformkonfiguration kann ein Trusted Platform Module (TPM) oder Trusted MCU (TMCU) umfassen, wobei das TPM/die TMCU einen herstellerseitig eingebetteten Schlüssel haben, der auch als „EK“ bekannt ist. Der TPM-/TMCU-Hersteller kann ein EK-Zertifikat/einen Zertifikatspfad erhalten, das/der von einer CA verwurzelt ist, die sich von jeder anderen CA unterscheidet. Das Plattform-Attributszertifikat (Platform Attribute Cert, PAC) kann von einem vertrauenswürdigen Plattformanbieter ausgestellt werden und kann einen Zertifikatspfad haben, der durch eine CA verwurzelt ist, die sich von jeder anderen CA unterscheidet.
  • In einem Beispiel kann ein Verfahren für eine Plattformkonformität (wie beispielsweise in 5 dargestellt) Folgendes umfassen:
    • Operation 510: Eine vertrauenswürdige Plattform (beispielsweise eine von der TCG definierte Plattform) wird von einem Plattformanbieter, einem Bewertungslabor (z.B. gemeinsame Kriterien) oder einer anderen Organisation oder Einrichtung zur Sicherheitsbewertung bewertet.
    • Operation 520: Der Plattformanbieter konstruiert einen Plattform-Attributsberechtigungsnachweis (z.B. TCG-PAC), der Bezüge auf die Plattformkonfiguration (z.B. URIs zu Hardwarekomponenten (z.B. Anbieter, Modell und Version), Softwarekomponenten (z.B. Anbieter, Modell, Version) und Bezüge auf die Plattformqualitätssicherung enthält (z.B. URIs zu Bewertungslabors, die öffentliche Dokumente/signierte Dokumente verwalten, die beschreiben, welche Software mittels welcher vertrauenswürdigen Plattformdefinition bewertet wurde).
    • Operation 530: Der Plattformanbieter signiert das PAC unter Verwendung eines Schlüsselpaares, wobei der öffentliche Schlüssel veröffentlicht wird (wie in früheren Operationen erörtert).
    • Operation 540: Der öffentliche Signierschlüssel des Bewertungslabors kann (wie in Operation 530 durchgeführt) veröffentlicht werden oder in einer Zertifikatskette enthalten sein, die durch einen Vertrauensanker abgeschlossen wird.
  • 6 zeigt ein Flussdiagramm einer beispielhaften vertrauenswürdigen Boot-Sequenz für Vorrichtungen in einer vertrauenswürdigen Plattform. Insbesondere zeigt das Flussdiagramm von 6 eine „Trusted Boot“-Sequenz (ein Industriebegriff aus dem Stand der Technik), die einen Bootstrap-Vorgang zeigt, der einen IoT-Vorrichtungslader 630 umfasst, der eine OCF-Vorrichtungssoftware 640 und Konfigurationsdateien laden kann. Dieser Vorgang kann die Software (für eine oder mehreren Plattformkonfigurationsregister (PCRs)) und Konfigurationsdateien messen, bevor er die Ausführung an den Software-Einstiegspunkt weiterleitet. Darüber hinaus kann dieser Vorgang für die PCRs für jede entsprechende Phase messen.
  • In einem Beispiel kann ein Verfahren für eine vertrauenswürdige Boot-Sequenz (z.B. wie in 6 dargestellt) einen iterativen Vorgang zum Starten eines IoT-Bootstrap-Laders, eines IoT-Plattformsystemsoftwareladers und eines IoT-Vorrichtungssoftwareladers sowie die Messung des Laders und des Software-Codes für entsprechende Plattformkonfigurationsregister (PCRs) umfassen. Wie gezeigt, kann die vertrauenswürdige Boot-Sequenz mit einem IoT-Firmware-(Bootstrap)-Lader 610 beginnen, der zum Laden (1) der IoT-Plattformfirmware und des Systemsoftware-Laders 660 verwendet wird. Darauf folgt ein Ausführungsfluss (2) zu dem IoT-Plattformsystemsoftwarelader 620, der zum Laden (3) der IoT-Plattformsystemsoftware und des Vorrichtungssoftware-Laders 650 verwendet wird. Danach folgt der Ausführungsfluss (4) zu dem IoT-Vorrichtungssoftware-Lader 630, der die IoT-Vorrichtungssoftware 640 lädt (5) und die Ausführung an den Einstiegspunkt dieser Software übergibt. Der Ausführungsfluss (6) setzt sich mit der IoT-Vorrichtungssoftware 640 fort.
  • Wie in dem Beispiel von 6 gezeigt, sind verschiedene Komponenten, die die vertrauenswürdige Plattform und die von ihr verwaltete IoT-Vorrichtung aufbauen, „aneinander gebunden“. Die Bindung wird hier in Form des vertrauenswürdigen Ladens der IoT-Vorrichtungssoftware 640 bekundet. In einigen eingeschränkten Umgebungen ist möglicherweise nur eine hybride Ausprägung vorhanden, die aus Firmware, Systemsoftware und Vorrichtungssoftware besteht. Dadurch wird die vertrauenswürdige Boot-Sequenz in wenige Operationen zusammengefasst, jedoch beinhaltet das PCR (bzw. enthalten die mehreren PCRs) (wie mit Bezug auf 7 weiter unten erörtert) immer noch die Messwerte, die für ein vertrauenswürdiges und beglaubigtes Onboarding erforderlich sind.
  • 7 veranschaulicht ein Flussdiagramm eines beispielhaften Verfahrens für ein vertrauenswürdiges oder beglaubigtes Onboarding einer Vorrichtung für Vorrichtungen in einer vertrauenswürdigen Plattform. Insbesondere zeigt das in 7 dargestellte Verfahren die OBT-Onboardingschritte, die eine neue Vorrichtung betreffen, die hofft, (an Bord) aufgenommen zu werden und das Recht zu erhalten, mit einem oder mehreren der Sicherheitsprofile zu arbeiten, die durch einen Vorrichtungskonformitätsvorgang (wie z.B. in 4 dargestellt und oben erörtert) als gültig zugesichert wurden.
  • In einem Beispiel kann ein Verfahren für ein vertrauenswürdiges oder beglaubigtes Onboarding einer Vorrichtung (wie es beispielsweise in 7 dargestellt ist) umfassen:
    • Operation 705: Eine vertrauenswürdige Plattform führt einen sicheren oder vertrauenswürdigen Bootvorgang durch, der die Plattformfirmware, die Systemsoftware und die IoT-Vorrichtungssoftware während des Ladens misst.
    • Operation 710: Ein IoT-Netzwerk-Onboarding-Tool (OBT) stellt eine Verbindung zu der IoT-Plattform her und fordert das Beglaubigungszeugnis an.
    • Operation 715: Die vertrauenswürdige Plattform signiert die Boot-/Lademessungen in PCRs unter Verwendung eines in der Plattform eingebetteten Herstellungsschlüssels (z.B. TPM EK oder AIK) und des PAC-Zertifikats.
    • Operation 720: Das OBT verifiziert die PCRs und PACs, das Zertifikatspfade zu einen Vertrauensanker enthält, der von dem Netzwerkeigentümer vorgesehen wird. Dies schließt eine Verifizierung des Herstellungs(manufacturing, mfg)-Schlüssels ein (der einem separaten Zertifikatspfad folgen kann).
    • Operation 725: Das OBT erhält signierte Dokumente, die über URI-Links in dem PAC verfügbar sind, und verifiziert die Dokumentsignatur und -kette (die einem separaten Zertifikatspfad folgen kann).
    • Operation 730: Das OBT erhält signierte Dokumente, die über URI-Links in dem PAC verfügbar sind, und verifiziert die Dokumentsignatur und -kette (die einem separaten Zertifikatspfad folgen kann).
    • Operation 735: Das OBT erhält die Vertrauensanker des Netzwerkeigentümers, der jede Zertifikatskette abschließt (der Eigentümer führt dies durch, indem er aus einer der öffentlichen Quellen liest und die Legitimität von öffentlichen Schlüsseln bewertet).
    • Operation 740: Das OBT verifiziert die IoT-Vorrichtungensicherheitsprofile, die das IoT-Vorrichtungsbewertungslabor den Bewertungsergebnissen zugewiesen hat.
    • Operation 745: Das OBT wählt ein Sicherheitsprofil aus den Profilen aus, die von der Vorrichtung unterstützt werden, und stellt (konfiguriert) die Vorrichtung so ein, dass sie mit dem von dem OBT ausgewählten Profil arbeitet.
    • Operation 750: Das OBT stellt einen lokalen Berechtigungsnachweis oder eine Rolle aus, der bzw. die die Vorrichtung dazu autorisiert, gemäß einem oder mehreren der unterstützten Sicherheitsprofile zu arbeiten.
    • Operation 755: Das OBT aktualisiert eine Vorrichtungsressource und teilt ihr mit, auf welches Sicherheitsprofil beim Hochfahren der Vorrichtung umzustellen ist.
    • Operation 760: Das OBT oder die Vorrichtung schließt die Verbindung.
  • 8 zeigt ein Flussdiagramm mit Beispielen für Operationen von Vorrichtung-zu-Vorrichtung für Vorrichtungen in einer vertrauenswürdigen Plattform. Insbesondere zeigt das in 8 dargestellte Verfahren ein Szenario, in dem ein IoT-Client Zugriff auf eine von einem IoT-Server verwaltete Ressource anfordert, wobei auf die Ressource nur dann zugegriffen werden kann, wenn der Server mit einem bestimmten Sicherheitsprofil arbeitet.
  • In diesem Szenario liefert der Client einen (von dem OBT oder der lokalen CA ausgestellten) Berechtigungsnachweis, der den Client dafür autorisiert, mit einem speziellen Sicherheitsprofil zu arbeiten. Der Server versucht, auf das erwartete Sicherheitsprofil umzustellen und versucht, die Anforderung zu erfüllen. Das lokale OBT/die CA kann lokale Zertifikate oder Rollenzertifikate ausstellen, wobei der Zertifikatspfad durch eine CA abgeschlossen werden kann, die von keinem der anderen Diagramme zum Abschließen des Pfades verwendet wird. Der eine oder die mehreren OBT- und IoT-Server verwenden eine „Vertrauensankerrichtlinie“, die der Netzwerkeigentümer vorsieht und die verwendet wird, um die verschiedenen Zertifikatsketten, die während des Onboardings und des Vorrichtung-zu-Vorrichtung-Betriebs verwendet werden, abzuschließen.
  • In einem Beispiel kann das beispielhafte Verfahren für ein vertrauenswürdiges oder beglaubigtes Onboarding einer Vorrichtung folgende Folge von Schritten umfassen:
    • Operation 810: Der IoT-Client fordert einen Zugriff auf eine IoT-Server-Vorrichtung an; und liefert einen Berechtigungsnachweis, der ein Sicherheitsprofil zusichert.
    • Operation 820: Der IoT-Server verifiziert eine Autorisierung des Berechtigungsnachweis- und Sicherheitsprofils für den IoT-Client.
    • Operation 825: Es wird bestimmt, ob der Client mit dem angeforderten Profil betriebsfähig ist. Wenn er nicht bereits bei dem angeforderten Profil betriebsfähig ist, wird bei 830 eine Umstellung auf ein angefordertes Sicherheitsprofil durchgeführt. Diese Verbindung wird dann bei 840 vervollständigt.
    • Operation 845: Es wird bestimmt, ob die Ressource ACL, die als verfügbar anzeigt ist, bei dem aktuellen Sicherheitsprofil verfügbar ist. Wenn diese verfügbar ist, wird die Client-Anforderung bei Operation 850 verarbeitet.
  • 9 zeigt ein Flussdiagramm 900 eines beispielhaften Verfahrens für ein Onboarding einer betreffenden Vorrichtung zur Verwendung mit einem Sicherheitsprofil. Wie veranschaulicht, werden die Operationen des Flussdiagramms 900 aus der Perspektive einer Onboarding-Tool-Vorrichtung dargestellt, die arbeitet, um entsprechende neue (betreffende) Vorrichtungen in die Verwendung einer Vorrichtungsplattform (z.B. einer OCF-Plattform) an Bord aufzunehmen. Es ist klar, dass diese Operationen in einigen Beispielen auf mehrere Entitäten oder Akteure verteilt sein können, und dass solche Operationen unter Verwendung eines der in den Beispielen hierin erörterten alternativen Sicherheitsansätze modifiziert werden können.
  • Das Flussdiagramm 900 beginnt bei 910 mit Operationen, um (z.B. bei der Onboarding-Tool-Vorrichtung) eine Anforderung zu empfangen, ein Eigentümerübertragungsverfahren (z.B. als Teil von Onboarding-Operationen) einer betreffenden Vorrichtung, die einer Vorrichtungsplattform zugeordnet ist, durchzuführen. Darauf folgen bei 920 Operationen zum Erlangen von Beglaubigungszeugnissen, die der betreffenden Vorrichtung zugeordnet sind, und bei 930 Operationen zum Verifizieren eines Beglaubigungszeugnisses. In einem Beispiel wird das Beglaubigungszeugnis von der Vorrichtungsplattform vorgesehen und das Beglaubigungszeugnis wird durch ein Zertifikat signiert, das unter Verwendung eines herstellerseitig eingebetteten Schlüssels erzeugt wird. Ferner kann der herstellerseitig eingebettete Schlüssel von einer vertrauenswürdigen Hardwarekomponente der Vorrichtungsplattform vorgesehen werden, da die Vorrichtungsplattform eine vertrauenswürdige Hardware betreibt und relevante Vertrauensbeglaubigungsinformationen für den Betrieb und die Hardware enthält.
  • Das Flussdiagramm 900 fährt mit dem Betrieb bei 940 fort, um die betreffende Vorrichtung zu versorgen, z.B. unter der Verwendung lokaler Berechtigungsnachweise, die von einer lokalen Zertifizierungsstelle ausgestellt sind. In einem Beispiel wird die lokale Zertifizierungsstelle durch die Onboarding-Tool-Vorrichtung betrieben. Ebenfalls in einem Beispiel zeigen die lokalen Berechtigungsnachweise eine verifizierte Verwendung des Sicherheitsprofils an, das an herstellerseitig eingebettete Schlüssel gebunden ist. Das Flussdiagramm 900 fährt dann bei 950 mit Operationen fort, um die betreffende Vorrichtung auf ein Verwenden eines spezifizierten Sicherheitsprofils umzustellen. In einem Beispiel umfasst dies ein Aktualisieren einer Ressource der betreffenden Vorrichtung auf einen Wert, der dem Sicherheitsprofil zugeordnet ist, so dass die betreffende Vorrichtung bei Vervollständigung der Vorrichtungsversorgung auf ein Verwenden des Sicherheitsprofils umgestellt wird. In einem Beispiel kann dies auch beinhalten, dass die Onboarding-Tool-Vorrichtung eine Liste eigener und vertrauenswürdiger Vorrichtungen der Vorrichtungsplattform führt, z.B. die Liste aktualisiert, um die betreffende Vorrichtung aufzuweisen.
  • Das Flussdiagramm 900 schließt bei 960 mit Operationen, um die Vorrichtungsversorgung für die betreffende Vorrichtung zu vervollständigen, da die betreffende Vorrichtung konfiguriert ist, um unter Verwendung des Sicherheitsprofils zu arbeiten. Letztendlich können nachfolgende Operationen mit der betreffenden Vorrichtung (und in der Netzwerkplattform und jeder definierten Netzwerkdomäne) die Verifikation des Sicherheitsprofils umfassen.
  • In weiteren Beispielen sind die Onboarding-Tool-Vorrichtung, die Vorrichtungsplattform und/oder die betreffende Vorrichtung gemäß einer Spezifikation einer Familie von Standards der Open Connectivity Foundation (OCF) konfiguriert und/oder können danach betrieben werden. Darüber hinaus sind die vertrauenswürdige Hardwarekomponente, die Onboarding-Tool-Vorrichtung und andere Aspekte der Vorrichtungsplattform und/oder der betreffenden Vorrichtung gemäß einer Spezifikation einer Familie von Standards der Trusted Computing Group (TCG) konfiguriert und/oder können danach betrieben werden.
  • In einem weiteren Beispiel führt die betreffende Vorrichtung eine vertrauenswürdige Boot-Sequenz der Vorrichtungssoftware für den Betrieb auf der betreffenden Vorrichtung durch, und das Beglaubigungszeugnis umfasst die Verifizierung der vertrauenswürdigen Boot-Sequenz durch die Vorrichtungsplattform. Ferner wird der herstellerseitig eingebettete Schlüssel in weiteren Beispielen einem Vertrauensanker zugeordnet, so dass der Vertrauensanker unter Verwendung eines Vertrauensankerverwaltungsprotokolls verwaltet wird. Weiter wird der herstellerseitig eingebettete Schlüssel in weiteren Beispielen mit einer Zertifikatskette verknüpft, und die Zertifikatskette wird durch einen Vertrauensanker abgeschlossen, so dass das Beglaubigungszeugnis den Vertrauensanker aufweist. Der herstellerseitig eingebettete Schlüssel wird in weiteren Beispielen einem Plattform-Attributsberechtigungsnachweis der Vorrichtungsplattform zugeordnet, und der Plattform-Attributsberechtigungsnachweis enthält Plattforminformationen, die sich an einer Datenquelle einer dritten Partei öffentlich verifizieren lassen. In noch weiteren Beispielen kann das Verifizieren ein Abfragen einer Blockkette, um einen Vertrauensanker zu bestätigen, der mit dem herstellerseitig eingebetteten Schlüssel verknüpft ist, oder ein Abfragen der Blockkette, um nach einem Vertrauensanker-Widerruf für den Vertrauensanker zu suchen, der mit dem herstellerseitig eingebetteten Schlüssel verknüpft ist, umfassen. Die Identifizierung eines Vertrauensanker-Widerrufs kann dazu führen, dass die betreffende Vorrichtung ein anderes Sicherheitsprofil verwendet.
  • In speziellen Beispielen können die hier erörterten Techniken in einem OCF-Einsatz als Teil einer Sicherheitsprofil-Zuweisung (z.B. während des Onboardings der Vorrichtung) implementiert werden. OCF-Vorrichtungen können gemäß einem OCF-Sicherheitsprofil bewertet worden sein. Auf Bewertungsergebnisse könnte über ein Herstellerzertifikat, einen OCF-Webserver oder ein anderes öffentliches Depot zugegriffen werden. Der DOTS überprüft die Bewertungsergebnisse, um zu bestimmen, für welche OCF-Sicherheitsprofile die OCF-Vorrichtung zum Besitz autorisiert ist, und konfiguriert die Vorrichtung mit dem Teilsatz der bewerteten Sicherheitsprofile, die am besten für die beabsichtigte Netzwerksegmentierungsstrategie des Netzwerkeigentümers geeignet ist. Die folgenden Absätze legen zusätzliche Einzelheiten zu einer möglichen Implementierung mit Bezug auf OCF-Ressourcen und Ressourceneigenschaften dar.
  • In einem Beispiel können die hier erörterten Techniken in ein Sicherheitsprofil, das als „Sicherheitsprofil Blau“ bezeichnet wird, integriert werden. Das „Sicherheitsprofil Blau“ wird verwendet, wenn Hersteller Plattform-Zertifikate für Plattformen ausstellen, die herstellerseitig eingebettete Schlüssel enthalten. Die Kompatibilität mit interoperablen, vertrauenswürdigen Plattformen wird unter Verwendung der von der Trusted Computing Group (TCG) definierten Zertifikatserweiterungen erwartet. Netzwerkeigentümer bewerten von dem Hersteller gelieferte Zertifikate und zugewiesene Daten, um ein geeignetes OCF-Sicherheitsprofil zu bestimmen, das für OCF-Vorrichtungen bei einem Onboarding konfiguriert wird. OCF-Vorrichtungen können mehreren OCF-Sicherheitsprofilen genügen. Der Netzwerkeigentümer kann Einsätze von Netzwerken unter Verwendung des Sicherheitsprofils als Netzwerkpartitionierungskriterien konfigurieren.
  • Das OCF-„Sicherheitsprofil Blau“ erwartet ein Ökosystem, in dem sich die Plattformanbieter von den OCF-Vorrichtungsanbietern möglicherweise unterscheiden und in dem die Plattformanbieter vertrauenswürdige Plattformen implementieren können, die den Industriestandards entsprechen, die vertrauenswürdige Plattformen definieren. Das OCF-Sicherheitsprofil Blau spezifiziert Mechanismen zum Verknüpfen von Plattformen mit OCF-Vorrichtungen und zur Bezugnahme auf Qualitätssicherungskriterien, die durch OCF-Konformitätsoperationen erstellt werden. Der Netzwerkeigentümer wertet diese Daten aus, wenn eine OCF-Vorrichtung an Bord des Netzwerks aufgenommen wird. Auf der Grundlage dieser Bewertung bestimmt der Netzwerkeigentümer, welches Sicherheitsprofil während des Betriebs der OCF-Vorrichtung angewendet werden soll. Sämtliche OCF-Vorrichtungstypen können für die Bewertung mittels des OCF-Sicherheitsprofils Blau in Betracht kommen.
  • In einem Beispiel definiert OCF-Sicherheitsprofil Blau die folgenden Qualitätssicherungen: Die OCF-Konformitätskriterien sollen eine Herstellerbeglaubigung voraussetzen, dass die konforme OCF-Vorrichtung auf einer oder mehreren Plattformen verwaltet wurde, die Sicherheitsgarantien des OCF-Sicherheitsprofils Blau und Voraussetzungen an die Sicherheits- und Datenschutzfunktionalität erfüllten. In einem Beispiel definiert OCF-Sicherheitsprofil Blau die Qualitätssicherungsfunktionalität wie folgt: Die Ergebnisse der OCF-Konformitätstests und der Sicherheitsprofilregeleinhaltung werden auf einer OCF-Website veröffentlicht; und die Ergebnisse der OCF-Konformitätstests und der Sicherheitsprofilregeleinhaltung werden mit einem OCFeigenen Signierschlüssel digital signiert.
  • In einem Beispiel definiert OCF-Sicherheitsprofil Blau die folgenden Sicherheitszusicherungen: Plattformen, die kryptografische Diensteanbieterfunktionalität und sichere Speicherfunktionalität implementieren, müssen mit einem Minimum eines FIPS 140-2 Level 1 oder Common Criteria EAL Level 1 bewertet werden. Plattformen, die vertrauenswürdige Plattformfunktionalität implementieren, sollten mindestens mit einem Common Criteria EAL Level 1 bewertet werden.
  • In einem Beispiel definiert OCF-Sicherheitsprofil Blau die folgende Sicherheits- und Datenschutzfunktionalität: OCF-Vorrichtungen müssen kryptografische Algorithmen unter Verwendung eines kryptografischen Service Providers (Cryptographic Service Provider, CSP) verwenden. Eine CSP-Funktionalität muss kryptografische Algorithmen, Zufallszahlengenerierung und eine sichere Zeit umfassen. OCF-Vorrichtungen sollen einen sicheren Speicheranbieter für die Speicherung kryptografischer Schlüssel verwenden. OCF-Vorrichtungen sollen für übertragene Daten einen mit AES128 gleichwertigen Mindestschutz verwenden und sollen für die Funktionalität der kryptografischen Algorithmen einen von der Plattform verwalteten CSP verwenden. Die OCF-Vorrichtungen sollen für gespeicherte Daten einen mit AES128 gleichwertigen Mindestschutz verwenden und sollen eine von der Plattform verwaltete sichere Schlüsselspeicherungsfunktionalität verwenden. Die OCF-Vorrichtungen sollen die /oic/sec/cred-Ressource unter Verwendung des sicheren Speicheranbieters der Plattform schützen. OCF-Vorrichtungen sollen Vertrauensanker (auch als Richtlinie bekannt, die vertrauenswürdige CAs und angeheftete Zertifikate definiert) unter Verwendung einer sicheren Speicherfunktionalität der Plattform schützen. OCF-Onboarding (auch als DOTS bekannt) soll eine Zertifikatspfad-Validierung von Herstellerzertifikaten unter Verwendung der von dem Netzwerkeigentümer autorisierten Vertrauensanker abschließen. OCF-Onboarding (auch als DOTS bekannt) soll für alle Zertifikate in einem Hersteller-Zertifikatspfad den Zertifikatswiderrufstatus prüfen. OCF-Vorrichtungen sollen den Zertifikatswiderrufstatus für lokal ausgestellte Zertifikate prüfen.
  • In einem Beispiel definiert OCF-Sicherheitsprofil Blau die Sicherheits- und Datenschutzfunktionalität für eine Plattform. Eine oder mehrere Plattformen, die OCF-Vorrichtungen verwalten, sollten eine Plattform-Kennung gemäß den Spezifikationen des IEEE802.1AR oder des TCG Trusted Platform Module (TPM) implementieren. Plattformen, die OCF-Vorrichtungen verwalten, können eine von der TCG definierte Erweiterung der Plattformsicherheitszusicherung implementieren:
    • tBBSecurityAssertions ATTRIBUTE::= {
    • WITH SYNTAX TBBSecurityAssertions
    • ID tcg-at-tbbSecurityAssertions
    • }
  • Plattformen, die OCF-Vorrichtungen verwalten, können eine von der TCG definierte Erweiterung der Plattformkonfigurationszusicherung implementieren: platformConfiguration ATTRIBUTE::= {
    • WITH SYNTAX PlatformConfiguration
    • ID tcg-at-platformConfiguration-v1
    • }
  • In einem Beispiel setzt der OCF-Vorrichtungshersteller einen Hersteller-Standardwert für die Eigenschaften der supported_profiles und des active_profile einer /oic/sec/sp-Ressource auf „oic.sec.sp.unspecified“. Der Standardwert wird erneut bestätigt, wenn die Vorrichtung auf den RESET-Vorrichtungszustand umstellt. Die OCF-Vorrichtung ermöglicht eine Aktualisierung der /oic/sec/sp_update-Ressource ausschließlich dann, wenn sich die Vorrichtung in einem der folgenden Vorrichtungszustände befindet: RFOTM, RFPRO, SRESET.
  • In einem Beispiel aktualisiert der DOTS die Eigenschaft der supported_profiles der /oic/sec/sp_update-Ressource mit einem Teilsatz der OCF-Sicherheitsprofilwerte, die die Vorrichtung als Teil der OCF-Konformitätsprüfung erreicht hat. Der DOTS kann Konformitätsergebnisse durch eine Überprüfung der Herstellerzertifikate, die mit der OCF-Vorrichtung geliefert wurden, ermitteln, indem er Berechtigungsnachweise auswählt, die einen „credusage“-Eigenschaftswert „oic.sec.cred.mfgcert“ haben. Der DOTS kann ferner Konformitätsergebnisse durch Aufsuchen einer bekannten OCF-Website-URI ermitteln, die der Plattform, dem OCF-Vorrichtungstyp und den jeweiligen Plattform- und OCF-Vorrichtungsanbietern entspricht. Der DOTS kann auf der Grundlage einer lokalen Richtlinie einen Teilsatz von Sicherheitsprofilen (aus den durch OCF-Konformitätstests bewerteten Sätzen) auswählen.
  • In einem Beispiel aktualisiert der DOTS die current_profile-Eigenschaft der /oic/sec/sp_update-Ressource mit dem Wert, der die beabsichtigte Netzwerksegmentierungsstrategie des Netzwerkeigentümers am genauesten wiedergibt. Der CMS kann Rollenberechtigungsnachweise mit dem Wert des Sicherheitsprofils (z.B. „oic.sec.sp.blue“) ausgeben, um die Absicht des Netzwerkeigentümers anzuzeigen, das Netzwerk gemäß einem Sicherheitsprofil zu segmentieren. Der CMS ruft die supported_profiles-Eigenschaft der /oic/sec/sp-Ressource ab, um bei der Ausgabe von Rollenberechtigungsnachweisen Rollennamen auszuwählen, die mit den unterstützten Sicherheitsprofilen der Vorrichtung übereinstimmen. Wenn der CMS Rollenberechtigungsnachweise auf der Grundlage eines Sicherheitsprofils ausgibt, sollte der AMS Zugriffskontrolleinträge liefern, die die Rollenbezeichnung(en) enthalten.
  • Ebenfalls in einem Beispiel wird die oic.sec.sp-Ressource von der OCF-Vorrichtung verwendet, um zu zeigen, welche OCF-Sicherheitsprofile von dem Netzwerkeigentümer autorisiert sind und welches OCF-Sicherheitsprofil aktuell betriebsfähig ist. Eine Sicherheitsprofil-Ressourcendefinition kann über die Eigenschaften der oic.sec.sp-Ressource und der oic.sec.sp_update-Ressource vorgesehen werden. Beispielsweise kann eine Sicherheitsprofil-Ressourcendefinition durch die Werte der oic.sec.sp-Eigenschaften der /oic/sec/sp-Ressource (sowohl in dem R- als auch in dem RW-Zugriffsmodus) vorgesehen werden, die eine Reihe von unterstützten Sicherheitsprofilen und ein aktuell aktives Sicherheitsprofil anzeigt.
  • Es können auch Abänderungen an den vorhergehenden Plattformen, an der Sicherheits- und Datenschutzfunktionalität, an Zertifizierungsvoraussetzungen, Sicherheitsprofilen und Durchführungen in einer OCF-Spezifikation oder anderen IoT-Netzwerkeinsätzen erfolgen.
  • In verschiedenen Beispielen können die oben unter Bezugnahme auf 3 bis 9 beschriebenen Operationen und Funktionen durch eine IoT-Vorrichtungsmaschine in der beispielhaften Form eines elektronischen Verarbeitungssystems verkörpert werden, innerhalb dessen ein Satz oder eine Folge von Befehlen ausgeführt werden kann, um das elektronische Verarbeitungssystem zu veranlassen, eines der hier erörterten Verfahren gemäß einer beispielhaften Ausführungsform auszuführen. Die Maschine kann eine IoT-Vorrichtung oder ein IoT-Gateway sein, beispielsweise eine Maschine, die durch Aspekte eines Personalcomputers (PC), eines Tablet-PCs, eines persönlichen digitalen Assistenten (PDA), eines Mobiltelefons oder eines Smartphones verkörpert wird, oder eine Maschine, die in der Lage ist, (sequentielle oder andere) Befehle auszuführen, die Aktionen spezifizieren, die von dieser Maschine auszuführen sind.
  • Obwohl in den obigen Beispielen nur eine einzelne Maschine mit Bezug darauf dargestellt ist, ist unter eine solchen Maschine auch eine Sammlung von Maschinen zu verstehen, die einzeln oder gemeinsam einen Satz (oder mehrere Sätze) von Befehlen ausführen, um eines oder mehrere der hier erörterten Verfahren durchzuführen. Weiter sind unter diesen und ähnlichen Beispielen für ein prozessorbasiertes System beliebige Sätze von einer oder mehreren Maschinen zu verstehen, die von einem Prozessor, einem Satz von Prozessoren oder einer Verarbeitungsschaltung (z.B. eine Maschine in Form eines Computers, einer IoT-Verarbeitungsvorrichtung oder dergleichen) gesteuert oder betrieben werden, um einzeln oder gemeinsam Befehle auszuführen, um eines oder mehrerer der hierin erörterten Verfahren durchzuführen. Dementsprechend können in verschiedenen Beispielen anwendbare Mittel zur Verarbeitung (z.B. Verarbeitung, Steuerung, Erzeugung, Auswertung und dergleichen) durch solche Verarbeitungsschaltungen verkörpert sein.
  • 10 veranschaulicht in einer Zeichnung ein Cloud-Computernetzwerk oder eine Cloud 1000 in Kommunikation mit einer Reihe von Internet of Things (IoT) Vorrichtungen. Die Cloud 1000 kann das Internet repräsentieren oder ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetzwerk (WAN) sein, wie z.B. ein proprietäres Netzwerk für ein Unternehmen. Die IoT-Vorrichtungen können eine beliebige Anzahl verschiedener Vorrichtungstypen umfassen, die in verschiedenen Kombinationen gruppiert sind. So kann beispielsweise eine Verkehrssteuerungsgruppe 1006 IoT-Vorrichtungen entlang von Straßen einer Stadt umfassen. Diese IoT-Vorrichtungen können Ampeln, Verkehrsflussmonitore, Kameras, Wettersensoren und dergleichen umfassen. Die Verkehrssteuerungsgruppe 1006 oder andere Untergruppen können über drahtgebundene oder drahtlose Verbindungen 1008, wie z.B. LPWA-Links, optische Verbindungen und dergleichen, mit der Cloud 1000 kommunizieren. Darüber hinaus kann ein drahtgebundenes oder drahtloses Subnetzwerk 1012 eine Kommunikation der IoT-Vorrichtungen untereinander ermöglichen, z.B. über ein lokales Netzwerk, ein drahtloses lokales Netzwerk und dergleichen. Die IoT-Vorrichtungen können eine andere Vorrichtung, z.B. ein Gateway 1010 oder 1028, zur Kommunikation mit entfernten Standorten, wie der Cloud 1000, verwenden; die IoT-Vorrichtungen können auch einen oder mehrere Server 1030 verwenden, um die Kommunikation mit der Cloud 1000 oder dem Gateway 1010 zu erleichtern. Der eine oder die mehreren Server 1030 können beispielsweise als Zwischennetzwerkknoten arbeiten, um in einem lokalen Netzwerk eine lokale Rand-Cloud- oder Fog-Implementierung zu unterstützen. Darüber hinaus kann das dargestellte Gateway 1028 in einer Konfiguration von Cloud zu Gateway und zu vielen Rand-Vorrichtungen arbeiten, z.B. wenn die verschiedenen IoT-Vorrichtungen 1014, 1020, 1024 gegenüber einer Zuweisung und Nutzung von Ressourcen in der Cloud 1000 gebunden oder dynamisch sind.
  • Andere Beispielgruppen von IoT-Vorrichtungen können entfernte Wetterstationen 1014, lokale Informationsterminals 1016, Alarmsysteme 1018, Geldautomaten 1020, Alarmtafeln 1022 oder sich bewegende Fahrzeuge wie Notfallfahrzeuge 1024 oder sonstige Fahrzeuge 1026 und vieles mehr umfassen. Jede dieser IoT-Vorrichtungen kann mit anderen IoT-Vorrichtungen, mit Servern 1004, mit einer anderen IoT-Fog-Vorrichtung oder einem (nicht gezeigten, aber in 2 dargestellten) anderen IoT-Fog-System oder einer Kombination davon kommunizieren. Die Gruppen von IoT-Vorrichtungen können in verschiedenen privaten, kommerziellen und industriellen Umgebungen (einschließlich privater und öffentlicher Umgebungen) eingesetzt werden.
  • Wie aus 10 ersichtlich ist, kann eine große Anzahl von IoT-Vorrichtungen über die Cloud 1000 kommunizieren. Hierdurch ist es unterschiedlichen IoT-Vorrichtungen ermöglicht, Informationen autonom anzufordern oder anderen Vorrichtungen zur Verfügung zu stellen. Zum Beispiel kann eine Gruppe von IoT-Vorrichtungen (z.B. die Verkehrssteuerungsgruppe 1006) eine aktuelle Wettervorhersage von einer Gruppe von entfernten Wetterstationen 1014 anfordern, die die Vorhersage ohne menschliches Zutun liefern können. Ferner kann ein Notfallfahrzeug 1024 durch einen Geldautomaten 1020 gewarnt werden, dass ein Einbruch stattfindet. Während sich das Notfallfahrzeug 1024 auf den Geldautomaten 1020 zu bewegt, kann es auf die Verkehrssteuerungsgruppe 1006 zugreifen, um eine freie Zufahrt zu dem Ort anzufordern, z.B. indem Ampeln, auf Rot geschaltet werden, um den Kreuzungsverkehr an einer Kreuzung ausreichend rechtzeitig anzuhalten, so dass das Notfallfahrzeug 1024 ungehindert in die Kreuzung einfahren kann.
  • Cluster von IoT-Vorrichtungen, wie die entfernten Wetterstationen 1014 oder die Verkehrssteuerungsgruppe 1006, können so ausgestattet werden, dass sie sowohl mit anderen IoT-Vorrichtungen als auch mit der Cloud 1000 kommunizieren können. Dadurch können die IoT-Vorrichtungen ein Ad-hoc-Netzwerk zwischen den Vorrichtungen bilden, so dass sie in der Lage sind, als eine einzige Vorrichtung zu arbeiten, die als Fog-Vorrichtung oder -system bezeichnet werden kann (wie sie z.B. oben mit Bezug auf 2 beschrieben ist).
  • 11 zeigt in einem Blockdiagramm ein Beispiel von Komponenten, die in einer IoT-Vorrichtung 1150 zur Implementierung der hier beschriebenen Techniken vorhanden sein können. Die IoT-Vorrichtung 1150 kann beliebige Kombinationen der in dem Beispiel gezeigten oder in der obigen Offenbarung erwähnten Komponenten enthalten. Die Komponenten können als ICs, Teile davon, diskrete elektronische Vorrichtungen oder sonstige Module, Logik, Hardware, Software, Firmware oder eine Kombination davon, die in der IoT-Vorrichtung 1150 angepasst sind, oder als Komponenten, die anderweitig in einem Gehäuse eines größeren Systems eingebaut sind, implementiert werden. Zusätzlich soll das Blockdiagramm von 11 eine Ansicht der Komponenten der IoT-Baugruppe 1150 auf hohem Niveau darstellen. Einige der gezeigten Komponenten können jedoch weggelassen werden, es können zusätzliche Komponenten vorhanden sein, und es kann in anderen Ausführungsformen eine andere Anordnung der gezeigten Komponenten vorkommen.
  • Die IoT-Vorrichtung 1150 kann eine Verarbeitungsschaltung in Form eines Prozessors 1152 enthalten, wobei es sich um einen Mikroprozessor, einen Mehrkernprozessor, einen Multithread-Prozessor, einen Ultra-Niederspannungsprozessor, einen eingebetteten Prozessor oder andere bekannte Verarbeitungselemente handeln kann. Der Prozessor 1152 kann ein Teil eines Systems auf einem Chip (SoC) sein, in dem der Prozessor 1152 und andere Komponenten zu einer einzigen integrierten Schaltung oder einem einzigen Gehäuse, wie z.B. die Edison™ oder Galileo™ SoC-Boards von Intel, geformt werden. Als Beispiel kann der Prozessor 1152 einen auf Intel® Architektur Core™ basierenden Prozessor enthalten, wie z.B. einen Quark™, einen Atom™, einen i3-, einen i5-, einen i7- oder einen Prozessor der MCU-Klasse oder einen anderen Prozessor dieser Art, der von der Intel® Corporation, Santa Clara, Kalifornien, bezogen werden kann. Es können jedoch beliebig viele andere Prozessoren verwendet werden, wie z.B. erhältlich von Advanced Micro Devices, Inc. (AMD) in Sunnyvale, Kalifornien, ein MIPS-basiertes Design von MIPS Technologies, Inc. in Sunnyvale, Kalifornien, ein ARM-basiertes Design, das von ARM Holdings, Ltd. oder deren Kunden oder deren Lizenznehmer oder Adoptierenden lizenziert ist. Zu den Prozessoren können Einheiten wie ein A5-A10-Prozessor von Apple® Inc., ein Snapdragon™-Prozessor von Qualcomm® Technologies, Inc. oder ein OMAP™-Prozessor von Texas Instruments, Inc. gehören.
  • Der Prozessor 1152 kann über eine Verbindung 1156 (z.B. einen Bus) mit einem Systemspeicher 1154 kommunizieren. Es kann eine beliebige Anzahl von Speichervorrichtungen verwendet werden, um eine vorgegebene Größe eines Systemspeichers vorzusehen. Der Speicher kann beispielsweise ein Speicher mit wahlfreiem Zugriff (RAM) gemäß einem Design des Joint Electron Devices Engineering Council (JEDEC) sein, wie z.B. die DDR- oder Mobil-DDR-Standards (z.B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4). In verschiedenen Implementierungen können die einzelnen Speichervorrichtungen auf einer beliebigen Anzahl unterschiedlicher Gehäusetypen basieren, wie z.B. Single-Die-Paket (SDP), Dual-Die-Paket (DDP) oder Quad-Die-Paket (Q17P). Diese Vorrichtungen können in einigen Beispielen direkt auf eine Hauptplatine gelötet sein, um eine Lösung mit einem niedrigeren Profil vorzusehen, während in anderen Beispielen die Vorrichtungen als ein oder mehrere Speichermodule konfiguriert sind, die ihrerseits über einen vorgegebenen Steckverbinder an die Hauptplatine gekoppelt werden. Es kann eine beliebige Anzahl anderer Speicherimplementierungen verwendet werden, wie z.B. andere Arten von Speichermodulen, z.B. Dual-Inline-Speichermodule (DIMMs) verschiedener Varianten, einschließlich, aber nicht beschränkt auf microDIMMs oder MiniDIMMs.
  • Um eine dauerhafte Speicherung von Informationen wie Daten, Anwendungen, Betriebssystemen und dergleichen zu ermöglichen, kann ein Speicher 1158 auch über die Verbindung 1156 mit dem Prozessor 1152 gekoppelt werden. In einem Beispiel kann der Speicher 1158 über ein Solid State Disk Drive (SSDD) implementiert werden. Andere Vorrichtungen, die für den Speicher 1158 verwendet werden können, sind Flash-Speicherkarten, wie SD-Karten, microSD-Karten, xD-Bildkarten und dergleichen, sowie USB-Flash-Laufwerke. In Implementierungen geringer Leistung kann der Speicher 1158 auf einem On-Die-Speicher oder -registern basieren, die mit dem Prozessor 1152 verbunden sind. In einigen Beispielen kann der Speicher 1158 allerdings mittels einem Mikro-Festplattenlaufwerk (HDD) implementiert werden. Zusätzlich zu oder anstelle der beschriebenen Technologien kann darüber hinaus eine beliebige Anzahl neuer Technologien für den Speicher 1158 verwendet werden, wie z.B. Widerstandsänderungsspeicher, Phasenänderungsspeicher, holographische Speicher oder chemische Speicher, um nur einige zu nennen.
  • Die Komponenten können über die Verbindung 1156 kommunizieren. Die Verbindung 1156 kann eine beliebige Anzahl von Technologien umfassen, einschließlich der Industriestandard-Architektur (ISA), der erweiterten ISA (EISA), der Peripheriekomponenten-Interconnect (PCI), der erweiterten Peripheriekomponenten-Interconnect (PCIx), PCI Express (PCIe) oder einer beliebigen Anzahl anderer Technologien. Die Verbindung 1156 kann ein proprietärer Bus sein, der z.B. in einem SoC-basierten System verwendet wird. Andere Bussysteme können enthalten sein, wie unter anderem z.B. eine I2C-Schnittstelle, eine SPI-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Power-Bus.
  • Die Verbindung 1156 kann den Prozessor 1152 an einen Maschen-Transceiver 1162 koppeln, um mit anderen Maschen-Vorrichtungen 1164 zu kommunizieren. Der Maschen-Transceiver 1162 kann eine beliebige Anzahl von Frequenzen und Protokollen, wie z.B. 2,4 Gigahertz (GHz) Übertragungen nach dem Standard IEEE 802.15.4, mittels des Bluetooth® Low Energy (BLE)-Standards, wie er unter anderem von der Bluetooth® Special Interest Group definiert wurde, oder des ZigBee®-Standards verwenden. Für die Verbindungen zu den Maschen-Vorrichtungen 1164 kann eine beliebige Anzahl von Funkvorrichtungen, die für ein bestimmtes drahtloses Kommunikationsprotokoll konfiguriert sind, verwendet werden. Zum Beispiel kann eine WLAN-Einheit verwendet werden, um in Übereinstimmung mit dem Standard 802.11 des Institute of Electrical and Electronics Engineers (IEEE) eine Wi-Fi™-Kommunikation zu implementieren. Darüber hinaus kann eine drahtlose Weitbereichskommunikation, z.B. nach einem zellularen oder anderen drahtlosen Weitbereichsprotokoll, über eine WWAN-Einheit erfolgen.
  • Der Maschen-Transceiver 1162 kann mittels mehrerer Standards oder Funkvorrichtungen zur Kommunikation mit unterschiedlichen Reichweiten kommunizieren. Die IoT-Vorrichtung 1150 kann mit nahen Vorrichtungen, z.B. innerhalb von etwa 11 Metern, um Strom zu sparen, mittels eines lokalen Transceivers, der auf BLE basiert, oder einer anderen Funkvorrichtung mit niedriger Leistung kommunizieren. Weiter entfernte Maschen-Vorrichtungen 1164, z.B. innerhalb von etwa 50 Metern, können über ZigBee oder andere Funkvorrichtungen mit mittlerer Leistung erreicht werden. Beide Kommunikationstechniken können über eine einzige Funkvorrichtung mit unterschiedlichen Leistungspegeln oder über separate Transceiver erfolgen, z.B. einen lokalen Transceiver, der BLE verwendet, und einen separaten Maschen-Transceiver, der ZigBee verwendet.
  • Ein drahtloser Netzwerk-Transceiver 1166 kann über lokale oder Wide Area Network Protokolle zur Kommunikation mit Vorrichtungen oder Diensten in der Cloud 1100 eingesetzt werden. Der drahtlose Netzwerk-Transceiver 1166 kann ein LPWA-Transceiver sein, der den Standards IEEE 802.15.4 oder IEEE 802.15.4g oder dergleichen folgt. Die IoT-Vorrichtung 1150 kann unter Verwendung von LoRaWAN™ (Long Range Wide Area Network), das von Semtech und der LoRa Alliance entwickelt wurde, über ein weites Gebiet kommunizieren. Die hier beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl anderer Cloud-Transceiver verwendet werden, die eine Kommunikation mit großer Reichweite und geringer Bandbreite durchführen, wie z.B. Sigfox und andere Technologien. Darüber hinaus können andere Kommunikationstechniken, wie z.B. das in der IEEE 802.15.4e Spezifikation beschriebene Kanalsprungverfahren mit Zeitschlitz, verwendet werden.
  • Zusätzlich zu den für den Maschen-Transceiver 1162 und den drahtlosen Netzwerk-Transceiver 1166 genannten Systemen, wie sie hier beschrieben sind, kann eine beliebige Anzahl anderer Funkkommunikationen und Protokolle verwendet werden. Die Funktransceiver 1162 und 1166 können z.B. einen LTE- oder anderen zellularen Transceiver umfassen, der zur Implementierung von Hochgeschwindigkeitskommunikation Spreizspektrum-Kommunikation (SPA/SAS) verwendet. Darüber hinaus kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie z.B. Wi-Fi®-Netzwerke für eine Kommunikation mittlerer Geschwindigkeit und ein Versorgen von Netzwerkkommunikation.
  • Die Funktransceiver 1162 und 1166 können Funkvorrichtungen umfassen, die mit einer beliebigen Anzahl von 3GPP-Spezifikationen (Third Generation Partnership Project) kompatibel sind, insbesondere Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A) und Long Term Evolution-Advanced Pro (LTE-A Pro). Es kann angemerkt werden, dass Funkvorrichtungen ausgewählt werden können, die mit einer beliebigen Anzahl anderer Festnetz-, Mobil- oder Satellitenkommunikationstechnologien und -standards kompatibel sind. Diese können z.B. eine beliebige zellulare Weitbereichsfunkkommunikationstechnologie umfassen, die z.B. ein Kommunikationssystem der 5. Generation (5G), eine Funkkommunikationstechnologie des Globalen Systems für mobile Kommunikation (GSM), eine Funkkommunikationstechnologie des Allgemeinen Paket-Funkdienstes (GPRS) oder eine Funkkommunikationstechnologie mit erhöhten Datenraten für die GSM-Evolution (Enhanced Data Rates for GSM Evolution, EDGE), eine Kommunikationstechnologie des UMTS (Universal Mobile Telecommunications System). Zusätzlich zu den oben aufgeführten Normen kann eine beliebige Anzahl von Satelliten-Uplink-Technologien für den drahtlosen Netzwerk-Transceiver 1166 verwendet werden, einschließlich z.B. Funkvorrichtungen, die regelkonform mit Standards sind, die von der ITU (Internationale Fernmeldeunion) oder dem Europäisches Institut für Telekommunikationsnormen (European Telecommunications Standards Institute, ETSI) oder dergleichen herausgegeben sind. Die hier angeführten Beispiele sind daher in dem Sinne zu verstehen, dass sie auf verschiedene andere Kommunikationstechnologien, sowohl auf bestehende als auch auf noch nicht formulierte, anwendbar sind.
  • Ein Netzwerk-Schnittstellen-Controller (NIC) 1168 kann enthalten sein, um eine drahtgebundene Kommunikation zu der Cloud 1100 oder zu anderen Vorrichtungen, wie z.B. zu den Maschen-Vorrichtungen 1164, zu ermöglichen. Die drahtgebundene Kommunikation kann eine Ethernet-Verbindung vorsehen oder auf anderen Arten von Netzwerken basieren, wie z.B. Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS oder PROFINET, neben vielen anderen. Ein zusätzliches NIC 1168 kann enthalten sein, um eine Verbindung zu einem zweiten Netzwerk zu ermöglichen, z. B. ein NIC 1168, das die Kommunikation mit der Cloud über Ethernet ermöglicht, und ein zweites NIC 1168, das die Kommunikation mit anderen Vorrichtungen über einen anderen Netzwerktyp ermöglicht.
  • Angesichts der Vielfalt der anwendbaren Typen einer Kommunikation von der Vorrichtung zu einer anderen Komponente oder einem anderen Netzwerk können anwendbare Kommunikationsschaltungen, die von der Vorrichtung verwendet werden, eine oder mehrere der Komponenten 1262, 1266, 1268 oder 1270 enthalten oder von diesen verkörpert werden. Dementsprechend können in verschiedenen Beispielen anwendbare Kommunikationsmittel (z.B. Empfangen, Senden und dergleichen) durch eine solche Kommunikationsschaltung verkörpert sein.
  • Die Verbindung 1156 kann den Prozessor 1152 mit einer externen Schnittstelle 1170 koppeln, die zum Anschluss externer Vorrichtungen oder Subsysteme verwendet wird. Zu den externen Vorrichtungen können Sensoren 1172 gehören, wie z.B. Beschleunigungsmesser, Füllstandssensoren, Durchflusssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, Sensoren eines globalen Positionierungssystems (GPS), Drucksensoren, Sensoren für den barometrischen Druck und dergleichen. Die externe Schnittstelle 1170 kann ferner dazu verwendet werden, die IoT-Vorrichtung 1150 mit Aktoren 1174 zu verbinden, wie z.B. Leistungsschaltern, Ventilaktuatoren, einem akustischen Tongenerator, einer visuellen Warneinrichtung und dergleichen.
  • In einigen optionalen Beispielen können verschiedene Ein-/Ausgabevorrichtungen (E/A) innerhalb der IoT-Einheit 1150 vorhanden oder an diese angeschlossen sein. Zum Beispiel kann eine Display- oder sonstige Ausgabevorrichtung 1184 enthalten sein, um Informationen wie z.B. Sensorwerte oder die Stellung eines Aktuators anzuzeigen. Eine Eingabevorrichtung 1186, wie z.B. ein Touchscreen oder eine Tastatur, kann zur Annahme von Eingaben enthalten sein. Eine Ausgabevorrichtung 1184 kann eine beliebige Anzahl von Formen von Audio- oder visuellen Anzeigen beinhalten, beispielsweise einfache visueller Ausgaben wie binäre Statusanzeigen (z.B. LEDs) und visuelle Mehrzeichen-Ausgaben oder komplexere Ausgaben wie z.B. Bildschirme (z.B. LCD-Bildschirme), wobei die Ausgabe von Zeichen, Grafiken, Multimedia-Objekten und dergleichen durch den Betrieb der IoT-Vorrichtung 1150 erzeugt oder hervorgebracht wird.
  • Eine Batterie 1176 kann die IoT-Baugruppe 1150 mit Strom versorgen, obwohl in Beispielen, in denen die IoT-Baugruppe 1150 an einem festen Ort angebracht ist, eine Stromversorgung aufweisen kann, die an ein elektrisches Netz gekoppelt ist. Die Batterie 1176 kann eine Lithium-Ionen-Batterie oder eine Metall-Luft-Batterie sein, wie z.B. eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen.
  • Eine Batterie-Überwachungs-/Ladevorrichtung 1178 kann in die IoT-Vorrichtung 1150 integriert sein, um den Ladezustand (State of Charge, SoCh) der Batterie 1176 zu verfolgen. Die Batterie-Überwachungs-/Ladevorrichtung 1178 kann zur Überwachung anderer Parameter der Batterie 1176 verwendet werden, um Ausfallvorhersagen zu treffen, wie z.B. den Gesundheitszustand (State of Health, SoH) und den Funktionszustand (State of Function, SoF) der Batterie 1176. Die Batterie-Überwachungs-/Ladevorrichtung 1178 kann eine integrierte Schaltung zur Batterieüberwachung enthalten, z.B. einen LTC4020 oder einen LTC2990 von Linear Technologies, einen ADT7488A von ON Semiconductor, Phoenix Arizona, oder einen IC aus der UCD90xxx-Familie von Texas Instruments, Dallas, TX. Die Batterie-Überwachungs-/Ladevorrichtung 1178 kann die Informationen hinsichtlich der Batterie 1176 über die Verbindung 1156 an den Prozessor 1152 übermitteln. Die Batterie-Überwachungs-/Ladevorrichtung 1178 kann auch einen Analog-Digital-Wandler (Analog-to-Digital Convertor, ADC) enthalten, der es dem Prozessor 1152 ermöglicht, die Spannung der Batterie 1176 oder den Stromfluss von der Batterie 1176 direkt zu überwachen. Die Batterieparameter können zur Bestimmung von Aktionen verwendet werden, die die IoT-Vorrichtung 1150 ausführen kann, wie z.B. Übertragungsfrequenz, Maschennetzwerkbetrieb, Abtastfrequenz und dergleichen.
  • Ein Netzteil 1180 oder eine andere an ein Netz gekoppelte Stromversorgung kann mit der Batterie-Überwachungs-/Ladevorrichtung 1178 gekoppelt werden, um die Batterie 1176 zu laden. In einigen Beispielen kann das Netzteil 1180 durch einen drahtlosen Leistungsempfänger ersetzt werden, um die Leistung drahtlos zu erhalten, z.B. über eine Schleifenantenne in der IoT-Vorrichtung 1150. Eine drahtlose Batterieladeschaltung, wie z.B. ein LTC4020-Chip von Linear Technologies aus Milpitas, Kalifornien, kann in der Batterie-Überwachungs-/Ladevorrichtung 1178 enthalten sein. Die gewählten speziellen Ladeschaltungen hängen von der Größe der Batterie 1176 und damit von dem geforderten Strom ab. Das Aufladen kann unter anderem mit dem von der Airfuel Alliance veröffentlichten Airfuel-Standard, dem von dem Wireless Power Consortium veröffentlichten Qi-Drahtlos-Ladestandard oder dem von der Alliance for Wireless Power veröffentlichten Rezence-Ladestandard durchgeführt werden.
  • Um die hier beschriebenen Techniken zu implementieren, kann der Speicher 1158 Befehle 1182 in Form von Software-, Firmware- oder Hardware-Befehlen enthalten. Obwohl solche Befehle 1182 als Code-Blöcke gezeigt sind, die in dem Speicher 1154 und in dem Speicher 1158 enthalten sind, kann selbstverständlich jeder der Code-Blöcke durch fest verdrahtete Schaltkreise, z.B. in einen anwendungsspezifischen integrierten Schaltkreis (Application Specific Integrated Circuit, ASIC) eingebaut, ersetzt werden.
  • In einem Beispiel können die Befehle 1182, die über den Speicher 1154, den Speicher 1158 oder den Prozessor 1152 vorgesehen werden, als ein nichtflüchtiges, maschinenlesbares Medium 1060 dargestellt werden, das Code enthält, um den Prozessor 1052 zu veranlassen, in der IoT-Einheit 1150 elektronische Operationen durchzuführen. Der Prozessor 1152 kann über die Verbindung 1156 auf das nichtflüchtige, maschinenlesbare Medium 1160 zugreifen. Zum Beispiel kann das nichtflüchtige, maschinenlesbare Medium 1160 durch Vorrichtungen verkörpert werden, die für den Speicher 1158 von 11 beschrieben sind, oder es kann spezielle Speichereinheiten wie optische Platten, Flash-Laufwerke oder eine beliebige Anzahl anderer Hardware-Vorrichtungen beinhalten. Das nichtflüchtige, maschinenlesbare Medium 1160 kann Befehle enthalten, die den Prozessor 1152 anweisen, eine bestimmte Abfolge oder einen bestimmten Ablauf von Aktionen durchzuführen, wie z.B. mit Bezug auf die oben dargestellten Flussdiagramme und die Blockdiagramme von Operationen und Funktionalität beschrieben.
  • In einem weiteren speziellen Beispiel können die Befehle 1288 (getrennt oder in Kombination mit den Befehlen 1288 des maschinenlesbaren Mediums 1260) auf dem Prozessor 1252 eine Ausführung oder einen Betrieb einer vertrauenswürdigen Ausführungsumgebung (Trusted Execution Environment, TEE) 1290 konfigurieren. In einem Beispiel arbeitet die TEE 1290 als ein geschützter Bereich, auf den der Prozessor 1252 zur sicheren Ausführung von Befehlen und zum sicheren Zugriff auf Daten zugreifen kann. Verschiedene Implementierungen der TEE 1290 und ein dazugehöriger sicherer Bereich in dem Prozessor 1252 oder in dem Speicher 1254 können z.B. unter Verwendung von Intel® Software Guard Extensions (SGX) oder ARM® TrustZone® Hardware-Sicherheitserweiterungen, Intel® Management Engine (ME) oder Intel® Converged Security Manageability Engine (CSME) vorgesehen werden. Weitere Aspekte der Sicherheitsfestigung, der Wurzeln des Vertrauens von Hardware und vertrauenswürdige oder geschützte Operationen können durch die TEE 1290 und den Prozessor 1252 in die Vorrichtung 1250 implementiert werden.
  • In weiteren Beispielen umfasst ein maschinenlesbares Medium ferner ein materielles Medium, das in der Lage ist, Befehle zur Ausführung durch eine Maschine zu speichern, zu kodieren oder zu übertragen, und das die Maschine veranlasst, eine oder mehrere der Verfahren der vorliegenden Offenbarung durchzuführen, oder das in der Lage ist, Datenstrukturen zu speichern, zu kodieren oder zu übertragen, die von solchen Befehlen verwendet werden oder diesen zugeordnet sind. Ein „maschinenlesbares Medium“ kann daher unter anderem Festkörperspeicher sowie optische und magnetische Medien umfassen. Spezielle Beispiele für maschinenlesbare Medien sind nichtflüchtige Speicher, beispielsweise, jedoch ohne darauf beschränkt zu sein, Halbleiter-Speichervorrichtungen (z.B. elektrisch programmierbare Festwertspeicher (EPROM), elektrisch löschbare programmierbare Festwertspeicher (EEPROM)) und Flash-Speichervorrichtungen; Magnetplatten wie interne Festplatten und Wechselplatten; magneto-optische Platten; und CD-ROM- und DVD-ROM-Platten. Die von einem maschinenlesbaren Medium verkörperten Befehle können ferner über ein Kommunikationsnetz unter Verwendung eines Übertragungsmediums über eine Netzwerkschnittstellenvorrichtung, die ein beliebiges von mehreren Übertragungsprotokollen (z.B. HTTP) verwendet, übertragen oder empfangen werden.
  • Es sollte klar sein, dass die in dieser Spezifikation beschriebenen Funktionseinheiten oder Fähigkeiten als Komponenten oder Module bezeichnet oder gekennzeichnet werden können, um ihre Unabhängigkeit bei der Implementierung besonders hervorzuheben. Solche Komponenten können durch eine beliebige Anzahl von Software- oder Hardwareformen verkörpert werden. So kann ein Bauteil oder Modul beispielsweise als Hardwareschaltung implementiert werden, die kundenspezifische VLSI (Very Large Scale Integration)-Schaltungen oder -Gate-Arrays, handelsübliche Halbleiter wie Logik-Chips, Transistoren oder andere diskrete Komponenten umfasst. Eine Komponente oder ein Modul kann auch in programmierbaren Hardware-Vorrichtungen wie z.B. feldprogrammierbaren Gate-Arrays, einer programmierbaren Array-Logik, programmierbaren Logikvorrichtungen oder dergleichen implementiert werden. Komponenten oder Module können auch in Software implementiert werden, um durch unterschiedliche Arten von Prozessoren ausgeführt zu werden. Eine identifizierte Komponente oder ein identifiziertes Modul eines ausführbaren Codes kann zum Beispiel einen oder mehrere physische oder logische Blöcke von Computerbefehlen umfassen, die zum Beispiel als Objekt, Prozedur oder Funktion organisiert sein können. Dennoch müssen die ausführbaren Codes einer identifizierten Komponente oder eines Moduls nicht unbedingt physisch zusammen angeordnet sein, sondern können unterschiedliche, an verschiedenen Orten gespeicherte Befehle umfassen, die, wenn sie logisch miteinander verknüpft werden, die Komponente oder das Modul bilden und den genannten Zweck für die Komponente oder für das Modul erreichen.
  • In der Tat kann eine Komponente oder ein Modul eines ausführbaren Codes auf einem einzelnen Befehl oder auf vielen Befehle basieren und kann sogar über mehrere verschiedene Codesegmente, über verschiedene Programme und über mehrere Speichervorrichtungen oder Verarbeitungssysteme verteilt sein. Insbesondere können einige Aspekte des beschriebenen Prozesses (wie z.B. ein Neuschreiben von Code und eine Codeanalyse) auf einem anderen Verarbeitungssystem (z.B. in einem Computer in einem Datenzentrum) stattfinden als dasjenige, in dem der Code eingesetzt wird (z.B. in einem Computer, der in einen Sensor oder Roboter eingebettet ist). In ähnlicher Weise können Betriebsdaten innerhalb von Komponenten oder Modulen identifiziert und dargestellt werden und können in jeder geeigneten Form verkörpert und in jeder geeigneten Art von Datenstruktur organisiert werden. Die Betriebsdaten können als ein einzelner Datensatz gesammelt sein, oder können auf andere Orte, beispielsweise auf unterschiedliche Speichergeräte, verteilt sein und liegen möglicherweise wenigstens teilweise lediglich als elektronische Signale auf einem System oder in einem Netzwerk vor. Die Komponenten oder Module können passiv oder aktiv sein, beispielsweise Akteure sein, die in der Lage sind, gewünschte Funktionen durchzuführen.
  • Zusätzliche Beispiele der hier beschriebenen Ausführungsformen von Verfahren, Systemen und Vorrichtungen schließen die folgenden, nicht als beschränkend zu bewertenden Konfigurationen ein. Jedes der folgenden nicht als beschränkend zu bewertenden Beispiele kann für sich stehen oder kann in beliebiger Reihenfolge oder Kombination mit einem oder mehreren der anderen Beispiele zusammengeführt werden, die weiter unten oder über die gesamte vorliegende Beschreibung hinweg vorgeschlagen sind.
  • Beispiel 1 ist eine Vorrichtung, die Folgendes umfasst: Kommunikationsschaltungen; Verarbeitungsschaltungen; und eine Speichervorrichtung, die darauf verkörperte Befehle enthält, wobei die Befehle, die, wenn sie von den Verarbeitungsschaltungen ausgeführt werden, die Verarbeitungsschaltungen so konfigurieren, dass sie Operationen ausführen, die Folgendes umfassen: Empfangen einer Anforderung zum Durchführen eines Eigentümerübertragungsverfahrens einer betreffenden Vorrichtung, wobei die betreffende Vorrichtung einer Vorrichtungsplattform zugeordnet ist; Verifizieren eines Beglaubigungszeugnisses, das der betreffenden Vorrichtung zugeordnet ist, wobei das Beglaubigungszeugnis durch die Vorrichtungsplattform vorgesehen wird, wobei das Beglaubigungszeugnis durch ein Zertifikat signiert wird, das unter Verwendung eines herstellerseitig eingebetteten Schlüssels erzeugt wird, wobei der herstellerseitig eingebettete Schlüssel von einer vertrauenswürdigen Hardwarekomponente der Vorrichtungsplattform vorgesehen wird; und Durchführen einer Vorrichtungsversorgung der betreffenden Vorrichtung auf der Grundlage des Beglaubigungszeugnisses, wobei die Vorrichtungsversorgung die betreffende Vorrichtung dazu veranlasst, ein Sicherheitsprofil zu verwenden, das an herstellerseitig eingebettete Schlüssel gebunden ist.
  • In Beispiel 2 umfasst der Gegenstand des Beispiels 1: Führen einer Liste eigener und vertrauenswürdiger Vorrichtungen der Vorrichtungsplattform, wobei die Liste die betreffende Vorrichtung enthält.
  • In Beispiel 3 umfasst der Gegenstand der Beispiele 1 bis 2 den Gegenstand, wobei das Durchführen der Vorrichtungsversorgung weitere Operationen beinhaltet, die Folgendes umfassen: Versorgen der betreffenden Vorrichtung mit lokalen Berechtigungsnachweisen von einer lokalen Zertifizierungsstelle, wobei die lokale Zertifizierungsstelle von der Vorrichtung betrieben wird, wobei die lokalen Berechtigungsnachweise eine verifizierte Verwendung des Sicherheitsprofils anzeigen, das an herstellerseitig eingebettete Schlüssel gebunden ist.
  • In Beispiel 4 umfasst der Gegenstand der Beispiele 1-3 den Gegenstand, wobei das Durchführen der Vorrichtungsversorgung weitere Operationen beinhaltet, die Folgendes umfassen: Aktualisieren einer Ressource der betreffenden Vorrichtung auf einen Wert, der dem Sicherheitsprofil zugeordnet ist, wobei die betreffende Vorrichtung bei Vervollständigung der Vorrichtungsversorgung auf ein Verwenden des Sicherheitsprofils umgestellt wird.
  • In Beispiel 5 umfasst der Gegenstand der Beispiele 1-4 den Gegenstand, wobei dem herstellerseitig eingebetteten Schlüssel ein Vertrauensanker zugeordnet wird, wobei der Vertrauensanker unter Verwendung eines Vertrauensankerverwaltungsprotokolls verwaltet wird.
  • In Beispiel 6 umfasst der Gegenstand der Beispiele 1-5 den Gegenstand, wobei der herstellerseitig eingebettete Schlüssel mit einer Zertifikatskette verknüpft wird, wobei die Zertifikatskette durch einen Vertrauensanker abgeschlossen wird, und wobei das Beglaubigungszeugnis den Vertrauensanker enthält.
  • In Beispiel 7 umfasst der Gegenstand der Beispiele 1-6 den Gegenstand, wobei dem herstellerseitig eingebetteten Schlüssel ein Plattform-Attributsberechtigungsnachweis der Vorrichtungsplattform zugeordnet wird, und wobei der Plattform-Attributsberechtigungsnachweis Plattforminformationen enthält, die sich an einer Datenquelle einer dritten Partei öffentlich verifizieren lassen.
  • In Beispiel 8 umfasst der Gegenstand der Beispiele 1-7 ein Abfragen einer Blockkette, um einen Vertrauensanker zu bestätigen, der mit dem herstellerseitig eingebetteten Schlüssel verknüpft ist.
  • In Beispiel 9 umfasst der Gegenstand von Beispiel 8: Abfragen der Blockkette, um nach einem Vertrauensanker-Widerruf für den Vertrauensanker zu suchen, der mit dem herstellerseitig eingebetteten Schlüssel verknüpft ist; und Veranlassen, dass die betreffend Vorrichtung ein anderes Sicherheitsprofil für die betreffende Vorrichtung verwendet, das auf einer Identifizierung des Vertrauensanker-Widerrufs basiert.
  • In Beispiel 10 umfasst der Gegenstand der Beispiele 1-9 den Gegenstand, wobei die betreffende Vorrichtung eine vertrauenswürdige Boot-Sequenz einer Vorrichtungssoftware für den Betrieb auf der betreffenden Vorrichtung durchführt, und wobei das Beglaubigungszeugnis eine Verifizierung der vertrauenswürdigen Boot-Sequenz durch die Vorrichtungsplattform enthält.
  • In Beispiel 11 umfasst der Gegenstand der Beispiele 1-10 den Gegenstand, wobei die Vorrichtung ein Onboarding-Tool ist und wobei die Vorrichtung und die Vorrichtungsplattform gemäß einer Spezifikation einer Familie von Standards der Open Connectivity Foundation (OCF) konfiguriert sind.
  • In Beispiel 12 umfasst der Gegenstand der Beispiele 1-11 den Gegenstand, wobei die vertrauenswürdige Hardwarekomponente und die Vorrichtung gemäß einer Spezifikation einer Familie von Standards der Trusted Computing Group (TCG) konfiguriert sind.
  • Beispiel 13 ist ein Verfahren zum Onboarding (An Bord Nehmen) einer betreffenden Vorrichtung zur Verwendung mit einem Sicherheitsprofil unter Verwendung von Operationen, die von einer Onboarding-Tool-Vorrichtung durchgeführt werden, Folgendes umfassend: Empfangen einer Anforderung zum Durchführen eines Eigentümerübertragungsverfahrens der betreffenden Vorrichtung, wobei die betreffende Vorrichtung einer Vorrichtungsplattform zugeordnet ist; Verifizieren eines Beglaubigungszeugnisses, das der betreffenden Vorrichtung zugeordnet ist, wobei das Beglaubigungszeugnis durch die Vorrichtungsplattform vorgesehen wird, wobei das Beglaubigungszeugnis durch ein Zertifikat signiert wird, das unter Verwendung eines herstellerseitig eingebetteten Schlüssels erzeugt wird, und wobei der herstellerseitig eingebettete Schlüssel von einer vertrauenswürdigen Hardwarekomponente der Vorrichtungsplattform vorgesehen wird; und Durchführen einer Vorrichtungsversorgung der betreffenden Vorrichtung auf der Grundlage des Beglaubigungszeugnisses, wobei die Vorrichtungsversorgung die betreffende Vorrichtung dazu veranlasst, ein Sicherheitsprofil zu verwenden, das an herstellerseitig eingebettete Schlüssel gebunden ist.
  • In Beispiel 14 umfasst der Gegenstand von Beispiel 13 ein Führen einer Liste eigener und vertrauenswürdiger Vorrichtungen der Vorrichtungsplattform, wobei die Liste die betreffende Vorrichtung enthält.
  • In Beispiel 15 umfasst der Gegenstand der Beispiele 13-14 den Gegenstand, wobei das Durchführen der Vorrichtungsversorgung weitere Operationen beinhaltet, die Folgendes umfassen: Versorgen der betreffenden Vorrichtung mit lokalen Berechtigungsnachweisen von einer lokalen Zertifizierungsstelle, wobei die lokale Zertifizierungsstelle von der Vorrichtung betrieben wird, wobei die lokalen Berechtigungsnachweise eine verifizierte Verwendung des Sicherheitsprofils anzeigen, das an herstellerseitig eingebettete Schlüssel gebunden ist.
  • In Beispiel 16 umfasst der Gegenstand der Beispiele 13-15 den Gegenstand, wobei das Durchführen der Vorrichtungsversorgung weitere Operationen beinhaltet, die Folgendes umfassen: Aktualisieren einer Ressource der betreffenden Vorrichtung auf einen Wert, der dem Sicherheitsprofil zugeordnet ist, wobei die betreffende Vorrichtung bei Vervollständigung der Vorrichtungsversorgung auf ein Verwenden des Sicherheitsprofils umgestellt wird.
  • In Beispiel 17 umfasst der Gegenstand der Beispiele 13-16 den Gegenstand, wobei dem herstellerseitig eingebetteten Schlüssel ein Vertrauensanker zugeordnet wird, wobei der Vertrauensanker unter Verwendung eines Vertrauensankerverwaltungsprotokolls verwaltet wird.
  • In Beispiel 18 umfasst der Gegenstand der Beispiele 13-17 den Gegenstand, wobei der herstellerseitig eingebettete Schlüssel mit einer Zertifikatskette verknüpft wird, wobei die Zertifikatskette durch einen Vertrauensanker abgeschlossen wird, und wobei das Beglaubigungszeugnis den Vertrauensanker enthält.
  • In Beispiel 19 umfasst der Gegenstand der Beispiele 13-18 den Gegenstand, wobei dem herstellerseitig eingebetteten Schlüssel ein Plattform-Attributsberechtigungsnachweis der Vorrichtungsplattform zugeordnet wird, und wobei der Plattform-Attributsberechtigungsnachweis Plattforminformationen enthält, die sich an einer Datenquelle einer dritten Partei öffentlich verifizieren lassen.
  • In Beispiel 20 umfasst der Gegenstand der Beispiele 13-19: Abfragen einer Blockkette, um einen Vertrauensanker zu bestätigen, der mit dem herstellerseitig eingebetteten Schlüssel verknüpft ist.
  • In Beispiel 21 umfasst der Gegenstand von Beispiel 20: Abfragen der Blockkette, um nach einem Vertrauensanker-Widerruf für den Vertrauensanker zu suchen, der mit dem herstellerseitig eingebetteten Schlüssel verknüpft ist; und Veranlassen, dass die betreffend Vorrichtung ein anderes Sicherheitsprofil für die betreffende Vorrichtung verwendet, das auf einer Identifizierung des Vertrauensanker-Widerrufs basiert.
  • In Beispiel 22 umfasst der Gegenstand der Beispiele 15-21 den Gegenstand, wobei die betreffende Vorrichtung eine vertrauenswürdige Boot-Sequenz einer Vorrichtungssoftware für den Betrieb auf der betreffenden Vorrichtung durchführt, und wobei das Beglaubigungszeugnis eine Verifizierung der vertrauenswürdigen Boot-Sequenz durch die Vorrichtungsplattform enthält.
  • In Beispiel 23 umfasst der Gegenstand der Beispiele 15-22 den Gegenstand, wobei die Onboarding-Tool-Vorrichtung und die Vorrichtungsplattform gemäß einer Spezifikation einer Familie von Standards der Open Connectivity Foundation (OCF) arbeiten.
  • In Beispiel 24 umfasst der Gegenstand von Beispiel 23 den Gegenstand, wobei die vertrauenswürdige Hardwarekomponente und die Vorrichtungsplattform gemäß einer Spezifikation einer Familie von Standards der Trusted Computing Group (TCG) konfiguriert werden.
  • Beispiel 25 ist ein maschinenlesbares Speichermedium mit Befehlen, wobei die Befehle, wenn sie von einer Verarbeitungsschaltung einer Computervorrichtung ausgeführt werden, die Verarbeitungsschaltung veranlassen, Operationen der Beispiele 13 bis 24 durchzuführen.
  • Beispiel 26 ist eine Einrichtung, die Folgendes umfasst: Mittel zum Empfangen einer Anforderung zum Durchführen eines Eigentümerübertragungsverfahrens einer betreffenden Vorrichtung, wobei die betreffende Vorrichtung einer Vorrichtungsplattform zugeordnet ist; Mittel zum Verifizieren eines Beglaubigungszeugnisses, das der betreffenden Vorrichtung zugeordnet ist, wobei das Beglaubigungszeugnis durch die Vorrichtungsplattform vorgesehen wird, wobei das Beglaubigungszeugnis durch ein Zertifikat signiert wird, das unter Verwendung eines herstellerseitig eingebetteten Schlüssels erzeugt wird, und wobei der herstellerseitig eingebettete Schlüssel von einer vertrauenswürdigen Hardwarekomponente der Vorrichtungsplattform vorgesehen wird; und Mittel zum Durchführen einer Vorrichtungsversorgung der betreffenden Vorrichtung auf der Grundlage des Beglaubigungszeugnisses, wobei die Vorrichtungsversorgung die betreffende Vorrichtung dazu veranlasst, ein Sicherheitsprofil zu verwenden, das an herstellerseitig eingebettete Schlüssel gebunden ist.
  • In Beispiel 27 umfasst der Gegenstand von Beispiel 26 Mittel zum Führen einer Liste eigener und vertrauenswürdiger Vorrichtungen der Vorrichtungsplattform, wobei die Liste die betreffende Vorrichtung enthält.
  • In Beispiel 28 umfasst der Gegenstand der Beispiele 26-27 Mittel zum Versorgen der betreffenden Vorrichtung mit lokalen Berechtigungsnachweisen von einer lokalen Zertifizierungsstelle, wobei die lokale Zertifizierungsstelle von der Vorrichtung betrieben wird, wobei die lokalen Berechtigungsnachweise eine verifizierte Verwendung des Sicherheitsprofils anzeigen, das an herstellerseitig eingebettete Schlüssel gebunden ist.
  • In Beispiel 29 umfasst der Gegenstand der Beispiele 26-28 Mittel zum Aktualisieren einer Ressource der betreffenden Vorrichtung auf einen Wert, der dem Sicherheitsprofil zugeordnet ist, wobei die betreffende Vorrichtung bei Vervollständigung der Vorrichtungsversorgung auf ein Verwenden des Sicherheitsprofils umgestellt wird.
  • In Beispiel 30 umfasst der Gegenstand der Beispiele 26-29 den Gegenstand, wobei dem herstellerseitig eingebetteten Schlüssel ein Vertrauensanker zugeordnet wird, wobei der Vertrauensanker unter Verwendung eines Vertrauensankerverwaltungsprotokolls verwaltet wird.
  • In Beispiel 31 umfasst der Gegenstand der Beispiele 26-30 den Gegenstand, wobei der herstellerseitig eingebettete Schlüssel mit einer Zertifikatskette verknüpft wird, wobei die Zertifikatskette durch einen Vertrauensanker abgeschlossen wird, und wobei das Beglaubigungszeugnis den Vertrauensanker enthält.
  • In Beispiel 32 umfasst der Gegenstand der Beispiele 26-31 den Gegenstand, wobei dem herstellerseitig eingebetteten Schlüssel ein Plattform-Attributsberechtigungsnachweis der Vorrichtungsplattform zugeordnet wird, und wobei der Plattform-Attributsberechtigungsnachweis Plattforminformationen enthält, die sich an einer Datenquelle einer dritten Partei öffentlich verifizieren lassen.
  • In Beispiel 33 umfasst der Gegenstand der Beispiele 26-32 Mittel zum Abfragen einer Blockkette, um einen Vertrauensanker zu bestätigen, der mit dem herstellerseitig eingebetteten Schlüssel verknüpft ist.
  • In Beispiel 34 umfasst der Gegenstand von Beispiel 33 Mittel zum Abfragen der Blockkette, um nach einem Vertrauensanker-Widerruf für den Vertrauensanker zu suchen, der mit dem herstellerseitig eingebetteten Schlüssel verknüpft ist; und Mittel, um die betreffende Vorrichtung zu veranlassen, ein anderes Sicherheitsprofil für die betreffende Vorrichtung zu verwenden, das auf einer Identifizierung des Vertrauensanker-Widerrufs basiert.
  • In Beispiel 35 umfasst der Gegenstand der Beispiele 26-34 den Gegenstand, wobei die betreffende Vorrichtung eine vertrauenswürdige Boot-Sequenz einer Vorrichtungssoftware für den Betrieb auf der betreffenden Vorrichtung durchführt, und wobei das Beglaubigungszeugnis eine Verifizierung der vertrauenswürdigen Boot-Sequenz durch die Vorrichtungsplattform enthält.
  • In Beispiel 36 umfasst der Gegenstand der Beispiele 26-35 den Gegenstand, wobei die Einrichtung und die Vorrichtungsplattform gemäß einer Spezifikation einer Familie von Standards der Open Connectivity Foundation (OCF) arbeiten.
  • In Beispiel 37 umfasst der Gegenstand der Beispiele 26-36 den Gegenstand, wobei die vertrauenswürdige Hardwarekomponente und die Vorrichtungsplattform gemäß einer Spezifikation einer Familie von Standards der Trusted Computing Group (TCG) konfiguriert werden.
  • Beispiel 38 ist eine IoT-Dienstplattform, die dafür eingerichtet ist, die Operationen der Beispiele 1 bis 37 durchzuführen.
  • Beispiel 39 ist eine Open Connectivity Foundation (OCF) Vorrichtung, die als Server, Client oder intermediär gemäß einer OCF-Spezifikation konfiguriert ist und Mittel zur Implementierung der Operationen der Beispiele 1 bis 37 umfasst.
  • Beispiel 40 ist ein Verwaltungsdienst für einen Vorrichtungseigentümerübertragungsdienst, der dafür eingerichtet ist, die Operationen durchzuführen, die durch ein beliebiges der Beispiele 1 bis 37 aufgerufen sind.
  • Beispiel 41 ist eine Netzwerktopologie des Internet der Dinge (IoT), wobei die IoT-Netzwerktopologie entsprechende Kommunikationsverbindungen umfasst, die dafür eingerichtet sind, Kommunikation für die Operationen beliebiger der Beispiele 1 bis 37 durchzuführen.
  • Beispiel 42 ist ein Netzwerk, das entsprechende Vorrichtungen und Vorrichtungskommunikationsmedien zum Durchführen beliebiger der Operationen der Beispiele 1 bis 37 umfasst.
  • Beispiel 43 ist eine Einrichtung, das Mittel zum Durchführen beliebiger der Operationen der Beispiele 1 bis 37 umfasst.
  • Beispiel 44 ist ein System zum Durchführen der Operationen beliebiger der Beispiele 1 bis 37.
  • Die Operationen und Funktionen, die oben in diesen Beispielen beschrieben sind, und in den speziellen Ausführungsformen, die mit Bezug auf 3 bis 9 beschriebenen sind, können in ganz unterschiedlichen Netzwerkumgebungen, beispielsweise IoT-Netzwerkbetrieb, Rand-Netzwerkbetrieb, Fog-Netzwerkbetrieb, Cloud-Netzwerkbetrieb und allen Mischformen davon angewendet werden. Die Operationen und die Funktionalität dieser Beispiele und Konfigurationen können auf verteilte Weise erfolgen, einschließlich in verteilten Netzwerkumgebungen, bei denen ein Aspekt der Funktionalität von einer ersten IoT-Rand-Vorrichtung oder einem Rand-Netzwerk, ein anderer Aspekt der Funktionalität von einem Fog-Netzwerk oder einer Plattform und ein weiterer Aspekt der Funktionalität von einer Cloud-Vorrichtung oder einem Cloud-System ausgeführt wird. Weiter können Kombinationen eingesetzt werden, die diesen gemeinsamen, verteilten oder gruppierenden Prinzipien folgen, wie sie in den Beispielen und Konfigurationen oben vorgeschlagen sind. Dementsprechend ist klar, dass die hier beschriebene Funktionalität innerhalb vieler Permutationen der obigen Beispiele und Konfigurationen und ähnlichen Variationen arbeiten kann.
  • In der obigen ausführlichen Beschreibung sind verschiedene Funktionen möglicherweise zusammengefasst, um die Offenbarung zu straffen. Die Ansprüche können jedoch nicht sämtliche hier offenbarten Merkmale darlegen, da Ausführungsformen einen Teilsatz der genannten Merkmale aufweisen können. Weiter können Ausführungsformen weniger Merkmale enthalten als die in einem bestimmten Beispiel offenbarten. Folglich sind die nachfolgenden Ansprüche hierdurch in die detaillierte Beschreibung einbezogen, wobei ein Anspruch für sich allein als separate Ausführungsform steht.

Claims (37)

  1. Vorrichtung, aufweisend: Kommunikationsschaltungen; Verarbeitungsschaltungen; und eine Speichervorrichtung, die darauf verkörperte Befehle enthält, wobei die Befehle, die, wenn sie von den Verarbeitungsschaltungen ausgeführt werden, die Verarbeitungsschaltungen so konfigurieren, dass sie Operationen ausführen, die Folgendes umfassen: Empfangen einer Anforderung zum Durchführen eines Eigentümerübertragungsverfahrens einer betreffenden Vorrichtung, wobei die betreffende Vorrichtung einer Vorrichtungsplattform zugeordnet ist; Verifizieren eines Beglaubigungszeugnisses, das der betreffenden Vorrichtung zugeordnet ist, wobei das Beglaubigungszeugnis durch die Vorrichtungsplattform vorgesehen wird, wobei das Beglaubigungszeugnis durch ein Zertifikat signiert wird, das unter Verwendung eines herstellerseitig eingebetteten Schlüssels erzeugt wird, wobei der herstellerseitig eingebettete Schlüssel von einer vertrauenswürdigen Hardwarekomponente der Vorrichtungsplattform vorgesehen wird; und Durchführen einer Vorrichtungsversorgung der betreffenden Vorrichtung auf der Grundlage des Beglaubigungszeugnisses, wobei die Vorrichtungsversorgung die betreffende Vorrichtung dazu veranlasst, ein Sicherheitsprofil zu verwenden, das an herstellerseitig eingebettete Schlüssel gebunden ist.
  2. Vorrichtung nach Anspruch 1, wobei die Operationen ferner umfassen: Führen einer Liste eigener und vertrauenswürdiger Vorrichtungen der Vorrichtungsplattform, wobei die Liste die betreffende Vorrichtung enthält.
  3. Vorrichtung nach Anspruch 1, wobei das Durchführen der Vorrichtungsversorgung weitere Operationen beinhaltet, die Folgendes umfassen: Versorgen der betreffenden Vorrichtung mit lokalen Berechtigungsnachweisen von einer lokalen Zertifizierungsstelle, wobei die lokale Zertifizierungsstelle von der Vorrichtung betrieben wird, wobei die lokalen Berechtigungsnachweise eine verifizierte Verwendung des Sicherheitsprofils anzeigen, das an herstellerseitig eingebettete Schlüssel gebunden ist.
  4. Vorrichtung nach Anspruch 1, wobei das Durchführen der Vorrichtungsversorgung weitere Operationen beinhaltet, die Folgendes umfassen: Aktualisieren einer Ressource der betreffenden Vorrichtung auf einen Wert, der dem Sicherheitsprofil zugeordnet ist, wobei die betreffende Vorrichtung bei Vervollständigung der Vorrichtungsversorgung auf ein Verwenden des Sicherheitsprofils umgestellt wird.
  5. Vorrichtung nach Anspruch 1, wobei dem herstellerseitig eingebetteten Schlüssel ein Vertrauensanker zugeordnet wird, wobei der Vertrauensanker unter Verwendung eines Vertrauensankerverwaltungsprotokolls verwaltet wird.
  6. Vorrichtung nach Anspruch 1, wobei der herstellerseitig eingebettete Schlüssel mit einer Zertifikatskette verknüpft wird, wobei die Zertifikatskette durch einen Vertrauensanker abgeschlossen wird, und wobei das Beglaubigungszeugnis den Vertrauensanker enthält.
  7. Vorrichtung nach Anspruch 1, wobei dem herstellerseitig eingebetteten Schlüssel ein Plattform-Attributsberechtigungsnachweis der Vorrichtungsplattform zugeordnet wird, und wobei der Plattform-Attributsberechtigungsnachweis Plattforminformationen enthält, die sich an einer Datenquelle einer dritten Partei öffentlich verifizieren lassen.
  8. Vorrichtung nach Anspruch 1, wobei die Operationen ferner umfassen: Abfragen einer Blockkette, um einen Vertrauensanker zu bestätigen, der mit dem herstellerseitig eingebetteten Schlüssel verknüpft ist.
  9. Vorrichtung nach Anspruch 8, wobei die Operationen ferner umfassen: Abfragen der Blockkette, um nach einem Vertrauensanker-Widerruf für den Vertrauensanker zu suchen, der mit dem herstellerseitig eingebetteten Schlüssel verknüpft ist; und Veranlassen, dass die betreffende Vorrichtung ein anderes Sicherheitsprofil verwendet, das auf einer Identifizierung des Vertrauensanker-Widerrufs basiert.
  10. Vorrichtung nach Anspruch 1, wobei die betreffende Vorrichtung eine vertrauenswürdige Boot-Sequenz einer Vorrichtungssoftware für den Betrieb auf der betreffenden Vorrichtung durchführt und wobei das Beglaubigungszeugnis eine Verifizierung der vertrauenswürdigen Boot-Sequenz durch die Vorrichtungsplattform enthält.
  11. Vorrichtung nach Anspruch 1, wobei die Vorrichtung ein Onboarding-Tool ist und wobei die Vorrichtung und die Vorrichtungsplattform gemäß einer Spezifikation einer Familie von Standards der Open Connectivity Foundation (OCF) konfiguriert sind.
  12. Vorrichtung nach Anspruch 1, wobei die vertrauenswürdige Hardwarekomponente und die Vorrichtung gemäß einer Spezifikation einer Familie von Standards der Trusted Computing Group (TCG) konfiguriert sind.
  13. Verfahren zum Onboarding („An Bord aufnehmen“) einer betreffenden Vorrichtung zur Verwendung mit einem Sicherheitsprofil unter Verwendung von Operationen, die von einer Onboarding-Tool-Vorrichtung durchgeführt werden, Folgendes umfassend: Empfangen einer Anforderung zum Durchführen eines Eigentümerübertragungsverfahrens der betreffenden Vorrichtung, wobei die betreffende Vorrichtung einer Vorrichtungsplattform zugeordnet ist; Verifizieren eines Beglaubigungszeugnisses, das der betreffenden Vorrichtung zugeordnet ist, wobei das Beglaubigungszeugnis durch die Vorrichtungsplattform vorgesehen wird, wobei das Beglaubigungszeugnis durch ein Zertifikat signiert wird, das unter Verwendung eines herstellerseitig eingebetteten Schlüssels erzeugt wird, und wobei der herstellerseitig eingebettete Schlüssel von einer vertrauenswürdigen Hardwarekomponente der Vorrichtungsplattform vorgesehen wird; und Durchführen einer Vorrichtungsversorgung der betreffenden Vorrichtung auf der Grundlage des Beglaubigungszeugnisses, wobei die Vorrichtungsversorgung die betreffende Vorrichtung dazu veranlasst, ein Sicherheitsprofil zu verwenden, das an herstellerseitig eingebettete Schlüssel gebunden ist.
  14. Verfahren nach Anspruch 13, ferner umfassend: Führen einer Liste eigener und vertrauenswürdiger Vorrichtungen der Vorrichtungsplattform, wobei die Liste die betreffende Vorrichtung enthält.
  15. Verfahren nach Anspruch 13, wobei das Durchführen der Vorrichtungsversorgung weitere Operationen beinhaltet, die Folgendes umfassen: Versorgen der betreffenden Vorrichtung mit lokalen Berechtigungsnachweisen von einer lokalen Zertifizierungsstelle, wobei die lokale Zertifizierungsstelle von der Vorrichtung betrieben wird, wobei die lokalen Berechtigungsnachweise eine verifizierte Verwendung des Sicherheitsprofils anzeigen, das an herstellerseitig eingebettete Schlüssel gebunden ist.
  16. Verfahren nach Anspruch 13, wobei das Durchführen der Vorrichtungsversorgung weitere Operationen beinhaltet, die Folgendes umfassen: Aktualisieren einer Ressource der betreffenden Vorrichtung auf einen Wert, der dem Sicherheitsprofil zugeordnet ist, wobei die betreffende Vorrichtung bei Vervollständigung der Vorrichtungsversorgung auf ein Verwenden des Sicherheitsprofils umgestellt wird.
  17. Verfahren nach Anspruch 13, wobei dem herstellerseitig eingebetteten Schlüssel ein Vertrauensanker zugeordnet wird, wobei der Vertrauensanker unter Verwendung eines Vertrauensankerverwaltungsprotokolls verwaltet wird.
  18. Verfahren nach Anspruch 13, wobei der herstellerseitig eingebettete Schlüssel mit einer Zertifikatskette verknüpft wird, wobei die Zertifikatskette durch einen Vertrauensanker abgeschlossen wird, und wobei das Beglaubigungszeugnis den Vertrauensanker enthält.
  19. Verfahren nach Anspruch 13, wobei dem herstellerseitig eingebetteten Schlüssel ein Plattform-Attributsberechtigungsnachweis der Vorrichtungsplattform zugeordnet wird, und wobei der Plattform-Attributsberechtigungsnachweis Plattforminformationen enthält, die sich an einer Datenquelle einer dritten Partei öffentlich verifizieren lassen.
  20. Verfahren nach Anspruch 13, wobei die Operationen ferner umfassen: Abfragen einer Blockkette, um einen Vertrauensanker zu bestätigen, der mit dem herstellerseitig eingebetteten Schlüssel verknüpft ist.
  21. Verfahren nach Anspruch 20, wobei die Operationen ferner umfassen: Abfragen der Blockkette, um nach einem Vertrauensanker-Widerruf für den Vertrauensanker zu suchen, der mit dem herstellerseitig eingebetteten Schlüssel verknüpft ist; und Veranlassen, dass die betreffende Vorrichtung ein anderes Sicherheitsprofil verwendet, das auf einer Identifizierung des Vertrauensanker-Widerrufs basiert.
  22. Verfahren nach Anspruch 13, wobei die betreffende Vorrichtung eine vertrauenswürdige Boot-Sequenz einer Vorrichtungssoftware für den Betrieb auf der betreffenden Vorrichtung durchführt, und wobei das Beglaubigungszeugnis eine Verifizierung der vertrauenswürdigen Boot-Sequenz durch die Vorrichtungsplattform enthält.
  23. Verfahren nach Anspruch 13, wobei die Onboarding-Tool-Vorrichtung und die Vorrichtungsplattform gemäß einer Spezifikation einer Familie von Standards der Open Connectivity Foundation (OCF) arbeiten.
  24. Verfahren nach Anspruch 23, wobei die vertrauenswürdige Hardwarekomponente und die Vorrichtungsplattform gemäß einer Spezifikation einer Familie von Standards der Trusted Computing Group (TCG) konfiguriert werden.
  25. Maschinenlesbares Speichermedium, das Befehle enthält, wobei die Befehle, wenn sie von einer Verarbeitungsschaltung einer Computervorrichtung ausgeführt werden, die Verarbeitungsschaltung veranlassen, Operationen nach einem der Ansprüche 13 bis 24 durchzuführen.
  26. Einrichtung, Folgendes aufweisend: Mittel zum Empfangen einer Anforderung zum Durchführen eines Eigentümerübertragungsverfahrens einer betreffenden Vorrichtung, wobei die betreffende Vorrichtung einer Vorrichtungsplattform zugeordnet ist; Mittel zum Verifizieren eines Beglaubigungszeugnisses, das der betreffenden Vorrichtung zugeordnet ist, wobei das Beglaubigungszeugnis durch die Vorrichtungsplattform vorgesehen wird, wobei das Beglaubigungszeugnis durch ein Zertifikat signiert wird, das unter Verwendung eines herstellerseitig eingebetteten Schlüssels erzeugt wird, und wobei der herstellerseitig eingebettete Schlüssel von einer vertrauenswürdigen Hardwarekomponente der Vorrichtungsplattform vorgesehen wird; und Mittel zum Durchführen einer Vorrichtungsversorgung der betreffenden Vorrichtung auf der Grundlage des Beglaubigungszeugnisses, wobei die Vorrichtungsversorgung die betreffende Vorrichtung dazu veranlasst, ein Sicherheitsprofil zu verwenden, das an herstellerseitig eingebettete Schlüssel gebunden ist.
  27. Einrichtung nach Anspruch 26, ferner aufweisend: Mittel zum Führen einer Liste eigener und vertrauenswürdiger Vorrichtungen der Vorrichtungsplattform, wobei die Liste die betreffende Vorrichtung enthält.
  28. Einrichtung nach Anspruch 26, ferner aufweisend: Mittel zum Versorgen der betreffenden Vorrichtung mit lokalen Berechtigungsnachweisen von einer lokalen Zertifizierungsstelle, wobei die lokale Zertifizierungsstelle von der Vorrichtung betrieben wird, wobei die lokalen Berechtigungsnachweise eine verifizierte Verwendung des Sicherheitsprofils anzeigen, das an herstellerseitig eingebettete Schlüssel gebunden ist.
  29. Einrichtung nach Anspruch 26, ferner aufweisend: Mittel zum Aktualisieren einer Ressource der betreffenden Vorrichtung auf einen Wert, der dem Sicherheitsprofil zugeordnet ist, wobei die betreffende Vorrichtung bei Vervollständigung der Vorrichtungsversorgung auf ein Verwenden des Sicherheitsprofils umgestellt wird.
  30. Einrichtung nach Anspruch 26, wobei dem herstellerseitig eingebetteten Schlüssel ein Vertrauensanker zugeordnet wird, wobei der Vertrauensanker unter Verwendung eines Vertrauensankerverwaltungsprotokolls verwaltet wird.
  31. Einrichtung nach Anspruch 26, wobei der herstellerseitig eingebettete Schlüssel mit einer Zertifikatskette verknüpft wird, wobei die Zertifikatskette durch einen Vertrauensanker abgeschlossen wird, und wobei das Beglaubigungszeugnis den Vertrauensanker enthält.
  32. Einrichtung nach Anspruch 26, wobei dem herstellerseitig eingebetteten Schlüssel ein Plattform-Attributsberechtigungsnachweis der Vorrichtungsplattform zugeordnet wird, und wobei der Plattform-Attributsberechtigungsnachweis Plattforminformationen enthält, die sich an einer Datenquelle einer dritten Partei öffentlich verifizieren lassen.
  33. Einrichtung nach Anspruch 26, ferner aufweisend: Mittel zum Abfragen einer Blockkette, um einen Vertrauensanker zu bestätigen, der mit dem herstellerseitig eingebetteten Schlüssel verknüpft ist.
  34. Einrichtung nach Anspruch 33, ferner aufweisend: Mittel zum Abfragen der Blockkette, um nach einem Vertrauensanker-Widerruf für den Vertrauensanker zu suchen, der mit dem herstellerseitig eingebetteten Schlüssel verknüpft ist; und Mittel, um die betreffende Vorrichtung zu veranlassen, ein anderes Sicherheitsprofil zu verwenden, das auf dem Vertrauensanker-Widerruf basiert.
  35. Einrichtung nach Anspruch 26, wobei die betreffende Vorrichtung eine vertrauenswürdige Boot-Sequenz einer Vorrichtungssoftware für den Betrieb auf der betreffenden Vorrichtung durchführt und wobei das Beglaubigungszeugnis eine Verifizierung der vertrauenswürdigen Boot-Sequenz durch die Vorrichtungsplattform enthält.
  36. Einrichtung nach Anspruch 26, wobei die Einrichtung und die Vorrichtungsplattform gemäß einer Spezifikation einer Familie von Standards der Open Connectivity Foundation (OCF) arbeiten.
  37. Einrichtung nach Anspruch 26, wobei die vertrauenswürdige Hardwarekomponente und die Vorrichtungsplattform gemäß einer Spezifikation einer Familie von Standards der Trusted Computing Group (TCG) konfiguriert werden.
DE112018006935.4T 2018-01-24 2018-09-28 Sicherheitsprofile für OCF-Vorrichtungen und vertrauenswürdige Plattformen Pending DE112018006935T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201862621376P 2018-01-24 2018-01-24
US62/621,376 2018-01-24
PCT/US2018/053433 WO2019147311A1 (en) 2018-01-24 2018-09-28 Security profiles for ocf devices and trusted platforms

Publications (1)

Publication Number Publication Date
DE112018006935T5 true DE112018006935T5 (de) 2020-10-08

Family

ID=63915123

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112018006935.4T Pending DE112018006935T5 (de) 2018-01-24 2018-09-28 Sicherheitsprofile für OCF-Vorrichtungen und vertrauenswürdige Plattformen

Country Status (3)

Country Link
CN (1) CN111201529A (de)
DE (1) DE112018006935T5 (de)
WO (1) WO2019147311A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2582738B (en) * 2019-02-01 2021-07-07 Arm Ip Ltd Electronic device registration mechanism
US11689416B2 (en) * 2019-08-05 2023-06-27 Telefonaktiebolaget Lm Ericsson (Publ) Hardware device onboarding
CN112995038B (zh) * 2019-12-16 2022-03-15 中国科学院沈阳自动化研究所 Profinet协议在工业sdn中的接入方法
US11233632B1 (en) 2020-07-02 2022-01-25 Cal-Chip Electronics Specialty Products, Inc. Connected secure key redistribution system and method

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150134965A1 (en) * 2012-05-24 2015-05-14 Telefonaktiebolaget L M Ericsson (Publ) Enhanced Secure Virtual Machine Provisioning
US11144911B2 (en) * 2016-06-20 2021-10-12 Intel Corporation Technologies for device commissioning

Also Published As

Publication number Publication date
CN111201529A (zh) 2020-05-26
WO2019147311A1 (en) 2019-08-01
US20220303123A1 (en) 2022-09-22

Similar Documents

Publication Publication Date Title
DE112018007052T5 (de) Konfiguration und Onboarding von vertrauenswürdigen IOT-Vorrichtungen
DE112018005260T5 (de) Sichere Gerät-Onboarding-Techniken
DE112017008311T5 (de) Technologien zur internet-der-dinge-schlüsselverwaltung
US11734458B2 (en) Extensible layered trusted computing base for computing devices
US11770383B2 (en) Cloud-to-device mediator service from services definition
US11337070B2 (en) User-authorized onboarding using a public authorization service
DE112017006994T5 (de) Bereitstellung und verwaltung von microservices
DE102020131613A1 (de) Verfahren, system und produkt zum implementieren von deterministischem on-boarding und planen virtualisierter arbeitslasten für edge-computing.
DE112018007463T5 (de) Flexibler Mehrfachzugriffs-Edge-Computing-Dienstverbrauch (Mec-Dienstverbrauch) durch Hostzoning
DE112020002310T5 (de) V2x-dienste zur bereitstellung fahrtspezifischer qos-vorhersagen
US11601436B2 (en) Internet of things (IoT) network domain resource model
DE112018007007T5 (de) Verteilte selbstsouveräne identitäten zur virtualisierung von netzwerkfunktionen
DE112018005810T5 (de) Plugin-management für internet of things- (iot) netzwerkoptimierung
DE112018006935T5 (de) Sicherheitsprofile für OCF-Vorrichtungen und vertrauenswürdige Plattformen
DE102019217367A1 (de) VERWALTUNG DER DIENSTQUALITÄT (QoS) IN EDGE-COMPUTING-UMGEBUNGEN
US10958446B2 (en) Secure wireless network association
US20220191702A1 (en) Two-phase discovery and onboarding of internet of things (iot) devices
DE112016006827T5 (de) Gruppenverwaltung in rekonfigurierbaren maschine-zu-maschine-systemen
US11763002B2 (en) Physical edge computing orchestration using vouchers and a root of trust
DE112020001814T5 (de) Privatsphärengeschützte autonome attestierung
DE112019003316T5 (de) Verteiltes berechnungsverfahren, vorrichtung und system
JP7500906B2 (ja) モノのインターネット（ＩｏＴ）デバイス用クラウドツークラウドアクセスの確立
US11310643B2 (en) Subject matching for distributed access control scenarios
DE102021210882A1 (de) Erweitertes peer-to-peer (p2p) mit edge-vernetzung
DE112020007229T5 (de) Föderiertes mec-framework für kraftfahrzeugdienste

Legal Events

Date Code Title Description
R081 Change of applicant/patentee

Owner name: INTEL CORPORATION, SANTA CLARA, US

Free format text: FORMER OWNER: INTEL CORPORATION, SANTA CLARA, CALIF., US

R082 Change of representative

Representative=s name: MAIWALD PATENTANWALTS- UND RECHTSANWALTSGESELL, DE