DE102019103927A1 - Systeme und Verfahren zur Ausführung eines Sicherheitsprotokolls in einem durch hierarchische Zustandsautomaten gesteuerten Ausführungsplan - Google Patents

Systeme und Verfahren zur Ausführung eines Sicherheitsprotokolls in einem durch hierarchische Zustandsautomaten gesteuerten Ausführungsplan Download PDF

Info

Publication number
DE102019103927A1
DE102019103927A1 DE102019103927.4A DE102019103927A DE102019103927A1 DE 102019103927 A1 DE102019103927 A1 DE 102019103927A1 DE 102019103927 A DE102019103927 A DE 102019103927A DE 102019103927 A1 DE102019103927 A1 DE 102019103927A1
Authority
DE
Germany
Prior art keywords
state
execution plan
security
execution
behavior
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
DE102019103927.4A
Other languages
English (en)
Inventor
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 DE102019103927A1 publication Critical patent/DE102019103927A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/535—Tracking the activity of the user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/562—Brokering proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • 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/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

Verfahren, Einrichtungen, Systeme und Erzeugnisse werden offenbart, um einen Informationsaustausch mittels Publish-Subscribe mit Blockchain zu ermöglichen. Eine beispielhafte Einrichtung weist einen Sicherheitsmanager auf, um einen Sicherheitsdienst mit einem Befehlsausführungsfluss in einer verteilten Vorrichtungsumgebung zu integrieren. Der Sicherheitsmanager weist einen Prozessor auf. Der Prozessor ist dafür ausgelegt, wenigstens einen ausführbaren hierarchischen Zustandsautomaten zum Bereitstellen einer Berechtigungsnachweisverwaltung und Zugangsverwaltung in Verbindung mit einer Befehlsausführung gemäß einem Ausführungsplan zu implementieren. Der ausführbare hierarchische Zustandsautomat erzeugt einen Sicherheitskontext für den Ausführungsplan, um eine Schutzbedingung zu implementieren, die einen Übergang von einem ersten Zustand in einen zweiten Zustand gemäß dem Ausführungsplan regelt.

Description

  • GEBIET DER ERFINDUNG
  • Die vorliegende Offenbarung betrifft allgemein die Ausführung von Sicherheitsprotokollen und insbesondere Systeme und Verfahren zur Ausführung eines Sicherheitsprotokolls in einem durch hierarchische Zustandsautomaten gesteuerten Ausführungsplan.
  • HINTERGRUND DER ERFINDUNG
  • Das Internet der Dinge (Internet of Things, IoT) ist ein Netz von Vorrichtungen, die Elektronik, Software, Sensoren und Netzkonnektivität beinhalten, um Daten zu sammeln und auszutauschen. IoT-fähige Vorrichtungen kommunizieren über ein Protokoll, etwa den SOAP (Simple Object Access Protocol)-Dienst, den WDSL (Web Services Description Language)-Dienst, den REST oder RESTful (Representational State Transfer)-Dienst usw. Beispielsweise basieren RESTful-IoT-Frameworks, etwa ein Open-Connectivity-Framework (OCF) usw., auf einem Nachrichtenübermittlungsprotokoll wie etwa dem CRUDN (Create, Retrieve, Update, Delete, and Notify)-Nachrichtenübermittlungsprotokoll für die Kommunikation zwischen IoT-Vorrichtungen. Durch die Verwendung eines Nachrichtenübermittlungsprotokolls kann die Ausführung einer Folge von Befehlen abgestimmt werden (was z. B. als Ausführungsplan bezeichnet wird). Allerdings unterstützen CRUDN und andere Nachrichtenübermittlungsprotokolle die sichere und autonome IoT-Ausführungsplanung nicht. Daher können Sicherheitsprotokolle, die mittels einer herkömmlichen IoT-Infrastruktur implementiert sind, als unsicher angesehen werden.
  • IoT-Vorrichtungen sind physische Objekte, die in einem Netz kommunizieren können, und können Sensoren, Betätigungselemente und andere Eingangs/AusgangsKomponenten beinhalten, um etwa aus einer realen Umgebung Daten zu erfassen oder Aktionen auszuführen. Beispielsweise können IoT-Vorrichtungen Niedrigenergie-Vorrichtungen beinhalten, die in alltäglichen Dingen eingebettet oder daran angebracht sind, etwa Gebäude, Fahrzeuge, Verpackungen usw., um eine zusätzliche Ebene künstlicher, sensorischer Wahrnehmung dieser Dinge bereitzustellen. In neuerer Zeit finden IoT-Vorrichtungen zunehmend Verbreitung, daher haben sich Anwendungsgebiete mit Einsatz solcher Vorrichtungen stark vermehrt.
  • Verschiedene Standards wurden vorgeschlagen, um IoT-Vorrichtungen und Anwendungsfälle im IoT-Netz effizienter zu verknüpfen und zu betreiben. Hierzu zählen die Spezialisierung von Kommunikationsstandards, wie sie von bestimmten Gruppen wie dem Institute of Electrical and Electronics Engineers (IEEE) verbreitet werden, und die Spezialisierung von Standards für Anwendungsinteraktionsarchitekturen und Konfiguration, wie sie von Gruppierungen wie OCF verbreitet werden.
  • Figurenliste
    • 1 zeigt ein Beispiel der geschachtelten Zustände für einen hierarchischen Zustandsautomaten.
    • 2 veranschaulicht ein Kern-Framework, das eine Verarbeitungs- und Technologieinfrastruktur bereitstellt, um Kommunikation von Vorrichtungen in einer Umgebung mit „Internet of Things“-Vorrichtungen zu ermöglichen.
    • 3 veranschaulicht eine beispielhafte Implementierung des Sicherheitsmanagers von 2.
    • 4 stellt einen beispielhaften hierarchischen Zustandsautomaten für eine beispielhafte Systemanwendung dar.
    • 5 veranschaulicht einen beispielhaften Ausführungsplan, der durch Zustände und Zustandsübergänge in einem hierarchischen Zustandsautomaten definiert ist.
    • 6 veranschaulicht einen beispielhaften Ausführungsplan eines hierarchischen Zustandsautomaten mit sicherheitsspezifischen Flüssen.
    • 7 stellt den beispielhaften Sicherheitsmanager von 2 dar, implementiert als ausführbarer hierarchischer Zustandsautomat.
    • 8-9 zeigen Flussdiagramme, die für beispielhafte maschinenlesbare Befehle repräsentativ sind, welche ausgeführt werden können, um die beispielhaften Systeme von 1-7 zu implementieren.
    • 10-11 sind schematische Darstellungen beispielhafter Prozessorplattformen, die die Befehle von 8-9 ausführen können, um die beispielhaften Systeme von 1-7 zu implementieren.
    • 12 veranschaulicht eine beispielhafte Domänentopologie für jeweilige „Internet-of-Things“ (IoT)-Netze, die über Verbindungen mit jeweiligen Netzübergängen (Gateways) gekoppelt sind.
    • 13 veranschaulicht ein Cloud-Computing-Netz in Kommunikationsverbindung mit einem Maschennetz von IoT-Vorrichtungen, das als Fog-Vorrichtung im Randbereich (Edge) eines Cloud-Computing-Netzes fungiert.
  • AUSFÜHRLICHE BESCHREIBUNG
  • In der folgenden ausführlichen Beschreibung wird auf die beigefügten Zeichnungen Bezug genommen, die Bestandteil der Beschreibung sind und in denen zur Veranschaulichung spezielle Beispiele gezeigt werden, die realisiert werden können. Diese Beispiele werden ausreichend detailliert beschrieben, um einen Fachmann in die Lage zu versetzen, den Erfindungsgegenstand in die Praxis umzusetzen, und es versteht sich, dass weitere Beispiele verwendet werden können und dass logische, mechanische, elektrische und/oder andere Änderungen vorgenommen werden können, ohne den Schutzbereich des Erfindungsgegenstandes der vorliegenden Offenbarung zu verlassen. Die nachstehende ausführliche Beschreibung wird daher bereitgestellt, um beispielhafte Implementierungen zu beschreiben, und ist nicht als Einschränkung des Schutzbereichs des Erfindungsgegenstandes, wie er in der vorliegenden Offenbarung beschrieben wird, zu verstehen. Bestimmte Merkmale verschiedener Aspekte der folgenden Beschreibung können kombiniert werden, um noch weitere neue Aspekte des nachstehend erörterten Erfindungsgegenstandes zu bilden.
  • Bei der Vorstellung von Elementen verschiedener Ausführungsformen der vorliegenden Erfindung werden die Wörter „ein“, „eine“ und „der/die/das“ in der Bedeutung verwendet, dass die Elemente einmal oder mehrmals vorhanden sind. Die Formulierungen „umfassend“, „beinhaltend“ und „mit“ sind inklusiv zu verstehen und bedeuten, dass es neben den aufgeführten Elementen noch weitere Elemente geben kann.
  • IoT-fähige Vorrichtungen kommunizieren über ein Protokoll, etwa SOAP, WDSL, REST (auch mit RESTful bezeichnet) usw. Beispielsweise basieren RESTful-IoT-Frameworks, etwa OCF usw., auf einem Nachrichtenübermittlungsprotokoll wie dem CRUDN-Nachrichtenübermittlungsprotokoll, um zwischen IoT-Vorrichtungen zu kommunizieren. Durch die Verwendung eines Nachrichtenübermittlungsprotokolls kann ein Ausführungsplan zusammengestellt werden. Herkömmliche Nachrichtenübermittlungsprotokolle, etwa CRUDN usw., unterstützen jedoch die sichere und autonome IoT-Ausführungsplanung nicht. Daher können Sicherheitsprotokolle, die mittels einer herkömmlichen IoT-Infrastruktur nach dem bisherigen Stand der Technik implementiert sind, als unsicher angesehen werden.
  • Industrielle IoT-Protokolle, etwa DDS (Data Distribution Service, Datenverteildienst) usw., unterstützen die Primitive PUBLISH (Veröffentlichen) und SUBSCRIBE (Abonnieren) (z. B. Programmiersprachenobjekte oder Codesegmente), die über gemakelte oder maklerlose IoT-Modelle arbeiten (auch als Distributed Pub-Sub oder Distributed Publish-Subscribe bezeichnet). Allerdings befasst sich eine Publish-Subscribe-Infrastruktur üblicherweise nicht mit sicherer und autonomer Ausführung. Versuche nach dem Stand der Technik mit Sicherheitsprotokollen, die mittels einer IoT-Infrastruktur implementiert sind, sind unsicher.
  • Ein Problem bei den Lösungsansätzen nach dem Stand der Technik ist die direktionale Sicherheit von Ende zu Ende. Ein sicherer Pfad für die Registrierung ist unidirektional, da die von einem Abonnenten (Subscriber) zum Abonnieren verwendeten Berechtigungsnachweise von den Berechtigungsnachweisen verschieden sind, die von einem Veröffentlicher (Publisher) zum Veröffentlichen (an den Abonnenten) verwendet werden. Somit kann sich, auch wenn ein Publish-Subscribe-Modell sowohl Veröffentlicher- als auch Abonnenten-Entitäten beinhaltet, die Semantik des öffentlichen Zugangs von der Semantik des Abonnierens unterscheiden.
  • Darüber hinaus impliziert asynchrone Veröffentlichung, dass Abonnenten nie direkt mit dem Veröffentlicher kommunizieren können. Stattdessen kann der Nachrichtenverkehr von einem oder mehreren Maklern oder Mittlern vermittelt werden. Beim verteilten Veröffentlichen-Abonnieren (Distributed Publish-Subscribe) können Benachrichtigungen rundgesendet oder nur an alle teilnehmenden Endpunkte geleitet werden, um basierend auf einem Profil gefiltert zu werden, um nur solche Themen (Topics) zu identifizieren, die einen bestimmten Abonnenten interessieren. Voraussetzungs-Sicherheitsflüsse können ebenfalls auf einem Publish-Subscribe-Benachrichtigungssystem basieren, jedoch können Filter das Vorhandensein von Voraussetzungen hinsichtlich Sicherheit oder Fähigkeiten ignorieren, was zu einer Verweigerung des Dienstes (Denial-of-Service) oder der Wiederverwendung abgelaufener Sicherheitskontextinformationen durch eine abonnierende Vorrichtung führen kann.
  • Ferner kann ein Sicherheitskontext, der zum Authentifizieren des Abonnenten gegenüber dem Veröffentlicher (oder Makler) verwendet wird, zwischen einem Zeitpunkt der Registrierung eines Abonnenten und (einer) nachfolgenden Veröffentlichung(en) ablaufen. Das Ablaufen des Sicherheitskontextes führt dazu, dass der Veröffentlicher (oder Makler) nicht in der Lage ist, Inhalt sicher zuzustellen.
  • Eine weitere Komplikation besteht, wenn ein Veröffentlicher versucht, eine Nachricht an (einen) Abonnenten zuzustellen, wo die Zugangsrichtlinien nicht aktualisiert wurden, um die Zustellung der Nachricht zuzulassen. Somit kann eine Nachricht verloren gehen, zurückgewiesen werden und/oder anderweitig unvollständig sein, bedingt durch die nicht mehr aktuelle oder abgelaufene Zugangs-/Sicherheitsrichtlinie.
  • Darüber hinaus können mehrere Veröffentlichungen mit demselben Thema verknüpft sein. Dasselbe Thema kann implizieren, dass ein gleicher Sicherheitskontext (z. B. Berechtigungsnachweise und Zugangsrichtlinien usw.) bei einem angemessenen Granularitäsniveau auf die mehreren Veröffentlichungen zur Anwendung kommt. Allerdings kann dies nicht für alle Konfigurationen zutreffen, und fehlerhafte Annahmen können zu einer unvollständigen und/oder anderweitig ungeeigneten Ausführung eines Ausführungsplans führen.
  • Für sich genommen gehen vorhandene Lösungen wie OCF, DDS usw. über direktionale Sicherheitssemantik hinweg. Das bedeutet, dass Zugangsregeln, die dafür vorgesehen sind, eine Abonnementregistrierung zu kontrollieren, nicht geeignet sind, um Interaktionen einer Veröffentlichung, die auf eine Registrierung folgen, zu regeln. Durch Verwendung von OCF, DDS usw. ist ein Server nicht mit Zugangskontrolllisten (Access Control Lists, ACL), Rollen oder Berechtigungsnachweisen ausgestattet, um eine Rollenumkehr des Servers in der Funktion als Client zu unterstützen, um eine Nachricht an den Client zu senden, der als Server fungiert. Darüber hinaus können Sicherheitskontexte und Zugangsrichtlinien ablaufen und dazu führen, dass Zugang gewährt wird, der die Gefahr einer Rechteausweitung erhöht, und/oder Zugang verweigert wird, was zu einer unbeabsichtigten Verweigerung des Dienstes führt.
  • Virtuelle private Netze (VPN) sind zu allgemein (sie haben z. B. eine grobe Granularität) und bieten Sicherheit auf Vorrichtungsebene statt auf Themen- oder Nachrichtenebene. Ferner sind VPN nicht sicher von Ende zu Ende. Beispielsweise entsteht durch den Einsatz von Maklern eine nicht beabsichtigte Notwendigkeit von „vertrauenswürdigen“ Maklern.
  • Einschätzungen von Sicherheitsschwachstellen müssen derzeit diese Lücken in der Abdeckungsanalyse übersehen, was eine Möglichkeit für Angriffe offen lässt, so dass Knoten unberechtigt Nachrichten zustellen oder wiedergeben.
  • Bestimmte Beispiele lösen diese Probleme, Anforderungen und Mängel bei Lösungsansätzen nach dem bisherigen Stand der Technik, indem sie einen oder mehrere ausführbare hierarchische Zustandsautomaten (Hierarchical State Machine, HSM) mit integrierter Sicherheit bereitstellen. In bestimmten hier beschriebenen Beispielen weist ein HSM-gesteuerter Ausführungsplan integrierte Sicherheitsprotokolle auf, die Schutzbedingungen für den Eintritt in Zustände im HSM bzw. das Verlassen derselben bereitstellen. Die Integration eines Sicherheitsprotokolls als Ausdruck eines HSM mit einer bestehenden HSM-Anwendung erzeugt einen HSM-Ausführungsplan, der unzweideutig sicherheitsbezogene Zustände im Kontext von Anwendungszuständen beschreibt, derart, dass das Eintreten in Sicherheits- und Anwendungszustände bzw. das Verlassen derselben in einer korrekten Reihenfolge erfolgen.
  • In bestimmten Beispielen kann, wenn Kontextinformationen, etwa der Sicherheitskontext, ablaufen (z. B. veralten), ein Ausführungszustand auf einen vorherigen „Gut“-Zustand (z. B. einen vorherigen sicheren Zustand) zurückzusetzen. Ohne Rücksetz (Rollback)-Semantik können abgelaufene Sicherheitskontexte von einem Angreifer ausgenutzt werden. Mit Rücksetzsemantik werden abgelaufene Sicherheitskontexte aufgelöst und automatisch entfernt, da sie zwischen zwei Zuständen in einer serialisierten Zustandsautomat-Darstellung existieren.
  • In einer RESTful-Architektur wird die Client-Server-Interaktion mittels ressourcenbasierter Operationen gesteuert, in denen eine Vorrichtung als Ressource dargestellt ist und CRUDN-Operationen verwendet werden, um die Ressourcen zu bearbeiten. Somit können eine Anforderung von einem Client an einen Server und eine Antwort vom Server zurück an den Client mithilfe einer oder mehrerer Erzeugen-, Abrufen-, Aktualisieren-, Löschen- und/oder Benachrichtigen-Nachrichten gebildet werden.
  • In einem beispielhaften CRUDN-gesteuerten System ist ein Endpunkt Quelle oder Ziel einer Anforderungs- bzw. Antwortnachricht für eine gegebene Transportprotokollsammlung. Jede Vorrichtung ist mit wenigstens einem Endpunkt verknüpft, mit dem die Vorrichtung Anforderungs- und Antwortnachrichten austauschen kann. Datenstrukturen werden verwendet, um Ressourcen und Vorrichtungen, die aus den Ressourcen gebildet sind, zu beschreiben. Definitionen beschreiben die Zuordnung zwischen Vorrichtungen in einem oder mehreren Systemen (z. B. mehreren RESTful-Systemen usw.). In bestimmten Beispielen unterliegt eine Anforderung an einen Server einer ACL-Richtlinienprüfung (z. B. themenbasierte Zugangskontrolle, rollenbasierte Zugangskontrolle usw.), um die Berechtigung zum Lese- und/oder Schreibzugriff zu überprüfen. Mit dieser Berechtigung können Operationen wie Holen/Beobachten (Get/Observe), postieren (Post), Setzen (Put), Löschen (Delete) usw. auf Ressourcen angewandt werden.
  • Somit kann bei Verwendung eines CRUDN-Ansatzes ein Interaktionsmodell erstellt werden, um einer Vorrichtung, einem Prozess oder einer anderen Ressource usw. zu ermöglichen, eine neue Ressource auf einem Server im System zu erzeugen. Zum Abrufen wird ein aktueller Zustand oder eine Darstellung einer Ressource von einem Server erfasst. Zum Aktualisieren wird eine teilweise oder vollständige Aktualisierung für in einer Ressource gespeicherte Informationen angefordert. Löschen entfernt eine Ressource vom Server. Benachrichtigen fordert eine asynchrone Benachrichtigung über Zustandsänderungen in einer Ressource an.
  • Während RESTful-Systeme zustandslose Systeme sind, verbessern hier beschriebene Beispiele die RESTful-Systemtechnologie, indem ein Zustandsautomat auf die RESTful-Architektur angewandt wird. In bestimmten Beispielen ist der Zustandsautomat ein hierarchischer Zustandsautomat (HSM). Ein beispielhafter HSM bindet Antworten an Ereignisse wie von einer Art des Ereignisses und eines Systemkontextes abhängig. Im Zustandsautomaten bezeichnen Knoten Zustände, und Verbinder zwischen Knoten bezeichnen Übergänge zwischen Knoten.
  • Ein beispielhafter HSM kann hierarchisch geschachtelte Zustände aufweisen. Beispielsweise ist, wie in 1 gezeigt, wenn ein System in einem geschachtelten Zustand s11 (auch als Unterzustand bezeichnet) ist, das System auch in einem umgebenden Zustand s1 (auch als Superzustand bezeichnet). Ereignisse werden gemäß dem Unterzustand s11 sowie dem Superzustand s1 behandelt. In bestimmten Beispielen definieren Unterzustände nur (einen) Unterschied(e) zum Superzustand. Somit wird beispielsweise ein Ereignis zunächst im Kontext von Unterzustand s11 behandelt, und danach werden nicht behandelte Ereignisse gemäß Superzustand s1 verarbeitet.
  • In einem reaktiven System wird ein Muster identifiziert, um Ereignisse in einer bestimmten Art und Weise zu verarbeiten. In bestimmten Beispielen verknüpft ein ereignisgesteuertes System Anforderungen und Antworten mit Ereignissen. Ereignisse sind mit Zuständen im HSM verknüpft.
  • Bestimmte hier beschriebene Beispiele integrieren Nachrichtenflüsse der Sicherheitsrichtlinienverwaltung mit normalen Betriebsflüssen. In bestimmten Beispielen werden Sicherheitsverwaltungsflüsse zu Voraussetzungsflüssen für normale Betriebsflüsse. In bestimmten Beispielen stellt Registrierungskontext dynamisch Zugangsberechtigungen und Zugangsrichtlinien bereit. Wenn das normale System als hierarchischer Zustandsautomat ausgedrückt ist, werden Sicherheitsflüsse zu Schutzbedingungen, die für den Eintritt in einen Zustand und das Verlassen desselben im HSM gelten.
  • In bestimmten Beispielen kann die Bereitstellung von Zugangsrichtlinien und Berechtigungsnachweisen leichter integriert und automatisiert werden. In bestimmten Beispielen kann ein Mindestrecht, das benötigt wird, um die Aufgabe zu erfüllen, zur Anwendung kommen. In bestimmten Beispielen sind die Durchsetzung von Zugangsrichtlinien und die Verwendung von Berechtigungsnachweisen zeitnah (z. B. aktuell), was die Wahrscheinlichkeit von Sicherheitsverstößen verringert. Als HSM sind Sicherheitsflüsse ebenso sicher wie Betriebsflüsse, was eine effektive Art und Weise darstellt, Betriebssicherheits- und Betriebsschutzanforderungen zu integrieren und abzustimmen.
  • Wie im Beispiel von 2 gezeigt, stellt ein Kern-Framework 200 Verarbeitungs- und Technologieinfrastruktur bereit, um die Kommunikation von Vorrichtungen einschließlich Publish-Subscribe-Austausch usw. in einer IoT-Vorrichtungsumgebung zu ermöglichen. Das beispielhafte Framework 200 weist einen Prozessor 202 und eine Speichervorrichtung 204 auf. Der beispielhafte Prozessor 202 weist einen Adressierer 206 auf, der Entitäten identifiziert und adressiert, die mit dem Framework 200 kommunizieren, einschließlich Vorrichtungen, Clients, Server, Ressourcen usw. Eine Protokollbrücke oder ein Netzübergang 208 weist eine Brückenspezifikation auf, die eine Übersetzung zwischen Vorrichtungen spezifiziert, etwa eine Übersetzung zwischen Protokollen usw. (z. B. AllJoyn zu OCF usw.). Ein „Common Resource“-Modell 210 definiert reale Entitäten als Datenmodelle, die Ressourcen darstellen. Eine Anforderung/Antwort-Steuereinheit 212 ermöglicht Anforderungen und Antworten zwischen Ressourcen unter Verwendung von CRUDN-Befehlen (Create, Retrieve, Update, Delete, and Notify - Erzeugen, Abrufen, Aktualisieren, Löschen und Benachrichtigen) usw. Eine Vorrichtungsentdeckungseinheit 214 identifiziert Vorrichtungen, die in Kommunikationsverbindung mit dem Kern-Framework 200 stehen. Ein Nachrichtenübermittler 216 stellt eingeschränkte Unterstützung von Vorrichtungen für Kommunikation (z. B. Constrained Application Protocol (CoAP), Hypertext Transfer Protocol (HTTP) usw.) sowie Protokollübersetzung beispielsweise mittels der Protokollbrücke 208 bereit. Ein Vorrichtungsmanager 218 koordiniert Vorrichtungen (z. B. Clients, Server, andere Ressourcen, andere Vorrichtungen usw.), die in Kommunikationsverbindung mit dem Kern-Framework 200 stehen. Die Speichervorrichtung 204 kann Befehle und Daten speichern, um Operationsaustausch und Kommunikation zwischen Vorrichtungen (z. B. IoT-Vorrichtungen usw.) über das Framework 200 zu ermöglichen.
  • Eine Konnektivitätsschnittstelle 220 stellt einen Mechanismus bereit, durch den Datenkommunikation, etwa Schicht-2 (Layer-2, L2) und/oder Schicht-3 (Layer-3, L3) -Konnektivität, Vernetzung, Datentransport usw. mit dem Kern-Framework 200 ermöglicht werden. Beispielsweise wird Datentransport wie Erfassung und Verteilung von Informationen an eine oder mehrere Vorrichtungen, die mit dem Framework 200 verbunden sind, über die Konnektivitätsschnittstelle 220 ermöglicht.
  • Ein Sicherheitsmanager 222 weist einen Mechanismus auf, um ein oder mehrere Sicherheitsprotokolle auf Kommunikation anzuwenden, die beim Kern-Framework 200 ankommt bzw. von diesem ausgeht, einschließlich Publish-Subscribe-Kommunikation zwischen Ressourcen in einem IoT-System. Wie im Beispiel von 3 gezeigt, kann der Sicherheitsmanager 222 derart implementiert sein, dass er einen Prozessor 302 und einen Datenspeicher 304 aufweist. Der Prozessor 302 kann einen Berechtigungsnachweis-Verwaltungsdienst (Credential Management Service, CMS) 306 und einen Zugangsverwaltungsdienst (Access Management Service, AMS) 308 aufweisen. Der CMS 306 und der AMS 308 wirken zusammen, um einen Sicherheitskontext zu erstellen, in dem eine Ressource authentifiziert und der Zugang der Ressource zu Infrastruktur, Kommunikation (z. B. Pub-Sub usw.), (einer) anderen Ressource(n) usw. bestimmt werden sollen. Der Sicherheitskontext kann an einen zustandsbasierten Befehlsausführungsfluss bereitgestellt und/oder anderweitig mit diesem integriert werden, beispielsweise über die Anforderung/Antwort-Steuereinheit 212, den Nachrichtenübermittler 216, den Vorrichtungsmanager 218 und/oder andere Komponenten des Prozessors 202 von Framework 200.
  • Die Speichervorrichtung 304 kann Befehle zum Implementieren und Ausführen von Sicherheitsprotokollen speichern, um Sicherheit, Zuverlässigkeit, Überprüfbarkeit usw. bei der Ausführung von Befehlen und der Kommunikation zwischen Vorrichtungen (z. B. IoT-Vorrichtungen usw.) über das Framework 200 sicherstellen zu helfen.
  • Der Sicherheitsmanager 222 integriert Nachrichtenflüsse der Sicherheitsrichtlinienverwaltung mit normalen Betriebsflüssen durch das Framework 200 beispielsweise im Hinblick auf eine oder mehrere verbindende Vorrichtungen/Ressourcen. In bestimmten Beispielen werden Sicherheitsverwaltungsflüsse zu Voraussetzungsflüssen für normale Betriebsflüsse. Ein Registrierungskontext stellt dynamisch Zugangsberechtigungen und Zugangsrichtlinien bereit. In bestimmten Beispielen ist der normale Systembetrieb als hierarchischer Zustandsautomat (HSM) ausgedrückt, und die zugehörigen Sicherheitsflüsse werden zu Schutzbedingungen, die zum Regeln des Eintretens in einen im HSM definierten Zustand und des Verlassens desselben gelten.
  • Durch die Verwendung von Sicherheitsflüssen als Schutzbedingungen in einem HSM können eine Zugangsrichtlinie vom ASM 308 und die Bereitstellung von Berechtigungsnachweisen durch den CSM 306 einfacher in den HSM-Verwaltungsfluss integriert und automatisiert werden. Durch die Verwendung von Schutzbedingungen kann eine niedrigste erforderliche Rechteebene angewandt werden, die für die Ausführung einer bestimmten Aufgabe benötigt wird. Die Durchsetzung von Zugangsrichtlinien durch den ASM 308 und die Verwendung von Berechtigungsnachweisen, die vom CSM 306 reguliert wird, sind zeitnah (aktuell), was die Wahrscheinlichkeit von Sicherheitsverstößen verringert. Im HSM sind Sicherheitsflüsse derart implementiert, dass sie ebenso sicher sind wie Betriebsanweisungen und Datenflüsse, mit integrierten Abstimmungen auf Basis von Betriebssicherheits- und Betriebsschutzanforderungen.
  • Während eine beispielhafte Implementierung des Sicherheitsmanagers 222 von 2 in 3 dargestellt ist, können eines oder mehrere der Elemente, Prozesse und/oder Vorrichtungen wie in 3 dargestellt kombiniert, unterteilt, neu angeordnet, weggelassen, entfernt und/oder in beliebiger anderer Weise implementiert werden. Ferner können der beispielhafte Prozessor 302, der beispielhafte Datenspeicher 304, der beispielhafte Berechtigungsnachweis-Verwaltungsdienst 306, der beispielhafte Zugangsverwaltungsdienst 308 und/oder, allgemeiner, der beispielhafte Sicherheitsmanager 222 von 3 durch Hardware, Software, Firmware und/oder eine beliebige Kombination von Hardware, Software und/oder Firmware implementiert sein. So könnte beispielsweise ein beliebiger beispielhafter Prozessor 302, beispielhafter Datenspeicher 304, beispielhafter Berechtigungsnachweis-Verwaltungsdienst 306, beispielhafter Zugangsverwaltungsdienst 308 und/oder, allgemeiner, beispielhafter Sicherheitsmanager 222 von 3 mithilfe von ein oder mehreren analogen oder digitalen Schaltung(en), Logikschaltungen, programmierbaren Prozessor(en), anwendungsspezifischen integrierten Schaltung(en) (ASIC(s)), programmierbaren Logikbaustein(en) (Programmable Logic Device(s), PLD(s)) und/oder feldprogrammierbaren Logikbaustein(en) (Field Programmable Logic Device(s), FPLD(s)) implementiert sein. Wenn beliebige der Vorrichtungs- oder Systemansprüche der vorliegenden Patentanmeldung im Hinblick auf eine reine Software- und/oder Firmware-Implementierung gelesen werden, wird hiermit ausdrücklich definiert, dass der beispielhafte Prozessor 302, der beispielhafte Datenspeicher 304, der beispielhafte Berechtigungsnachweis-Verwaltungsdienst 306, der beispielhafte Zugangsverwaltungsdienst 308 und/oder, allgemeiner, der beispielhafte Sicherheitsmanager 222 von 3 eine nichttransitorische, computerlesbare Speichervorrichtung oder Speicherplatte wie etwa einen Speicher, eine Digital Versatile Disk (DVD), eine Compact Disk (CD), eine Blu-Ray Disk etc. aufweisen, welche die Software und/oder die Firmware beinhaltet. Noch ferner kann der beispielhafte Sicherheitsmanager 222 von 3 ein oder mehrere Elemente, Prozesse und/oder Vorrichtungen zusätzlich zu oder anstelle der in 3 dargestellten beinhalten und/oder kann mehr als ein beliebiges der oder alle dargestellten Elemente, Prozesse und Vorrichtungen aufweisen.
  • Ein sicherheitsfähiger HSM kann auf einen Publish-Subscribe (Veröffentlichen-Abonnieren)-Nachrichtenfluss angewandt werden, um beispielsweise die Ausführung von Befehlen, den Datenzugriff und zugehörige Schutzmaßnahmen in einem IoT-Ausführungsplan zu regeln. In bestimmten Beispielen weist eine „Registrierungs“-Nachricht (auch mit SUBSCRIBE=Abonnieren bezeichnet) zusätzlichen Kontext auf, der beschreibt, wie sicher eine Verbindung zurück zum Registrierenden und/oder beabsichtigten Empfänger(n) ist (z. B. zu dem Zeitpunkt, an dem asynchrone Nachrichten sendebereit sind). Der Registrierende/Abonnent liefert zusätzliche Daten, etwa: 1) eine Vorrichtungskennung (ID), die mit dem/den Empfänger(n) verknüpft ist; 2) (einen) Vertrauensursprung (Trust Anchor) für Berechtigungsnachweise, die von dem/den Empfänger(n) verwendet werden, um Verbindungsanforderungen zu validieren; und 3) eine Bestätigung der Vorrichtungs-ID, die eine Registrierstelle/ein Veröffentlicher verwenden soll, wenn eine asynchrone Antwort versucht wird. Darüber hinaus können ein Name einer registrierenden Ressource, der aktualisiert wird, wenn die asynchrone Antwort gesendet wird, und ein Name einer Ressourcenschnittstelle, die verwendet werden soll, wenn die asynchrone Antwort gesendet wird, bereitgestellt werden, zusammen mit einer Rolle, die die Registrierstelle einnehmen soll, wenn die asynchrone Antwort gesendet wird. Der Registrierende kann auch eine Bestätigung des vertrauenswürdigen Autorisierungsdienstes/-anbieters der ACL-Richtlinie der Registrierstelle bereitstellen. Der Registrierende identifiziert die Benachrichtigungsnachrichten und/oder Bloom-Filter, die zur Durchführung der Voraussetzungs-Sicherheitskonfiguration verwendet wurde. Das Definieren des Nachrichtensystems als HSM erlaubt die Identifikation der Zustandsautomat-Schutzbedingungen, die erwartet werden, beispielsweise für (einen) gebundene(n) verfügbare(n) Datenzugangszustand (-zustände).
  • Eine Registrierstelle oder ein Veröffentlicher kann zusätzliche Aufgaben ausführen, einschließlich: 1) Erhalten eines Berechtigungsnachweises, der sich selbst für den/die Empfänger authentifiziert; 2) Erhalten eines Rollenautorisierungs-Berechtigungsnachweises für eine Rolle, die am Datenzugang beteiligt ist; und 3) Erhalten der Bereitstellung eines Zugangskontrolllisteneintrags, der der Registrierstelle Aktualisieren (UPDATE)-Zugang zu der bezeichneten Ressource des Registrierenden gewährt. Die Registrierstelle kann eine Verbindung zu dem oder den Empfänger(n) öffnen und Berechtigungsnachweise, Berechtigungen und Zugangsvoraussetzungen bereitstellen, um beispielsweise auf Daten und/oder anderen Inhalt zuzugreifen. Die Registrierstelle kann dann die bezeichnete Antwortressource mit einer asynchronen Antwort aktualisieren. Das System als HSM zu definieren erlaubt beispielsweise der Registrierstelle, Zustandsautomat-Schutzbedingungen durchzusetzen.
  • Somit können durch Verwendung des Kern-Frameworks 200 eine oder mehrere IoT-Systemanwendungen als HSM ausgedrückt werden. 4 veranschaulicht einen beispielhaften HSM 400 für eine beispielhafte IoT-Systemanwendung. Übergänge zu verschiedenen Zustandsebenen spiegeln sich in den verschiedenen Darstellungsstilen (z. B. durchgehend, gestrichelt, gepunktet) der Pfeile wider, die zum Anzeigen von Zustandsänderungen in Schaltbild 400 verwendet werden. Im Beispiel von 4 zeigen durchgehende Pfeile Übergänge niedrigerer Ebenen an, gestrichelte Pfeile Übergänge höherer Ebenen und gepunktete Pfeile Übergänge höchster Ebene. Wenn ein Übergang auf einer niedrigeren Ebene erfolgt, werden eine oder mehrere Schutzbedingungen, die mit Zuständen höherer Ebene verknüpft sind, zusätzlich zu der/den Schutzbedingung(en) für den Zustand/die Zustände der niedrigsten Ebene angewandt. Auch wenn die dargestellten Pfeile im Beispiel von 4 lediglich in eine bestimmte Richtung weisen, impliziert das HSM-Schaltbild von 4 auch Übergänge und Anwendung von Schutzbedingungen in umgekehrter Richtung.
  • Beispielsweise ist bezogen auf HSM 400 Zustand Z ein Superzustand zu Zustand Y und X. Während Y ein Unterzustand von Zustand Z ist, ist Y zugleich auch ein Superzustand zu den Zuständen d, e und f. Ähnlich ist, während X ein Unterzustand von Zustand Z ist, X gleichzeitig ein Superzustand der Zustände g, h und i. Zustand W ist ein Superzustand zu den Unterzuständen b und c, und Zustand a ist ein weiterer Zustand im beispielhaften HSM 400. Im beispielhaften HSM 400 sind die Übergänge zwischen den Unterzuständen d, e und f in den Superzustand W Übergänge niedrigerer Ebene, die den Schutzbedingungen von Superzustand W und dessen Superzustand Z sowie den Schutzbedingungen für Unterzustände d, e und/oder f unterliegen. Ähnlich sind Übergänge zwischen den Unterzuständen g, h und i Übergänge niedrigerer Ebene, die beispielsweise den Schutzbedingungen von Superzustand X und dessen Superzustand Z sowie den Schutzbedingungen für Unterzustände g, h und/oder i unterliegen. Ein Übergang von Superzustand Y zu Unterzustand g ist ein Übergang höherer Ebene, unterliegt jedoch auch den Schutzbedingungen für die höchste Ebene Z. Beispielsweise unterliegen Übergänge zwischen den Zuständen b und c den mit ihnen verknüpften Schutzbedingungen ebenso wie den Schutzbedingungen, die mit ihrem Superzustand W verknüpft sind. Ein dargestellter Übergang zwischen den Zuständen e und c unterliegt Schutzbedingungen, die mit den Zuständen e und c verknüpft sind, ebenso wie Schutzbedingungen, die mit den Superzuständen W, Y und Z verknüpft sind. Ein Übergang zwischen den Zuständen Y und b unterliegt Schutzbedingungen, die mit den Zuständen Y, b, W und Z verknüpft sind. Ein Übergang zwischen den Zuständen X und c unterliegt Schutzbedingungen, die mit den Zuständen X, c, W und Z verknüpft sind. Ein Übergang zwischen den Zuständen W und a unterliegt Schutzbedingungen, die mit den Zuständen W und a verknüpft sind. Ein Übergang zwischen den Zuständen Z und a unterliegt beispielsweise Schutzbedingungen, die mit den Zuständen Z und a verknüpft sind. Atomarität von Zuständen und zugehörigen Übergängen kann gewährleistet werden durch Verwendung von Datei- und Prozesssperrmechanismen wie Dateisperren, Datensatzsperren, Advisory-Sperren, Shared-Memory-Sperren, Spin-Sperren, gegenseitigen Ausschlüssen (Mutex) usw.
  • Somit stellt 4 ein Beispiel sicherer Ausführungsplanung gemäß HSM 400 dar. Das Zuordnen eines Plans zur Befehlsausführung in den HSM 400 und Konstruieren des HSM 400 als ein oder mehrere hierarchische Zustandsautomaten stellt eine technologische Innovation im Bereich der verteilten Datenverarbeitung und zugehöriger ausführbarer Umgebung(en) dar.
  • 5 zeigt Zustände und Zustandsübergänge von einem HSM im Kontext eines IoT-Systemausführungsplans 500. Somit zeigt der beispielhafte Ausführungsplan 500 integrierte Zustandsübergänge, und die spezifizierten integrierten Zustandsübergänge werden als „sicher“ angesehen, da Datenmodifikationen, die aus einem Ausgangsfluss resultieren, atomisch sind. Das bedeutet, dass Datenmodifikationen im HSM-Ausführungsplan 500 in nur einem einzigen Schritt abgeschlossen werden (atomisch sind). Schutzbedingungen, die als Teil der HSM-Zustandsübergänge spezifiziert sind, werden als „kritischer Abschnitt“ verarbeitet, in dem die Ordnung gemäß der in der HSM-Darstellung spezifizierten Sequenzierung beibehalten wird.
  • In bestimmten Beispielen kann der HSM-Ausführungsplan 500 mittels eines Publish-Subscribe-Modells implementiert werden, indem Datenobjekte als Veröffentlicher und Verhaltensblöcke sowohl als Abonnenten als auch als Veröffentlicher klassifiziert werden. Eingangs-, Ausgangs- und Parameterflüsse werden als Publish-Subscribe-Themen („Topics“) bereitgestellt, die daher mithilfe einer IoT-Pub-Sub-Infrastruktur wie Robot Operating System (ROS2), DDS, MQ Telemetry Transport (MQTT), Extensible Messaging and Presence Protocol (XMPP) usw. implementiert werden können.
  • Der beispielhafte HSM-Ausführungsplan 500 von 5 verwendet Zustände und ordnet die Zustände in den Ausführungsplan 500 ein, basierend auf Veröffentlichern und Abonnenten. Der beispielhafte Plan 500 beinhaltet Superzustände W 502, Y 504, X 506, Z 508 und Unterzustände a 510, b 512, c 514, d 516, e 518, f 520, g 522, h 524, i 526 und j 528. Zustände a-j 510-528 entsprechen Datenobjekten 530-556. Die Datenobjekte 530-556 beziehen sich auf verschiedene Verhaltensweisen 560-566.
  • Beispielsweise stellt das Datenobjekt 530, das Zustand c 514 entspricht, Eingang für das Verhalten 560 bereit. Datenobjekt 532, das Zustand f 520 entspricht, stellt Parameter für das Verhalten 560 bereit. Datenobjekt 534, das Zustand a 510 entspricht, empfängt beispielsweise einen Ausgang von Verhalten 560 basierend auf dem Eingang und (einem) Parameter(n). Veröffentlicher 570 steuern die Datenobjekte 530-556 und Zustände 502-528 und sammeln Ausgänge von den ein oder mehreren Verhalten 560-566, und Abonnenten 572 empfangen Aktualisierungen und/oder andere Nachrichten bezüglich der ein oder mehreren Verhalten 560-566 basierend auf ihren Abonnements.
  • Wie im Beispiel von 5 gezeigt, stellen Indikatoren oder Demarkatoren 580-594 eine Angabe von Unterzuständen 510-528 bereit, die in jedem Superzustand 502-508 vorhanden sind. Beispielsweise zeigen die Indikatoren 580, 584 an, dass die Unterzustände c 514, f 520 und a 510 unter Superzustand Z 508 zusammengefasst sind. Die Indikatoren 582 und 588 zeigen an, dass die Unterzustände a 510, i 526 und d 516 in Superzustand X 506 vorhanden sind. Die Indikatoren 586 und 592 zeigen an, dass die Unterzustände i 526, d 516, h 524 und e 518 Bestandteile des Superzustands Y 504 sind. Die Indikatoren 590, 594 zeigen an, dass die Unterzustände e 518, g 522 und j 528 unter Superzustand W 502 zusammengefasst sind. Somit sind die Superzustände W-Z 502-508 jeweils Kombinationen von Publish-Subscribe-Datenflüssen gebildet aus den Unterzuständen 510-528, aus denen sie sich zusammensetzen. Jedes Paar Indikatoren 580-594 ist mit einem Verhalten 560-566 verknüpft (z. B. bilden sie seine(n) Eingang/Eingänge, Parameter und Ausgang/Ausgänge usw.).
  • Beispielsweise weist der Zustand Z 508 Zustände c 514, f 520 und a 510 als deterministische Start- und Endpunkte auf. In bestimmten Beispielen werden deterministische Start- und Endpunkte als „sicher“ betrachtet, weil sie in Datensätzen 530-556 und Verhalten 560-566 beschrieben werden können, welche in Form von definierten Eingängen und Ausgängen beschrieben werden, die durch Datenobjekte 530-556 dargestellt sind, welche Zustände 510-528 repräsentieren. Mit den bekannten, definierten Eingängen und Ausgängen kann der Sicherheitsmanager 218 garantieren, dass die Programmausführung an einem bekannten Punkt endet (z. B. Start bei Zustand i 526 und Übergang in Zustand d 316 oder Zustand 518 usw.). Die Datenobjekte 530-556 sind als Veröffentlicher 570 klassifiziert, und die Verhalten 560-566 sind sowohl als Veröffentlicher 570 als auch als Abonnenten 572 klassifiziert, um Eingangs-, Ausgangs- und Parameterflüsse beispielsweise als Publish-Subscribe-Themen zu regeln.
  • 6 veranschaulicht einen HSM-Ausführungsplan 600 mit sicherheitsspezifischen Flüssen. Der gesicherte HSM-Ausführungsplan 600 unterscheidet sich von dem beispielhaften Plan 500 dahingehend, dass der beispielhafte Fluss 600 Blöcke für Geheimtextdaten 602, 606 und Sicherheitskontext 604, 608, 610 aufweist. Beispielsweise erzeugt ein Ausgang Daten a 510 vom ersten Verhaltensblock 560 die Geheimtextdaten 602. Daten, die mit dem Zustand a 510 verknüpft sind, bilden den Eingang in den zweiten Verhaltensblock 562 und erfordern Sicherheitskontext 604 als Eingangsparameter i 526. Der Block i 526 kann beispielsweise Berechtigungsnachweise zum Entschlüsseln von a 510 und Zugangsrichtlinien bereitstellen. Der zweite Verhaltensblock 562 erzeugt beispielsweise zwei Ausgänge, sowohl Klartextdaten 550, die Zustand e 518 entsprechen, als auch Geheimtextdaten 606, die Zustand d 516 entsprechen. Zustand h 524 ist ein Sicherheitskontext 608, der Berechtigungsnachweise und Zugangsautorisierungsrichtlinien auf den dritten Verhaltensblock 564 anwendet, der Daten 550 von Zustand g 522 erzeugt und als Eingang in den vierten Verhaltensblock 566 zuführt. Der Sicherheitskontext 610 von Zustand b 512 kann beispielsweise Zugangsautorisierungsrichtlinien auf die Klartextdaten 550 (Zustand e 518) anwenden, was zur Erzeugung von Klartextdaten 556 (Zustand j 528) führt.
  • Somit wendet der Ausführungsplan 600 des Beispiels von 6 die Ausführung eines hierarchischen Zustandsautomaten auf Sicherheitsschlüsselverwaltung und/oder andere Daten und/oder Programmsicherheitstechnologie an. Die Programmausführung kann im Sinne von sicheren Daten definiert werden. Geheimtext 602, 606 und Sicherheitskontext 604, 608, 610 können herangezogen werden, um zu prüfen, ob ein bestimmtes Verhalten 560-566 für das System akzeptabel ist und zur sicheren, gültigen Ausführung und nicht zu einem Fehler oder zum Eintritt in einen Fehlerzustand führt. Somit können Kommunikation, Interaktion und/oder Ausführung anderer Befehle zwischen IoT-Vorrichtungen über den HSM-Ausführungsplan 600 gesichert werden (z. B. mit kryptografischen Datengruppen, sicheren Ausführungsmodellen usw.). Eine IoT-Anwendung, die als ausführbarer HSM instanziiert ist, kann verwendet werden, um Sicherheitsschlüsselverwaltung and Durchsetzung einer Zugangskontrollrichtlinie zu integrieren und gleichzeitig beispielsweise eine sichere Ausführungssemantik zu gewährleisten.
  • Beispielsweise muss, wenn der Eintritt in einen Anwendungszustand von der Entschlüsselung von Anwendungsdaten abhängig ist, der Entschlüsselungsschlüssel vor dem Eintreten in den Zustand bereitgestellt werden. Wenn die Anwendung die Daten erfolgreich entschlüsselt, jedoch nicht erfolgreich in den nächsten Zustand übergeht, können die Daten verloren gehen (z. B. gehen Klartextdaten bei einem Stromausfall verloren usw.). Die HSM-Schutzbedingungen erfordern das Rücksetzen auf einen vorherigen Zustand, wobei angenommen wird, dass der Anwendungszustand den Geheimtext nicht kennt und wobei beispielsweise der Klartext verschlüsselt und der Entschlüsselungsschlüssel dem Anwendungszustand erneut bereitgestellt werden muss. Wenn beispielsweise die Zustände c 514 und f 520 eintreten, jedoch der Zustand a 510 nicht, kann der Ausführungsplan zu Indikator 580 zurückkehren, um die Zustände c 514 und f 520 erneut auszuführen.
  • Somit sind Kontextstrukturen sichere Kontexte und helfen, den Systembetrieb gemäß Ausführungsplan 600 für den HSM über die Zeit aufrechtzuerhalten. Kontextstrukturen sind gegen mögliche Beschädigung durch Wettlaufsituationen („Race Conditions“) usw. geschützt, beispielsweise unter Verwendung von Sperrstrukturen. Sperrstrukturen helfen Übergänge in unbekannte Zustände zu verhindern, die beispielsweise in Mehrfaden- und Mehrkernsystemen vorkommen können. Kontextstrukturen helfen dabei, eine deterministische Schlüsselverwaltung als Bestandteil des Befehlsausführungsplanflusses zu ermöglichen, und helfen beispielsweise, unbekannte/unbestimmte Zustände zu verhindern.
  • 7 veranschaulicht eine beispielhafte Implementierung von Sicherheitsdiensten des Sicherheitsmanagers 222 ausgedrückt als ausführbarer HSM 700. Im Beispiel von 7 sind Sicherheitsdienste, die einen Berechtigungsnachweis-Verwaltungsfluss (über den Berechtigungsnachweis-Verwaltungsdienst 306) und einen Zugangsverwaltungsfluss (über den Zugangsverwaltungsdienst 308) bereitstellen, als HSM-Ausführungsplan unter Verwendung eines ausführbaren HSM-Systems 700 dargestellt. Der beispielhafte Ausführungsplan erzeugt drei Datenwerte, SC i 604, SC h 608 und SC b 610, als Ausgang, etwa zum beispielhaften Ausführungsplan 600. Datenobjekte 702-706 sind Eingänge in die ausführbare HSM-Anwendung 700 (z. B. mittels des Prozessors 302 usw. implementiert), die beispielsweise Sicherheit in den IoT-Befehlsprozessfluss integriert. Die ausgegebenen Sicherheitskontextwerte 604, 608, 610 können beispielsweise als Sicherheitskontexteingang für den HSM-Ausführungsplan 600 dienen.
  • Der Ausführungsplan 600 kann auch als ausführbarer HSM implementiert sein, um vom Prozessor 302 des Sicherheitsmanagers 222 ausgeführt zu werden. Alternativ oder zusätzlich dazu kann der Ausführungsplan 600 vom Prozessor 202 ausgeführt werden. Beispielsweise kann der Ausführungsplan 600 durch die Anforderung/Antwort-Steuereinheit 212 implementiert sein, allein oder in Verbindung mit dem Nachrichtenübermittler 216, dem Vorrichtungsmanager 218 und/oder (einer) anderen Komponente(n) des Prozessors 202, und erzeugt CRUDN-Nachrichten, um eine verteilte IoT-Ausführung gesteuert durch Prozessor 202 des Kern-Frameworks 200 usw. zu unterstützen.
  • Somit kann, wie in den Beispielen von 6-7 veranschaulicht, Zustandsübergangslogik verwendet werden, um Schutzbedingungen zu definieren, die einen Übergang von Zustand Z zu Zustand X und Zustand X zu Zustand Y beeinflussen. Die Schutzbedingung(en) verlangt/verlangen die Anwendung von Sicherheitskontextdaten (z. B. SC i 702). Da die Schutzbedingung von der Verfügbarkeit der Sicherheitskontextdaten (z. B. SC i 604) abhängt, erfordert der HSM-Ausführungsplan 600 die Ausführung der HSM-Sicherheitsdienste 700 des Beispiels von 7 beispielsweise als Voraussetzung für die Ausführung des zweiten Verhaltensblocks 562 in Ausführungsplan 600 von 6. Da sowohl der HSM-Ausführungsplan 600 als auch die ausführbaren HSM-Sicherheitsdienste 700 als HSM-Ausführungspläne ausgedrückt sind, werden beide, 600, 700, als sicher für die automatisierte Ausführung angesehen.
  • Darüber hinaus ist, da der Ausführungsplan 600 von den Sicherheitsdiensten 700 abhängt, auch die Kombination von 600 und 700 sicher. Eine Sequenzierung von Befehlen, die in einer Beschreibung des HSM enthalten sind, bleibt im HSM-Ausführungsplan 600 erhalten, was sicherstellt, dass der Sicherheitskontext (SC i 604) sowohl zeitnah als auch aktuell ist. Daher ist bei HSM-Ausführung 600 sichergestellt, dass die Sicherheitsberechtigungsnachweise und -richtlinien korrekt sind.
  • In bestimmten Beispielen kann, wenn ein Anwendungsentwickler eine Anwendung aktualisiert, um ein anderes Anwendungsziel zu erreichen, das Sicherheitsmodell 700 aktualisiert werden, um die Änderung(en) umzusetzen und sicherstellen zu helfen, dass eine absolut korrekte Anwendung implementiert wird.
  • Durch Implementierung von Computerausführungsprozessflüssen in einem Publish-Subscribe-Modell (und/oder eines Anforderung-Antwort-Flusses, Anwendungsprogrammierschnittstellen (Application Programming Interface, API)-Flusses usw.) über einen ausführbaren HSM können ausführbare Prozessflüsse Daten zwischen Zuständen des ausführbaren Zustandsautomaten konform mit definierten Schutzbedingungen verschieben. Die Schutzbedingungen helfen sicherzustellen, dass der Prozessfluss nur in einen gegebenen Zustand eintreten oder diesen verlassen kann, wenn die definierte(n) Schutzbedingung(en) erfüllt ist/sind.
  • Schutzbedingungen können Sicherheit bieten, indem ein bestimmter Schlüssel und/oder bestimmte Zugangskontrollrichtlinien als Schutzbedingungen verlangt werden. Solche Schutzbedingungen können auf den Eingang zu einem Zustand und/oder den Ausgang von diesem Zustand angewandt werden. Somit können eingangsseitige Zugangskontrolle und ausgangsseitige Zugangskontrolle in einem ausführbaren Zustandsautomatenmodell definiert werden.
  • Die Verwendung des ausführbaren HSM, um einen Prozessausführungsplan zu definieren, erlaubt das Quantifizieren und Beschränken von Daten, Verhalten und gewünschtem Zustand, um eine ordnungsgemäße, zuverlässige und sichere Ausführung sicherzustellen zu helfen. Diese zuverlässige, sichere Ausführung ermöglicht autonome Transaktionen und den Austausch von Informationen zwischen IoT-Vorrichtungen, ohne manuelle Eingaben zu erfordern und ohne Fehler oder Störungen aufgrund einer nicht ordnungsgemäßen Ausführung zu verursachen.
  • In einem beispielhaften HSM-Ausführungsplan können ein oder mehrere Muster angewandt werden, was folgende Terminologie einschließt:
    • DX←BY, zeigt an: „Daten (X) sind abhängig vom Ausgangsfluss von Verhalten (Y)“;
    • BY←DZ, zeigt an: „Verhalten (Y) ist abhängig vom Ausgangsfluss von Daten (Z)“; und
    • DX←BY←DZ, zeigt an: „Zustand DX wird erreicht über BY von Zustand DZ“.
  • Im beispielhaften HSM-Ausführungsplan können Schutzbedingungen als Zustandsabhängigkeits-Tupel in folgender Form ausgedrückt werden: DX←BY←DZ oder kurz (DX.BY.DZ). Ein Endzustand DX kann mehrere abhängige Zustände aufweisen (D0, D1, ..., DZ) und (B0, B1,... ,BY), so dass (DX.BY.D0), (DX.BY.D1),...,(DX.BY.DZ) und (DX.B0.D0), (DX.B1.D0),...(DX.BY.D0) und (DX.BY.D1), (DX.BY.D2),..., (DX.BY.DZ) vorherige Zustände beschreiben, von denen ein aktueller Zustand abhängt.
  • Die Schutzbedingung kann allgemein ausgedrückt werden als:
    Zustand S ijk = f 0 i ( D ) ← f 0 i ( B ) ← f 0 k ( D )
    Figure DE102019103927A1_0001
    für alle Daten D und Verhalten B in einem System. Für einen gegebenen Zustand Sijk gibt es einen anderen Zustand S(ijk+1) , in dem Sijk ← S(ijk+1), so dass S (ijk+1) eine Sicherheits-Zustandsautomat-Schutzbedingung (Security State Machine Guard Condition, SSMGC) ist, die den Zugang zu Sijk kontrolliert. Das bedeutet, der Zustand S(ijk+1) muss erfüllt sein, um Zustand Sijk zu erreichen. Daher besteht für jeden geschützten HSM-Ausführungsplan auch ein sicherer HSM-Ausführungsplan, der ebenfalls geschützt ist. Wenn daher eine Veröffentlichung an Abonnenten von einem Registrierenden- oder Registrierstellen-Datenobjekt wie oben beschrieben abhängt, kann ein sicherer HSM-Ausführungsplan gefunden werden, der die Anforderungen an die Sicherheit der Veröffentlichung erfüllt.
  • In bestimmten Beispielen kann der sichere HSM-Publish-Subscribe-Ausführungsplan auf Distributed-Ledger (verteiltes Kassenbuch)-Nutzungsfälle (auch als Blockchain, Blockkette, bekannt) angewandt werden. Beispielsweise kann ein HSM-Ausführungsplan verwendet werden, um einen Typ von Blockchain zu definieren, der als elektronische Verträge (e-Verträge) bezeichnet wird, der mit einem Distributed-Ledger verbunden sein kann, indem ein HSM entwickelt wird, der den e-Vertrag implementiert und eine elektronische Geldbörse (e-Wallet) sowie Interaktionen zur Schlüsselverwaltung implementiert. Ein e-Vertrag stellt eine Reihe von Schritten und/oder Aktionen dar, in denen Daten zwischen bestimmten Prinzipien fließen, die bestimmte Ergebnisse erzeugen. Prinzipien und Ergebnisse können in einem e-Vertrag deterministisch sein oder nicht (z. B. keine Zufälligkeit aufweisen und immer dasselbe Ergebnis in Reaktion auf denselben Eingang erzeugen). Beispielsweise können e-Verträge in Ethereum ein Zufälligkeitsproblem haben, daher kann ein HSM-Ausführungsplan auf e-Verträge angewandt werden, die mit Ethereum verknüpft sind, um Ethereum zu adressieren, indem ein deterministisches Protokoll erzeugt wird, das auf e-Verträge in Ethereum angewandt werden soll.
  • Eingangs-, Parameter- und Ausgangsflüsse können derart ergänzt werden, dass sie äquivalente Primitive (z. B. Algorithmen einer niedrigeren Ebene und/oder Computercodesegmente) im Distributed-Ledger darstellen und/oder diesen anderweitig entsprechen. Beispielsweise können kryptografische Primitive wie Hash-Funktionen, Verschlüsselungsfunktionen, Digitale-Signatur-Algorithmen, Ringsignaturen, Schwellwertsignaturen, Bit-Commitment-Schemata, Zero-Knowledge-Proof-Techniken, Multi-Party Computation, quantenresistente Algorithmen usw. als Verhalten 560-566 klassifiziert werden, mit bestimmten Eingängen, Parametern und Ausgängen, die als ein sicherer HSM-Ausführungsplan 600 definiert sind. Daten 530-556, die mit verschiedenen Zuständen 510-528 verknüpft sind, können mit Verhalten 560-566 verwendet werden, um Ausgänge und damit verknüpfte Zustandsänderungen 510-528 gemäß verschiedenen Sicherheitskontexten 604-610 zu steuern und beispielsweise eine sichere Distributed-Ledger-Transaktion zu bilden.
  • Somit kann in bestimmten Beispielen ein serialisierter Ausführungsplan einer Blockchain angehören, so das alle Blockchain-Miner dem Ausführungsplan zustimmen. Nachfolgend können die Blockchain-Miner über jeden Schritt des Ausführungsplans informiert werden. Eine Bedingung eines Blockchain-Block-Commitment kann ferner durch jeden Miner vereinbart werden, indem verifiziert wird, dass die zuvor festgelegte Abfolge der Blöcke eine korrekte Abfolge gemäß dem Ausführungsplan enthält. Weiterhin kann ein nächster festzulegender Block ausgewertet werden, um zu bestätigen, dass der Block einen Zustandsübergang enthält, der dem Ausführungsplan entspricht. Falls eine Rücksetzung erkannt wird, entspricht der zurückgesetzte Zustand dem Ausführungsplan gemäß Miner-Konsens.
  • Der beispielhafte ausführbare HSM 700 kann verwendet werden, um den Berechtigungsnachweis-Verwaltungsdienst 306 und den Zugangsverwaltungsdienst 308 als verschiedene Verhalten zu implementieren, die durch Eingangsdaten 702-706 gesteuert sind, um einen Ausgangs-Sicherheitskontext 604-610 (und/oder Geheimtext usw.) bereitzustellen, um Schutzbedingungen für die Ausführung des HSM-Ausführungsplans 600 usw. bereitzustellen.
  • Statt eine Befehlsausführung ohne Vorhersagbarkeit und ohne Sicherheitsmechanismus, der hilft sicherzustellen, dass die Ausführung des Befehls nicht mit einem Fehler endet, wodurch eine Distributed-Ledger-Berechnung und/oder ein anderer Fluss einer IoT-Vorrichtung unterbrochen würde, lösen bestimmte Beispiele diese technischen Probleme, indem sie eine technische Lösung bereitstellen, um die Funktion eines IoT- und/oder anderen Computersystems zu verbessern, indem ein Plan für die Programm-/Befehlsausführung umgewandelt wird in einen durch hierarchische Zustandsautomaten gesteuerten Ausführungsplan mit einer Hierarchie der Daten, Sicherheitskontext und/oder anderen Schutzbedingung basierend auf einem oder mehreren geschachtelten Zuständen, die (einen) Eingang/Eingänge und Parameter bilden, um Verhalten von ausführbaren Anwendungen zu steuern und (einen) Ausgang/Ausgänge für (eine) nächste Aktion(en) im Programmausführungsplan bereitzustellen. Solche Beispiele verändern das Programmausführungsverhalten und stellen verbesserte, robuste Sicherheit und Zuverlässigkeit bereit, um sicherstellen zu helfen, dass Verhalten und zugehörige Zustände nicht erreicht werden, ohne definierte Eingangs- und Ausgangs-Schutzbedingungen zu erfüllen, um die Sicherheit und Zuverlässigkeit der Programmausführung sicherzustellen und damit beispielsweise dazu beizutragen, Systemfehler oder eine unbestimmte Ausführung zu verhindern.
  • Während eine beispielhafte Implementierung des Sicherheitsmanagers 222 von 2-3 in 7 dargestellt ist, können ein oder mehrere der Elemente, Prozesse und/oder Vorrichtungen wie in 7 dargestellt kombiniert, unterteilt, neu angeordnet, weggelassen, entfernt und/oder in beliebiger anderer Weise implementiert werden. Ferner können der beispielhafte ausführbare HSM 700, der beispielhafte Prozessor 302, der beispielhafte Datenspeicher 304, der beispielhafte Berechtigungsnachweis-Nachrichtendienst 306, der beispielhafte Zugangsverwaltungsdienst 308 und/oder, allgemeiner, der beispielhafte Sicherheitsmanager 222 von 2, 3 und/oder 7 durch Hardware, Software, Firmware und/oder eine beliebige Kombination von Hardware, Software und/oder Firmware implementiert sein. So könnte beispielsweise ein beliebiger von beispielhaftem HSM 700, beispielhaftem Prozessor 302, beispielhaftem Datenspeicher 304, beispielhaftem Berechtigungsnachweis-Nachrichtendienst 306, beispielhaftem Zugangsverwaltungsdienst 308 und/oder, allgemeiner, beispielhaftem Sicherheitsmanager 222 von 2, 3, und/oder 7 mithilfe von einer einzigen oder mehreren analogen oder digitalen Schaltung(en), Logikschaltungen, programmierbaren Prozessor(en), anwendungsspezifischen integrierten Schaltung(en) (Application Specific Integrated Circuit, ASIC(s)), programmierbaren Logikbaustein(en) (Programmable Logic Device, PLD(s)) und/oder feldprogrammierbaren Logikbaustein(en) (Field Programmable Logic Device, FPLD(s)) implementiert sein. Wenn beliebige der Vorrichtungs- oder Systemansprüche der vorliegenden Patentanmeldung im Hinblick auf eine reine Software- und/oder Firmware-Implementierung gelesen werden, wird hiermit ausdrücklich definiert, dass der beispielhafte ausführbare HSM 700, der beispielhafte Prozessor 302, der beispielhafte Datenspeicher 304, der beispielhafte Berechtigungsnachweis-Nachrichtendienst 306, der beispielhafte Zugangsverwaltungsdienst 308 und/oder, allgemeiner, der beispielhafte Sicherheitsmanager 222 von 2, 3 und/oder 7 eine nichttransitorische, computerlesbare Speichervorrichtung oder Speicherplatte wie etwa einen Speicher, eine Digital Versatile Disk (DVD), eine Compact Disk (CD), eine Blu-Ray Disk etc. aufweist, welche die Software und/oder die Firmware beinhaltet. Noch ferner kann der beispielhafte Sicherheitsmanager 222 ein oder mehrere Elemente, Prozesse und/oder Vorrichtungen zusätzlich zu den oder anstelle der in 2, 3 und/oder 7 dargestellten beinhalten und/oder kann mehr als ein beliebiges der oder alle dargestellten Elemente, Prozesse und Vorrichtungen aufweisen.
  • Flussdiagramme, die beispielhafte maschinenlesbare Befehle zur Implementierung des beispielhaften Sicherheitsmanagers 222 von 2, 3 und/oder 7 darstellen, werden in 8-9 gezeigt. In diesem Beispiel beinhalten die maschinenlesbaren Befehle ein Programm zur Ausführung durch einen Prozessor wie etwa einen Prozessor 1012, der in der beispielhaften Prozessorplattform 1000 gezeigt wird, welche weiter unten im Zusammenhang mit 10 erörtert wird. Das Programm kann in Software ausgeführt sein, die auf einem nichttransitorischen, computerlesbaren Speichermedium gespeichert ist, etwa einer CD-ROM, einer Diskette, einer Festplatte, einer DVD, einer Blu-Ray-Disk oder einem Speicher, der dem Prozessor 1012 zugeordnet ist, jedoch können das gesamte Programm und/oder Teile davon alternativ auch von einer anderen Vorrichtung anstelle des Prozessors 1012 ausgeführt werden und/oder in Firmware oder dedizierter Hardware ausgeführt sein. Ferner können, auch wenn das beispielhafte Programm unter Bezugnahme auf das in 10 dargestellte Flussdiagramm beschrieben wird, alternativ auch zahlreiche andere Verfahren zur Implementierung des beispielhaften Sicherheitsmanagers 222 von 2, 3 und/oder 7 verwendet werden. Beispielsweise kann die Reihenfolge der Ausführung der Blöcke geändert werden und/oder können einige der beschriebenen Blöcke verändert, ausgelassen oder kombiniert werden. Zusätzlich oder alternativ können beliebige oder alle dieser Blöcke mithilfe einer oder mehrerer Hardwareschaltung(en) implementiert werden (z. B. diskrete und/oder integrierte analoge und/oder digitale Schaltungen, eine feldprogrammierbare Gatteranordnung (Field Programmable Gate Array, FPGA), eine anwendungsspezifische integrierte Schaltung (Application Specific Integrated Circuit, ASIC), ein Komparator, ein Operationsverstärker (Op-Amp), eine Logikschaltung usw.), die so aufgebaut sind, dass sie die entsprechende Operation durchführen können, ohne dass Software oder Firmware ausgeführt wird.
  • Wie vorstehend erwähnt, können die beispielhaften Prozesse von 8-9 mithilfe von codierten Befehlen (z. B. computer- und/oder maschinenlesbaren Befehlen) implementiert werden, die auf/in einem nichttransitorischen computer- und/oder maschinenlesbaren Medium, etwa einem Festplattenlaufwerk, einem Flash-Speicher, einem Festwertspeicher, einer CD, einer DVD, einem Cache, einem Direktzugriffsspeicher und/oder einer beliebigen sonstigen Speichervorrichtung oder Speicherplatte gespeichert sind, in/auf der Informationen für beliebige Zeit (z. B. über längere Zeiträume, dauerhaft, kurzzeitig, zur zeitweisen Pufferung und/oder zur Zwischenspeicherung der Informationen) gespeichert sind. Gemäß Verwendung in der vorliegenden Patentschrift ist der Begriff „nichttransitorisches computerlesbares Medium“ ausdrücklich dahingehend definiert, dass er jede beliebige Art von computerlesbarer Speichervorrichtung und/oder Speicherplatte einschließt und eine Signalausbreitung sowie Übertragungsmedien ausschließt. Die Ausdrücke „aufweisen/einschließen/beinhalten“ und „umfassen“ (sowie jegliche Abwandlungen und Zeitformen davon) werden hier als offene Ausdrücke verwendet. Somit ist überall dort, wo in den Patentansprüchen eine Form von „aufweisen/einschließen/beinhalten“ oder „umfassen“ (z. B. umfasst, beinhaltet, umfassend, beinhaltend etc.) zu finden ist, diese dahingehend zu verstehen, dass zusätzliche Elemente, Begriffe etc. vorhanden sein können, ohne den Schutzbereich des betreffenden Anspruchs zu verlassen. Gemäß Verwendung hier ist der Ausdruck „wenigstens“, soweit er als überleitender Ausdruck im Oberbegriff eines Anspruchs steht, ein offener Ausdruck ähnlich wie die ebenfalls offenen Ausdrücke „umfassend“ und „beinhaltend/einschließend/aufweisend“.
  • Beispielhafte maschinenlesbare Befehle zum Implementieren des Sicherheitsmanagers 222 von 2, 3 und/oder 7, die ausgeführt werden können, um eine durch hierarchische Zustandsautomaten gesteuerte Progammentwicklung und -ausführung durchzuführen, sind in 8-9 dargestellt. Bezug nehmend auf die vorhergehenden Figuren und zugehörigen Beschreibungen beginnen die beispielhaften maschinenlesbaren Befehle 800 zum Erzeugen eines Befehlsausführungsplans eines ausführbaren HSM bei Block 802. Bei Block 802 wird ein Eingangstyp identifiziert. Beispielsweise kann ein Eingangstyp einen Term für einen elektronischen Vertrag in einem Distributed-Ledger-IoT-System von Vorrichtungen aufweisen. Ein Eingangstyp kann beispielsweise eine Schnittstelle für die Kommunikation zwischen IoT-Vorrichtungen beinhalten. Ein Eingangstyp kann Nutzdaten, Geheimtextdaten und/oder andere Daten aufweisen, die beispielsweise in einem aktuellen oder nachfolgenden Verhalten verwendet werden sollen. Bei Block 804 wird ein Parametertyp identifiziert. Beispielsweise kann ein Parametertyp einen Sicherheitskontext, eine andere Verhaltenseinstellung usw. beinhalten. Bei Block 806 wird ein Ausgangstyp identifiziert. Beispielsweise kann ein Ausgang ein Datenwert, Geheimtext usw. sein. Ein Ausgang für ein Verhalten kann ein Eingang und/oder Parameter beispielsweise für ein anderes Verhalten sein.
  • Bei Block 808 wird ein erster Zustand 510-528 mit dem Eingangstyp verknüpft, und ein zweiter Zustand 510-528 wird mit dem Parametertyp verknüpft und ein dritter Zustand 510-528 wird mit dem Ausgangstyp verknüpft. Somit können Eingangstyp, Parametertyp und Ausgangstyp als Zustände 510-528 im hierarchischen Zustandsautomaten 600 definiert werden.
  • Bei Block 810 wird ein Verhalten 560-566 dem Übergang vom ersten Zustand in den dritten Zustand zugeordnet. Beispielsweise kann eine Sicherheitsprüfung, eine Verschlüsselung und/oder eine andere Operation ein Verhalten definieren, das auf den Eingang/die Eingänge angewandt werden soll, basierend auf dem oder den Parametern, um den oder die Ausgänge zu erzeugen. Das Verhalten bindet die Elemente zusammen, um ein Ergebnis zu erzeugen, und Veröffentlicher und Abonnenten können (ein) Ergebnis(se) und/oder (eine) andere Komponente(n) des Verhaltens (z. B. Ausgang, Eingang, Parameter usw.) empfangen.
  • Bei Block 812 wird/werden (eine) Schutzbedingung(en), die mit dem Verhalten verknüpft ist/sind, etwa eine erste Schutzbedingung, um den ersten Zustand zu verlassen, und eine zweite Schutzbedingung, um in den dritten Zustand einzutreten, bestimmt. Beispielsweise können Eingang und/oder Ausgang erforderlich sein, um eine Bedingung/ein Kriterium zu erfüllen, um in den Verhaltenszustand einzutreten und/oder den Verhaltenszustand zu verlassen. Ein Wert, ein Schwellwert, ein Bereich, ein Vergleich usw. kann bestimmt werden, um zuzulassen, dass das Verhalten Zustandsübergänge auf Basis von Eingangs- und/oder Ausgangswerten reguliert. Beispielsweise können Schutzbedingungen mit den Zuständen verknüpft werden, die Eingangs-, Parameter- und/oder Ausgangswerte repräsentieren, und die Bedingungen müssen erfüllt sein für den Übergang in und/oder aus dem gegebenen Zustand.
  • Bei Block 814 wird ein Ausführungsplan formuliert, basierend auf dem ersten Zustand, der ersten Schutzbedingung, dem zweiten Zustand, dem Verhalten, dem dritten Zustand und der zweiten Schutzbedingung. Beispielsweise bilden Eingangs-, Parameter- und Ausgangstypen und zugehörige Zustände und Schutzbedingung(en) den HSM-Ausführungsplan 600, um die Ausführung der Befehle durch den Prozessor und/oder eine andere Computervorrichtung (z. B. IoT-Vorrichtung usw.) gemäß den Zuständen und Bedingungen wie im Plan definiert zu führen. Schutzbedingungen sind derart angeordnet, dass sie als kritische Abschnitte verarbeitet werden, um eine Ordnung gemäß der durch die Zustände 510-528 und Verhalten 560-566 im HSM-Ausführungsplan 600 spezifizierten Abfolge zu bewahren. Somit können die Schutzbedingungen genutzt werden, um eine vorhersagbare, verifizierbare, sichere und zuverlässige Ordnung von Operationen in einem Befehlsausführungsfluss durchzusetzen.
  • Bei Block 816 kehrt die Steuerung zu Block 802 zurück, um den Prozess für jedes verfügbare zusätzliche Verhalten zu wiederholen. Somit können mehrere Verhalten 560-566 (z. B. mehrere Befehls-Primitive, Codesegmente usw.) miteinander verbunden werden, basierend auf Eingängen, Parametern und Ausgängen. Der Ausgang 602 eines ersten Verhaltens 560 kann beispielsweise der Eingang eines zweiten Verhaltens 562 sein. Sobald alle relevanten Verhalten 560-566 mit ihren jeweiligen Zuständen in den Ausführungsplan verarbeitet worden sind, geht die Steuerung weiter zu Block 818.
  • Bei Block 818 wird ein ausführbarer hierarchischer Zustandsautomat instanziiert, unter Verwendung des formulierten Ausführungsplans 600 für den Einsatz zur Ausführung auf einem Prozessor 1012 und/oder einer anderen Computervorrichtung. Beispielsweise kann das Kern-Framework 200 Kommunikation und/oder eine andere Operation zwischen IoT-Vorrichtungen ermöglichen, und der Sicherheitsmanager 222 kann integrierte Betriebssicherheit und -zuverlässigkeit bereitstellen, wobei die Kommunikation/Operation den ausführbaren HSM 700 und zugehörigen Ausführungsplan 600 verwendet. Vorrichtungen und/oder zugehörige Datenverarbeitungsprozesse können Veröffentlicher sein, um Daten und/oder Befehle bereitzustellen, und/oder Abonnenten sein, um Daten und/oder Befehle zu empfangen, die beispielsweise mit den definierten Verhalten 560-566 verknüpft sind. Abonnementthemen können Eingangsflüsse, Parameterflüsse, Ausgangsflüsse usw. beinhalten.
  • 9 veranschaulicht ein Flussdiagramm, das beispielhafte Befehle 900 darstellt, um die Ausführung des HSM-Ausführungsplans 600 über den ausführbaren HSM 700 zu ermöglichen. Bei Block 902 werden Eingänge im HSM-Ausführungsplan 600 identifiziert. Beispielsweise ist ein Dateneingang 530, der mit einem Zustand c 514 verknüpft ist, im Ausführungsplan 600 identifiziert. In einigen Beispielen wird ein Ausgang eines ersten Verhaltens beispielsweise zu einem Eingang eines zweiten Verhaltens. Bei Block 904 werden Parameter im HSM-Ausführungsplan 600 identifiziert. Beispielsweise ist ein Datenparameter 532, der mit einem Zustand f 520 verknüpft ist, im Ausführungsplan 600 identifiziert. Ein Sicherheitskontext, der vom Berechtigungsnachweis-Verwaltungsdienst 304 und/oder Zugangsverwaltungsdienst 304 des ausführbaren HSM 700 erzeugt wird, kann beispielsweise ein Parameter für Verhalten 560-566 im Ausführungsplan 600 werden.
  • Bei Block 906 wird eine erste Schutzbedingung für den Zugang zu einem Verhalten 560-566 aus einem ersten Zustand 510-528 angewandt. Beispielsweise werden (ein) Eingang/Eingänge und (ein) Parameter im Hinblick auf die mit ihnen verknüpften Informationen 530-566 und/oder 602-610 sowie die entsprechenden Zustände 510-528 analysiert, um (eine) Schutzbedingung(en) oder Anforderungen, die vom Eingang und/oder Parameter erfüllt sein müssen, um in ein Verhalten 560-566 und/oder einen entsprechenden Zustand 510-528 einzutreten, zu bestimmen. Beispielsweise kann ein Sicherheitskontext Berechtigungsnachweise zum Entschlüsseln eines Geheimtexts und eine zugehörige Zugangsrichtlinie bereitstellen. Ein Sicherheitskontext kann Berechtigungsnachweise sowie eine Zugangsverwaltungsrichtlinie von einem Verhalten 560-566 anwenden, das einen Ausgang bereitstellt, um beispielsweise einen Eingang bei einem anderen Verhalten 560-566 anzusteuern. Somit können Zugang, Verschlüsselung/Entschlüsselung und Abfolge von Ereignissen ordnungsgemäß durch den Ausführungsplan gesteuert werden.
  • Wenn bei Block 908 die erste Schutzbedingung nicht erfüllt ist, dann kehrt bei Block 910 die Ausführung zu einem vorherigen sicheren Zustand zurück. Beispielsweise kehrt die Steuerung zu Block 902 zurück, um den Prozess erneut zu starten. Alternativ kann die Steuerung zu einem anderen vorherigen, bekannten, sicheren Zustand zurückkehren, um den Ausführungsplan aus diesem Zustand heraus wieder aufzunehmen. Somit können veraltete Sicherheits- und/oder andere fehlerhafte Zustände vermieden werden.
  • Wenn die Schutzbedingung erfüllt ist, wird bei Block 912 das Verhalten 560-566 ausgeführt. Beispielsweise können Berechtigungsnachweise angewandt werden, um Zugang zu überprüfen und Daten zu entschlüsseln. Eine Autorisierung kann es erlauben, Eingangsdaten in Ausgangsdaten umzuwandeln und an einen Benutzer, ein nächstes Verhalten 560-566 usw. bereitzustellen.
  • Bei Block 914 wird eine zweite Schutzbedingung angewandt, um das Verhalten 560-566 zu verlassen und in einen zweiten Zustand 510-528 einzutreten, nachdem Verhalten 560-566 abgeschlossen ist. Beispielsweise kann eine Zugangsbedingung angewandt werden, um einen Ausgang des Verhaltens 560-566 zu erzeugen, um den Ausgang im Ausführungsplan 600 ordnungsgemäß weiterzuverbreiten. Eine Entschlüsselung kann angewandt werden, um sicherzustellen, dass ein Ausgang für die weitere Anwendung im Ausführungsplan 600 verarbeitbar und/oder anderweitig verständlich ist.
  • Wenn bei Block 916 die zweite Schutzbedingung nicht erfüllt ist, dann kehrt bei Block 918 die Ausführung zu einem vorherigen sicheren Zustand zurück. Beispielsweise kehrt die Steuerung zu Block 902 zurück, um den Prozess erneut zu starten. Alternativ kann die Steuerung zu einem anderen vorherigen, bekannten sicheren Zustand zurückkehren, um den Ausführungsplan aus diesem Zustand heraus wieder aufzunehmen. Somit können veraltete Sicherheits- und/oder andere fehlerhafte Zustände vermieden werden.
  • Wenn die Schutzbedingung erfüllt ist, dann wird bei Block 920 ein Ausgang beim zweiten Zustand 510-528 bereitgestellt. Beispielsweise werden entschlüsselte Daten vom Verhalten 560-566 an einen nächsten Zustand 510-528 bereitgestellt. Ein Geheimtext 602, 606 wird beispielsweise als Eingang zu einem nächsten Verhalten 562, 564 erzeugt. Ausgangsdaten werden vom Verhalten 562 erzeugt, um beispielsweise zum Eingang für das Verhalten 566 zu werden. Ein Ausgang kann beispielsweise an eine Vorrichtung und/oder einen anderen Prozess (z. B. über ein Abonnement usw.) bereitgestellt werden.
  • Bei Block 922 werden zugehörige Abonnements übertragen. Beispielsweise können ein oder mehrere Veröffentlicher und/oder Abonnenten einen Eingangsfluss, Parameterfluss und/oder Ausgangsfluss als Ergebnis der Ausführung eines Verhaltens empfangen. Abonnementinformationen können mit dem Ausgang, zum Zeitpunkt der Anwendung der Schutzbedingung, dynamisch bei Erzeugung und/oder Empfang jedes Eingangs, Parameters und/oder Ausgangs usw. übertragen werden. Somit können Vorrichtungen, Programme usw. Daten- und/oder Befehlsausgang (-ausgänge) des verhaltens- und zustandsgesteuerten Ausführungsplans 600 empfangen, um einen Systembetrieb wie etwa Kommunikation von IoT-Vorrichtungen, Programmausführung, Synchronisation von Vorrichtungen usw. zu ermöglichen.
  • Bei Block 924 wird die Ausführung des Ausführungsplans 600 fortgesetzt, solange Verhalten 560-566 bestehen bleiben. Andernfalls endet der Prozess. Somit ermöglicht der HSM-Ausführungsplan 600, der durch den und/oder zusammen mit dem ausführbaren HSM 700 des Sicherheitsmanagers 222 und/oder anderen ausführbaren HSM implementiert ist, eine ordnungsgemäße, zuverlässige und sichere Programmausführung in einer IoT- und/oder sonstigen Umgebung.
  • 10 ist ein Blockschaltbild einer beispielhaften Prozessorplattform 1000, die in der Lage ist, die Befehle von 8-9 auszuführen, um die Systeme von 1-7 zu implementieren. Die Prozessorplattform 1000 kann beispielsweise ein Server, ein Personal-Computer, eine mobile Vorrichtung (z. B. ein Mobiltelefon, ein Smartphone, ein Tablet wie etwa ein iPad™), ein persönlicher digitaler Assistent (PDA), ein Internetgerät, ein DVD-Player, ein CD-Player, ein digitaler Videorecorder, ein Blu-Ray-Player, eine Spielkonsole, ein persönlicher Videorecorder, eine Set-Top-Box oder eine andere Art von Computervorrichtung sein.
  • Die Prozessorplattform 1000 des dargestellten Beispiels weist einen Prozessor 1012 auf. Der Prozessor 1012 des dargestellten Beispiels ist Hardware. Beispielsweise kann der Prozessor 1012 durch eine(n) oder mehrere integrierte Schaltungen, Logikschaltungen, Mikroprozessoren oder Steuerungen einer beliebigen gewünschten Familie bzw. eines beliebigen gewünschten Herstellers implementiert sein. In dem dargestellten Beispiel ist der Prozessor 1012 derart aufgebaut, dass er den beispielhaften Prozessor 302 aufweist, welcher den beispielhaften ausführbaren HSM 700 mit dem beispielhaften Berechtigungsnachweis-Verwaltungsdienst 306 und Zugangsverwaltungsdienst 308 usw. aufweist.
  • Der Prozessor 1012 des dargestellten Beispiels weist einen lokalen Speicher 1013 auf (z. B. einen Cache). Der Prozessor 1012 des dargestellten Beispiels steht über einen Bus 1018 in Kommunikationsverbindung mit einem Hauptspeicher, der einen flüchtigen Speicher 1014 und einen nichtflüchtigen Speicher 1016 aufweist. Der flüchtige Speicher 1014 kann mittels SDRAM (Synchronous Dynamic Random Access Memory, synchroner dynamischer Direktzugriffsspeicher), DRAM (Dynamic Random Access Memory, dynamischer Direktzugriffsspeicher), RDRAM (RAMBUS Dynamic Random Access Memory, dynamischer Direktzugriffsspeicher von RAMBUS), 3D XPoint (etwa Intel Optane™, Micron QuantX™, usw.) und/oder eines anderen Typs von Direktzugriffsspeichervorrichtung implementiert sein. Der nichtflüchtige Speicher 1016 kann mittels Flash-Speicher und/oder einer beliebigen anderen gewünschten Art von Speichervorrichtung implementiert sein. Der Zugriff auf den Hauptspeicher 1014, 1016 wird durch eine Speichersteuerung gesteuert.
  • Die Prozessorplattform 1000 des dargestellten Beispiels weist auch eine Schnittstellenschaltung 1020 auf. Die Schnittstellenschaltung 1020 kann mittels eines beliebigen Typs von Schnittstellenstandard, etwa einer Ethernet-Schnittstelle, eines Universal Serial Bus (USB) und/oder einer PCI (Peripheral Component Interconnect, Peripheriegeräteverbindung)-Express-Schnittstelle implementiert sein.
  • In dem dargestellten Beispiel sind eine oder mehrere Eingabevorrichtungen 1022 mit der Schnittstellenschaltung 1020 verbunden. Die Eingabevorrichtung(en) 1022 erlaubt/erlauben es einem Benutzer, Daten und Befehle in den Prozessor 1012 einzugeben. Die Eingabevorrichtung(en) 1022 können beispielsweise durch einen Audio-Sensor, ein Mikrofon, eine Tastatur, eine Taste, eine Maus, einen Berührungsschirm, ein Trackpad, einen Trackball, einen Isopoint und/oder ein Spracherkennungssystem implementiert sein.
  • Eine oder mehrere Ausgabevorrichtungen 1024 sind ebenfalls mit der Schnittstellenschaltung 1020 des dargestellten Beispiels verbunden. Die Ausgabevorrichtungen 1024 können beispielsweise mittels Anzeigevorrichtungen implementiert sein (z. B. einer Leuchtdiode (LED), einer organischen Leuchtdiode (OLED), einer Flüssigkristallanzeige, einer CRT (Cathod Ray Tube, Kathodenstrahlröhre)-Anzeige, einem Berührungsschirm, einer taktilen Ausgabevorrichtung). Die Schnittstellenschaltung 1020 des dargestellten Beispiels weist somit typischerweise eine Grafiktreiberkarte, einen Grafiktreiberchip oder einen Grafiktreiberprozessor auf.
  • Die Schnittstellenschaltung 1020 des dargestellten Beispiels weist auch eine Kommunikationsvorrichtung auf, etwa einen Sender, einen Empfänger, einen Sendeempfänger, ein Modem und/oder eine Netzschnittstellenkarte, um den Austausch von Daten mit externen Maschinen (z. B. Computervorrichtungen beliebiger Art) über ein Netz 1026 (z. B. eine Ethernet-Verbindung, einen digitalen Teilnehmeranschluss (Digital Subscriber Line, DSL), eine Telefonleitung, ein Koaxialkabel, ein Mobiltelefonsystem etc.) zu ermöglichen.
  • Die Prozessorplattform 1000 des dargestellten Beispiels weist außerdem eine oder mehrere Massenspeichervorrichtungen 1028 zum Speichern von Software und/oder Daten auf. Beispiele derartiger Massenspeichervorrichtungen 1028 beinhalten Diskettenlaufwerke, Festplattenlaufwerke, Compact-Disk-Laufwerke, Blu-Ray-Disk-Laufwerke, RAID-Systeme und Digital-Versatile-Disk (DVD)-Laufwerke.
  • Die codierten Befehle 1032 von 5-7 können in der Massenspeichervorrichtung 1028, im flüchtigen Speicher 1014, im nichtflüchtigen Speicher 1016 und/oder auf einem wechselbaren physischen, computerlesbaren Speichermedium wie einer CD oder DVD gespeichert sein.
  • 11 ist ein Blockschaltbild einer beispielhaften Prozessorplattform 1100, die in der Lage ist, die Befehle von 8-9 auszuführen, um die Systeme von 1-7 zu implementieren. Die Prozessorplattform 1100 kann beispielsweise ein Server, ein Personal-Computer, eine mobile Vorrichtung (z. B. ein Mobiltelefon, ein Smartphone, ein Tablet wie etwa ein iPad™), ein persönlicher digitaler Assistent (PDA), ein Internetgerät, ein DVD-Player, ein CD-Player, ein digitaler Videorecorder, ein Blu-Ray-Player, eine Spielkonsole, ein persönlicher Videorecorder, eine Set-Top-Box oder eine andere Art von Computervorrichtung sein.
  • Die Prozessorplattform 1100 des dargestellten Beispiels weist einen Prozessor 1112 auf. Der Prozessor 1112 des dargestellten Beispiels ist Hardware. Beispielsweise kann der Prozessor 1112 durch eine(n) oder mehrere integrierte Schaltungen, Logikschaltungen, Mikroprozessoren oder Steuerungen einer beliebigen gewünschten Familie bzw. eines beliebigen gewünschten Herstellers implementiert sein. In dem dargestellten Beispiel ist der Prozessor 1112 derart aufgebaut, dass er den beispielhaften Prozessor 202 und seine Bestandteile wie etwa den beispielhaften Adressierer 206, die beispielhafte Protokollbrücke 208, das beispielhafte „Common Resource“-Modell 210, die beispielhafte Anforderung/Antwort-Steuereinheit 212, die beispielhafte Vorrichtungsentdeckungseinheit 214, den beispielhaften Nachrichtenübermittler 216, den beispielhaften Vorrichtungsmanager 218 usw. aufweist.
  • Der Prozessor 1112 des dargestellten Beispiels weist einen lokalen Speicher 1113 auf (z. B. einen Cache). Der Prozessor 1112 des dargestellten Beispiels steht über einen Bus 1118 in Kommunikationsverbindung mit einem Hauptspeicher, der einen flüchtigen Speicher 1114 und einen nichtflüchtigen Speicher 1116 aufweist. Der flüchtige Speicher 1114 kann mittels SDRAM (Synchronous Dynamic Random Access Memory, synchroner dynamischer Direktzugriffsspeicher), DRAM (Dynamic Random Access Memory, dynamischer Direktzugriffsspeicher), RDRAM (RAMBUS Dynamic Random Access Memory, dynamischer Direktzugriffsspeicher von RAMBUS), 3D XPoint (etwa Intel Optane™, Micron QuantX™, usw.) und/oder eines anderen Typs von Direktzugriffsspeichervorrichtung implementiert sein. Der nichtflüchtige Speicher 1116 kann mittels Flash-Speicher und/oder einer beliebigen anderen gewünschten Art von Speichervorrichtung implementiert sein. Der Zugriff auf den Hauptspeicher 1114, 1116 wird durch eine Speichersteuerung gesteuert.
  • Die Prozessorplattform 1100 des dargestellten Beispiels weist auch eine Schnittstellenschaltung 1120 auf. Die Schnittstellenschaltung 1120 kann mittels eines beliebigen Typs von Schnittstellenstandard, etwa einer Ethernet-Schnittstelle, eines Universal Serial Bus (USB) und/oder einer PCI (Peripheral Component Interconnect, Peripheriegeräteverbindung)-Express-Schnittstelle implementiert sein.
  • In dem dargestellten Beispiel sind eine oder mehrere Eingabevorrichtungen 1122 mit der Schnittstellenschaltung 1120 verbunden. Die Eingabevorrichtung(en) 1122 erlaubt/erlauben es einem Benutzer, Daten und Befehle in den Prozessor 1112 einzugeben. Die Eingabevorrichtung(en) 1122 können beispielsweise durch einen Audio-Sensor, ein Mikrofon, eine Tastatur, eine Taste, eine Maus, einen Berührungsschirm, ein Trackpad, einen Trackball, einen Isopoint und/oder ein Spracherkennungssystem implementiert sein.
  • Eine oder mehrere Ausgabevorrichtungen 1124 sind ebenfalls mit der Schnittstellenschaltung 1120 des dargestellten Beispiels verbunden. Die Ausgabevorrichtungen 1124 können beispielsweise mittels Anzeigevorrichtungen implementiert sein (z. B. einer Leuchtdiode (LED), einer organischen Leuchtdiode (OLED), einer Flüssigkristallanzeige, einer CRT (Cathod Ray Tube, Kathodenstrahlröhre)-Anzeige, einem Berührungsschirm, einer taktilen Ausgabevorrichtung). Die Schnittstellenschaltung 1120 des dargestellten Beispiels weist somit typischerweise eine Grafiktreiberkarte, einen Grafiktreiberchip oder einen Grafiktreiberprozessor auf.
  • Die Schnittstellenschaltung 1120 des dargestellten Beispiels weist auch eine Kommunikationsvorrichtung auf, etwa einen Sender, einen Empfänger, einen Sendeempfänger, ein Modem und/oder eine Netzschnittstellenkarte, um den Austausch von Daten mit externen Maschinen (z. B. Computervorrichtungen beliebiger Art) über ein Netz 1126 (z. B. eine Ethernet-Verbindung, einen digitalen Teilnehmeranschluss (Digital Subscriber Line, DSL), eine Telefonleitung, ein Koaxialkabel, ein Mobiltelefonsystem etc.) zu ermöglichen.
  • Die Prozessorplattform 1100 des dargestellten Beispiels weist außerdem eine oder mehrere Massenspeichervorrichtungen 1128 zum Speichern von Software und/oder Daten auf. Beispiele derartiger Massenspeichervorrichtungen 1128 beinhalten Diskettenlaufwerke, Festplattenlaufwerke, Compact-Disk-Laufwerke, Blu-Ray-Disk-Laufwerke, RAID-Systeme und Digital-Versatile-Disk (DVD)-Laufwerke.
  • Die codierten Befehle 1132 von 5-7 können in der Massenspeichervorrichtung 1128, im flüchtigen Speicher 1114, im nichtflüchtigen Speicher 1116 und/oder auf einem wechselbaren physischen, computerlesbaren Speichermedium wie einer CD oder DVD gespeichert sein.
  • 12 veranschaulicht eine beispielhafte Domänentopologie für jeweilige „Internet-of-Things“ (IoT)-Netze, die über Verbindungen mit jeweiligen Netzübergängen (Gateways) gekoppelt sind. In bestimmten Beispielen beinhaltet das IoT ein große Zahl von Computervorrichtungen, die untereinander und mit dem Internet verbunden sind, um Funktionalität und Datenerfassung auf sehr niedriger Ebene bereitzustellen. Somit kann, wie hier verwendet, eine IoT-Vorrichtung eine halbautonome Vorrichtung, die eine Funktion ausführt, unter anderem etwa Erfassen oder Steuern, in Kommunikationsverbindung mit anderen IoT-Vorrichtungen und einem größeren Netz, etwa dem Internet, beinhalten.
  • Häufig sind IoT-Vorrichtungen hinsichtlich Speicher, Größe oder Funktionalität eingeschränkt, was einen Einsatz einer größeren Anzahl zu vergleichbaren Kosten wie bei einer geringeren Anzahl größere Vorrichtungen erlaubt. Allerdings kann eine IoT-Vorrichtung ein Smartphone, Laptop, Tablet oder PC oder eine andere größere Vorrichtung sein. Ferner kann eine IoT-Vorrichtung eine virtuelle Vorrichtung sein, etwa eine Anwendung auf einem Smartphone oder einer anderen Computervorrichtung. IoT-Vorrichtungen können IoT-Netzübergänge aufweisen, die dazu dienen, IoT-Vorrichtungen mit anderen IoT-Vorrichtungen und Cloud-Anwendungen für Datenspeicherung, Prozesssteuerung und dergleichen zu koppeln.
  • Netze von IoT-Vorrichtungen können kommerzielle und Hausautomatisierungsvorrichtungen wie etwa Wasserverteilsysteme, Stromverteilungssysteme, Pipeline-Steuerungssysteme, Anlagensteuerungssysteme, Lichtschalter, Thermostate, Schlösser, Kameras, Alarme, Bewegungssensoren und dergleichen beinhalten. Auf die IoT-Vorrichtungen kann über entfernte Computer, Server und andere Systeme zugegriffen werden, beispielsweise um Systeme zu steuern oder auf Daten zuzugreifen.
  • Das künftige Wachstum des Internets und derartiger Netze kann sehr große Zahlen von IoT-Vorrichtungen mit sich bringen. Entsprechend werden im Zusammenhang der hier erörterten Techniken eine Anzahl von Innovationen für eine derartige künftige Vernetzung der Notwendigkeit für alle diese Schichten Rechnung tragen, ungehindert zu wachsen, verbundene Vorrichtungen zu entdecken und zugänglich zu machen und die Möglichkeit zu unterstützen, verbundene Ressourcen zu verbergen und aufzuteilen. Eine Anzahl verschiedener Netzprotokolle und Kommunikationsstandards können verwendet werden, wobei jedes Protokoll und jeder Standard dafür ausgelegt ist, spezifische Aufgaben zu erfüllen. Ferner sind die Protokolle Teil des Fabric und unterstützen für Menschen zugängliche Dienste, die unabhängig von Ort, Zeit oder Raum arbeiten. Zu den Innovationen zählen die Dienstbereitstellung und die zugehörige Infrastruktur, etwa Hardware und Software; Sicherheitsverbesserungen; und die Bereitstellung von Diensten basierend auf Dienstgüte (Quality of Service, QoS)-Bedingungen, die in Dienstleistungs (Service Level)- und Dienstbereitstellungs (Service Delivery)-Vereinbarungen niedergelegt sind. Wie einzusehen ist, ergeben sich durch die Verwendung von IoT-Vorrichtungen und -netzen wie den hier vorgestellten eine Reihe neuer Herausforderungen in einem heterogenen Netz mit Konnektivität, die eine Kombination aus drahtgebundenen und drahtlosen Technologien umfasst.
  • 12 stellt eine vereinfachte Zeichnung einer Domänentopologie bereit, die für eine Reihe verschiedener IoT-Netze verwendet werden kann, die IoT-Vorrichtungen 1204 (z. B. ein Beispiel der Prozessorplattform 1100 usw.) aufweisen, wobei die IoT-Netze 1256, 1258, 1260, 1262 über Backbone-Verbindungen 1202 mit entsprechenden Netzübergängen 1254 gekoppelt sind. Beispielsweise können eine Reihe von IoT-Vorrichtungen 1204 mit einem Netzübergang 1254 und über den Netzübergang 1254 untereinander kommunizieren. Zur Vereinfachung der Zeichnung sind nicht alle IoT-Vorrichtungen 1204 oder Kommunikationsverbindungen (z. B. Verbindung 1216, 1222, 1228 oder 1232) beschriftet. Die Backbone-Verbindungen 1202 können eine beliebige Anzahl drahtgebundener oder drahtloser Technologien aufweisen, darunter etwa optische Netze, und können Teil eines Ortsnetzes (Local Area Network, LAN), eines Weitverkehrsnetzes (Wide Area Network, WAN) oder des Internets sein. Darüber hinaus ermöglichen solche Kommunikationsverbindungen optische Signalpfade sowohl zwischen IoT-Vorrichtungen 1204 als auch Netzübergängen 1254, einschließlich die Verwendung von MUX-/DeMUX-Komponenten, die die Zusammenschaltung der verschiedenen Vorrichtungen ermöglichen.
  • Die Netztopologie kann eine beliebige Anzahl von IoT-Netztypen aufweisen, etwa ein Maschennetz, das mit dem Netz 1256 bereitgestellt wird, unter Verwendung von BLE (Bluetooth Low Energy, Bluetooth-Niedrigenergie)-Verbindungen 1222. Andere IoT-Netztypen, die vorhanden sein können, können ein drahtloses Ortsnetz (Wireless Local Area Network, WLAN) 1258 aufweisen, das genutzt wird, um mit IoT-Vorrichtungen 1204 über IEEE 802.11 (Wi-Fi®)-Verbindungen 1228 zu kommunizieren, ein Zellularnetz 1260, das genutzt wird, um mit IoT-Vorrichtungen 1204 über ein LTE/LTE-A (4G)- oder 5G-Zellularnetz zu kommunizieren, und ein Niedrigenergie-Weitverkehrs (Low-Power Wide Area, LPWA)-Netz 1262, beispielsweise ein LPWA-Netz, das mit der LoRaWan-Spezifikation kompatibel ist, welche von der LoRa Alliance veröffentlicht wurde, oder ein IPv6-über-LPWAN (Low Power Wide-Area Networks)-Netz, das mit einer Spezifikation kompatibel ist, die von der Internet Engineering Task Force (IETF) veröffentlicht wurde. Ferner können die jeweiligen IoT-Netze mit einem externen Netzanbieter (z. B. einem Tier-2- oder Tier-3-Anbieter) über eine beliebige Anzahl von Kommunikationsverbindungen kommunizieren, beispielsweise eine LTE-Mobilfunkverbindung, eine LPWA-Verbindung oder eine Verbindung auf Basis des IEEE-802.15.4-Standards, etwa Zigbee®. Die jeweiligen IoT-Netze können auch unter Verwendung einer Reihe verschiedener Netz- und Internet-Anwendungsprotokolle wie dem Constrained Application Protocol (CoAP) betrieben werden. Die jeweiligen IoT-Netze können außerdem mit Koordinatorvorrichtungen integriert sein, die eine Kette von Verbindungen bereitstellen, welche einen Cluster-Baum aus verbundenen Vorrichtungen und Netzen bildet.
  • Jedes dieser IoT-Netze kann Möglichkeiten für neue Technologien, etwa die hier beschriebenen, bereitstellen. Die verbesserten Technologien und Netze können das exponentielle Wachstum von Vorrichtungen und Netzen einschließlich der Nutzung von IoT-Netzen als Fog-Vorrichtungen oder -Systeme ermöglichen. Mit zunehmender Nutzung solcher verbesserter Technologien können IoT-Netze für Selbstverwaltung, funktionale Weiterentwicklung und Zusammenarbeit, ohne direkte menschliche Eingriffe zu erfordern, entwickelt werden. Die verbesserten Technologien können sogar ermöglichen, dass IoT-Netze ohne zentralisierte gesteuerte Systeme funktionieren. Entsprechend können die hier beschriebenen verbesserten Technologien eingesetzt werden, um Netzverwaltungs- und -betriebsfunktionen weit über das Maß aktueller Implementierungen hinaus zu automatisieren.
  • In einem Beispiel kann Kommunikation zwischen IoT-Vorrichtungen 1204, etwa über die Backbone-Verbindungen 1202, durch ein dezentrales System für Authentifizierung, Autorisierung und Abrechnung (Authentication, Authorization, and Accounting, AAA) geschützt werden. In einem dezentralen AAA-System können verteilte Zahlungs-, Gutschrift-, Prüfungs-, Autorisierungs- und Authentifizierungssysteme über eine verbundene heterogene Netzinfrastruktur implementiert werden. Dies erlaubt eine Entwicklung von Systemen und Netzen hin zum autonomen Betrieb. Bei dieser Art autonomen Betriebs können Maschinen sogar Verträge für Mitarbeiter abschließen und Partnerschaften mit anderen Maschinennetzen aushandeln. Dies kann das Erreichen wechselseitiger Ziele und einer ausgeglichenen Dienstbereitstellung vor dem Hintergrund klar umrissener, geplanter Dienstleistungsvereinbarungen (Service Level Agreements) ermöglichen und Lösungen erzielen, die Zählung, Messungen, Nach- und Rückverfolgbarkeit bieten. Die Schaffung neuer Lieferkettenstrukturen und -verfahren kann eine Vielzahl von Diensten möglich machen, die ohne menschliche Beteiligung erzeugt, zur Wertschöpfung genutzt und wieder abgebaut werden.
  • Solche IoT-Netze können durch Integration von Sensortechnologien, etwa Ton, Licht, elektronischer Verkehr, Gesichts- und Mustererkennung, Geruch, Schwingung, weiter zu den autonomen Organisationen unter den IoT-Vorrichtungen verbessert werden. Die Integration von Sensorsystemen kann eine systematische und autonome Kommunikation und Koordination der Dienstbereitstellung vor dem Hintergrund vertraglich vereinbarter Serviceziele, Orchestrierung sowie Dienstgüte (Quality Of Service, QoS)-basiertes Swarming („Schwarmbildung“) und Fusionieren von Ressourcen ermöglichen. Einige Einzelbeispiele für netzbasierte Ressourcenverarbeitung beinhalten die folgenden.
  • Das Maschennetz 1256 beispielsweise kann durch Systeme verbessert werden, die Inline-Umwandlungen von Daten in Informationen durchführen. Beispielsweise können selbstausbildende Ketten von Verarbeitungsressourcen, die ein Multi-Verbindungsnetz umfassen, die Umwandlung von Rohdaten in Informationen wirksam dezentralisieren, ebenso die Fähigkeit, zwischen Anlagen und Ressourcen und der jeweils zugehörigen Verwaltung zu differenzieren. Weiterhin können die geeigneten Komponenten von Infrastruktur und ressourcenbasierte Vertrauens- und Dienstindizes eingefügt werden, um Datenintegrität, Qualität, Sicherheit zu verbessern und einen Kennwert für die Datenzuverlässigkeit (Konfidenz) zu liefern.
  • Das WLAN-Netz 1258 beispielsweise kann Systeme nutzen, die Umsetzungen zwischen Standards durchführen, um Mehrstandard-Konnektivität bereitzustellen, wodurch IoT-Vorrichtungen 1204, die mit verschiedenen Protokollen arbeiten, kommunizieren können. Weitere Systeme können nahtlose Interkonnektivität in einer Mehrstandard-Infrastruktur bereitstellen, die sichtbare Internet-Ressourcen und verborgene Internet-Ressourcen aufweist.
  • Die Kommunikation im Zellularnetz 1260 beispielsweise kann durch Systeme verbessert werden, die Daten auslagern, die Kommunikation auf eine größere Zahl entfernter Vorrichtungen ausdehnen oder beides. Das LPWA-Netz 1262 kann Systeme aufweisen, die Verbindungen, Adressierung und Routing zwischen Internet-Protokoll (IP) und anderen Protokollen durchführen. Ferner kann jede der IoT-Vorrichtungen 1204 den geeigneten Sendeempfänger für Weitverkehr-Kommunikation mit der betreffenden Vorrichtung aufweisen. Ferner kann jede IoT-Vorrichtung 1204 weitere Sendeempfänger für die Kommunikation unter Verwendung zusätzlicher Protokolle und Frequenzen aufweisen.
  • Und schließlich können Cluster von IoT-Vorrichtungen ausgerüstet werden, um mit anderen IoT-Vorrichtungen ebenso wie mit einem Cloud-Netz zu kommunizieren. Dies kann es ermöglichen, dass die IoT-Vorrichtungen ein Ad-hoc-Netz zwischen den Vorrichtungen bilden, was ihnen ermöglicht, wie eine einzige Vorrichtung zu funktionieren, die als Fog-Vorrichtung bezeichnet werden kann. Diese Ausgestaltung wird nachstehend unter Bezugnahme auf 13 erörtert.
  • 13 veranschaulicht ein Cloud-Computing-Netz in Kommunikationsverbindung mit einem Maschennetz von IoT-Vorrichtungen (Vorrichtungen 1302), das als Fog-Vorrichtung im Randbereich (Edge) des Cloud-Computing-Netzes fungiert. Das Maschennetz aus IoT-Vorrichtungen kann als Fog 1320 bezeichnet werden und arbeitet im Randbereich der Cloud 1300. Zur Vereinfachung des Diagramms ist nicht jede IoT-Vorrichtung 1302 beschriftet.
  • Der Fog 1320 kann als ein sehr stark untereinander verbundenes Netz betrachtet werden, wobei eine Anzahl von IoT-Vorrichtungen 1302 in Kommunikationsverbindung miteinander stehen, beispielsweise über Funkverbindungen 1322. Als Beispiel kann dieses untereinander verbundene Netz unter Verwendung einer Spezifikation für Interkonnektivität realisiert werden, die von der Open Connectivity Foundation™ (OCF) veröffentlicht wurde. Mit diesem Standard können Vorrichtungen einander erkennen und Kommunikation für Verbindungen einrichten. Andere Verbindungsprotokolle können ebenfalls verwendet werden, darunter beispielsweise das „Optimized Link State Routing“ (OLSR)-Protokoll, das „Better Approach To Mobile Ad-Hoc Networking“ (B.A.T.M.A.N.)-Routing-Protokoll oder das „OMA Lightweight M2M“ (LWM2M)-Protokoll.
  • Drei Arten von IoT-Vorrichtungen 1302 werden in diesem Beispiel gezeigt, Netzübergänge 1304, Datenaggregatoren 1326 und Sensoren 1328, wenngleich beliebige Kombinationen von IoT-Vorrichtungen 1302 und Funktionalität verwendet werden können. Die Netzübergänge 1304 können die Netzrand (Edge)-Vorrichtungen sein, die Kommunikation zwischen der Cloud 1300 und dem Fog 1320 bereitstellen, und können außerdem die Backend-Prozessfunktion für Daten bereitstellen, die von Sensoren 1328 erhalten werden, etwa Bewegungsdaten, Stromdaten, Temperaturdaten und dergleichen. Die Datenaggregatoren 1326 können Daten von einer beliebigen Anzahl der Sensoren 1328 sammeln und die Backend-Verarbeitungsfunktion für die Analyse durchführen. Die Ergebnisse, Rohdaten oder beides können über die Netzübergänge 1304 an die Cloud 1300 weitergegeben werden. Die Sensoren 1328 können vollfunktionale IoT-Vorrichtungen 1302 sein, die beispielsweise sowohl Daten sammeln als auch die Daten verarbeiten können. In manchen Fällen können die Sensoren 1328 in der Funktionalität stärker eingeschränkt sein, beispielsweise die Daten erfassen und die Datenaggregatoren 1326 oder Netzübergänge 1304 die Daten verarbeiten lassen.
  • Übertragungen von einer beliebigen IoT-Vorrichtung 1302 können über einen geeigneten Pfad (z. B. einen geeignetsten Pfad) zwischen beliebigen der IoT-Vorrichtungen 1302 weitergeleitet werden, um die Netzübergänge 1304 zu erreichen. In diesen Netzen bietet die Anzahl der Verbindungen erhebliche Redundanz, was es ermöglicht, Kommunikation auch dann aufrechtzuerhalten, wenn einige der IoT-Vorrichtungen 1302 ausfallen. Ferner kann die Verwendung eines Maschennetzes IoT-Vorrichtungen 1302 ermöglichen, die eine sehr geringe Leistung aufweisen oder in einer Entfernung von der zu verwendenden Infrastruktur angeordnet sind, da die Reichweite zum Verbinden mit einer anderen IoT-Vorrichtung 1302 deutlich kürzer sein kann als die Reichweite zum Verbinden mit den Netzübergängen 1304.
  • Der Fog 1320, der von diesen IoT-Vorrichtungen 1302 bereitgestellt wird, kann für Vorrichtungen in der Cloud 1300, etwa einen Server 1306, als eine einzelne Vorrichtung im Randbereich der Cloud 1300, z. B. eine Fog-Vorrichtung, dargestellt werden. In diesem Beispiel können Meldungen, die von der Fog-Vorrichtung kommen, gesendet werden, ohne dass sie als von einer bestimmten IoT-Vorrichtung 1302 im Fog 1320 kommend identifiziert werden. Auf diese Weise kann der Fog 1320 als eine verteilte Plattform betrachtet werden, die Rechen- und Speicherressourcen bereitstellt, um verarbeitungs- oder datenintensive Aufgaben wie etwa Datenanalyse, Datenaggregation und maschinelles Lernen und andere auszuführen.
  • In einigen Beispielen können die IoT-Vorrichtungen 1302 mithilfe eines imperativen Programmierstils konfiguriert werden, wobei z. B. jede IoT-Vorrichtung 1302 eine bestimmte Funktion und bestimmte Kommunikationspartner hat. Die IoT-Vorrichtungen 1302, die die Fog-Vorrichtung bilden, können jedoch auch in einem deklarativen Programmierstil konfiguriert werden, der es den IoT-Vorrichtungen 1302 erlaubt, ihren Betrieb und ihre Kommunikation neu zu konfigurieren, etwa um benötigte Ressourcen zu bestimmen, in Reaktion auf Bedingungen, Abfragen und Ausfall von Vorrichtungen. Als Beispiel kann eine Abfrage von einem Benutzer, der an einem Server 1306 angesiedelt ist, zum Betrieb einer Teilmenge von Ausrüstung, die durch die IoT-Vorrichtungen 1302 überwacht wird, dazu führen, dass die Fog 1320 -Vorrichtung die IoT-Vorrichtungen 1302, etwa bestimmte Sensoren 1328, auswählt, die zur Beantwortung der Abfrage benötigt werden. Die Daten von diesen Sensoren 1328 können dann durch eine beliebige Kombination der Sensoren 1328, Datenaggregatoren 1326 oder Netzübergänge 1304 aggregiert und analysiert werden, bevor sie von der Fog 1320 -Vorrichtung an den Server 1306 weitergesendet werden, um die Anfrage zu beantworten. In diesem Beispiel können die IoT-Vorrichtungen 1302 im Fog 1320 die Sensoren 1328 auswählen, die verwendet werden, basierend auf der Abfrage, etwa Hinzufügen von Daten von Durchflusssensoren oder Temperatursensoren. Ferner können, wenn einige der IoT-Vorrichtungen 1302 nicht in Betrieb sind, andere IoT-Vorrichtungen 1302 in der Fog 1320 -Vorrichtung analoge Daten bereitstellen soweit verfügbar.
  • Aus dem Vorstehenden wird ersichtlich, dass die oben offenbarten Verfahren, Einrichtungen und Erzeugnisse die Ausführung eines Sicherheitsprotokolls in einem durch hierarchische Zustandsautomaten gesteuerten Ausführungsplan ermöglichen. Beispielsweise wird hier die sichere Ausführung von Sicherheitsprotokollen in einem autonomen, zielorientierten IoT-Ausführungsplan offenbart und beschrieben.
  • In der verteilten Datenverarbeitung können verschiedene Vorrichtungen orchestriert (z. B. zum Zusammenarbeiten konfiguriert) werden. Eine Orchestrierung oder ein Ausführungsplan für die Vorrichtungen dient dazu sicherstellen zu helfen, dass die Vorrichtungen miteinander kommunizieren können und bei der Ausführung der Befehle ordnungsgemäß zusammenarbeiten. Falls jedoch das verteilte System und/oder einzelne Computervorrichtungen in einem unbekannten Zustand verharren (z. B. wenn eine Ausführung fehlschlägt, die Zeitsteuerung fehlerhaft ist und/oder anderweitig keine Synchronisation zwischen den Vorrichtungen erfolgt usw.), wird der Betrieb nicht-deterministisch und kann in einen ungeplanten Zustand eintreten.
  • Zur Behebung dieses gefährlichen Mangels und zur Verbesserung der verteilten Computertechnologie (z. B. im Internet der Dinge usw.) wird ein sicherer Ausführungsplan erzeugt und als hierarchischer Zustandsautomat bereitgestellt, der ausführbar gestellt wird, um die Befehlsausführung gemäß darin enthaltenen Zuständen, Übergängen zwischen Zuständen, zugehörigen Verhalten usw. zu steuern. Integrierte Schutzbedingungen wie Sicherheitskontext, Schlüsselverwaltung und/oder andere Beschränkungen helfen sicherzustellen, dass das System während der Ausführung des Programms nicht in einen nichtdeterministischen Zustand eintritt.
  • Durch Verwendung eines Berechtigungsnachweis-Verwaltungsdienstes und eines Zugangsverwaltungsdienstes kann ein Sicherheitsziel angewandt werden, um Berechtigungsnachweis-Verwaltung und Zugangskontrolle für ankommende Daten durchzuführen. Verwaltungsverhalten läuft parallel zur Befehlsausführung, um einen Sicherheitskontext-Eingang in den Ausführungsplan zu erzeugen. Sicherheitsverwaltung kann dadurch gesteuert werden, dass ein hierarchischer Zustandsautomat, der Schlüsselverwaltung, Zugangsverwaltung usw. definiert, in Datenflüsse definiert wird, um einen sicheren, zuverlässigen Programmausführungsfluss der Software bereitzustellen.
  • Statt separater Ausführungs- und Sicherheitsflüsse sind die Flüsse integriert. Damit werden Ausführung und Verhalten sowohl robuster als auch beschleunigt. Darüber hinaus können Analyse-Tools ein System untersuchen, um zu bestimmen, ob Sicherheitsprobleme für ein ganzes Protokoll vorliegen. Anstelle von Annahmen hinsichtlich Integrationspunkten zwischen Flüssen werden Flüsse als Ganzes in einem HSM konstruiert, um zu ermöglichen, dass Protokolle integriert und gemäß einem HSM-Modell evaluiert werden.
  • Schutzbedingungen stellen Kriterien für das Eintreten in einen Zustand und/oder das Verlassen eines solchen sowie für das Bereitstellen von Sicherheit auf, basierend auf einem Authentifizierungsschlüssel und/oder einem anderen Berechtigungsnachweis sowie einer Zugangskontrollrichtlinie, die auf Eingänge und/oder Ausgänge eines Zustands angewandt wird. Eingehende und/oder ausgehende Zugangskontrolle ist in das ausführbare HSM-Modell und den zugehörigen Ausführungsplan integriert. Ein solches Modell/ein solcher Plan kann auf eine Vielzahl verschiedener Flüsse, etwa einen Publish/Subscribe-Befehls-/Datenfluss, einen Anfrage-/Antwortfluss, einen Anwendungsprogrammierschnittstellen (API)-Fluss usw., für einer Reihe verschiedener Daten in einem verteilten System aus Vorrichtungen wie etwa IoT-Vorrichtungen usw. zur Anwendung kommen.
  • Somit stellen einige Beispiele eine Schlüsselverwaltung mit Sicherheitseigenschaften bereit, einschließlich einer deterministischen Programmzustandsausführung, Unfähigkeit zum Eintreten in einen unbekannten oder unbestimmten Zustand, Fähigkeit zum Rücksetzen in einen bekannten Zustand im Fall einer Fehlfunktion usw. Da Sicherheit und sonstige Befehlsausführung in einem HSM-Ausführungsplan integriert sind, ist das gesamte System als sicher zu betrachten. Der Ausführungsplan ist deshalb deterministisch, weil er über die Zeit serialisiert ist, wie in den Beispielen von 5-7 gezeigt, die eine serialisierte Darstellung des HSM über die Zeit zeigen.
  • Beispiel 1 weist eine Einrichtung mit einem Sicherheitsmanager auf, um einen Sicherheitsdienst mit einem Befehlsausführungsfluss in einer verteilten Vorrichtungsumgebung zu integrieren. Der beispielhafte Sicherheitsmanager soll einen Prozessor aufweisen, der dafür ausgelegt ist, wenigstens einen ausführbaren hierarchischen Zustandsautomaten zum Bereitstellen einer Berechtigungsnachweisverwaltung und Zugangsverwaltung in Verbindung mit einer Befehlsausführung gemäß einem Ausführungsplan zu implementieren. Der ausführbare hierarchische Zustandsautomat erzeugt einen Sicherheitskontext für den Ausführungsplan, um eine Schutzbedingung zu implementieren, die einen Übergang von einem ersten Zustand in einen zweiten Zustand gemäß dem Ausführungsplan regelt.
  • Beispiel 2 beinhaltet Beispiel 1, wobei der erste Zustand einen Eingangszustand beinhaltet und der zweite Zustand einen Ausgangszustand beinhaltet.
  • Beispiel 3 beinhaltet Beispiel 2, wobei der Ausführungsplan ein Verhalten des Empfangens eines Eingangs vom ersten Zustand beinhaltet, um einen Ausgang beim zweiten Zustand zu erzeugen.
  • Beispiel 4 beinhaltet Beispiel 3, wobei das Verhalten ein erstes Verhalten ist und wobei der Ausgang einen Eingang zum zweiten Verhalten bildet.
  • Beispiel 5 beinhaltet Beispiel 1, wobei der Sicherheitskontext die Durchsetzung von Schlüsselverwaltungs- und Zugangskontrollrichtlinien bereitstellt.
  • Beispiel 6 beinhaltet Beispiel 1, wobei die Schutzbedingung als ein Zustandsabhängigkeits-Tupel ausgedrückt ist, das einen oder mehrere vorherige Zustände beschreibt, von denen ein aktueller Zustand abhängt.
  • Beispiel 7 beinhaltet Beispiel 1, wobei eine Nichterfüllung der Schutzbedingung eine Rücksetzung in einen sicheren Zustand auslöst.
  • Beispiel 8 beinhaltet Beispiel 1, wobei der Ausführungsplan gemäß einem Publish-Subscribe-Modell implementiert ist und wobei Veröffentlicher und Abonnenten Informationen bezüglich eines Eingangs und/oder eines Ausgangs gemäß einem Abonnement empfangen.
  • Beispiel 9 beinhaltet Beispiel 8, wobei das Abonnement einen Eingangsfluss, einen Parameterfluss und/oder einen Ausgangsfluss beinhaltet.
  • Beispiel 10 beinhaltet eines oder mehrere der Beispiele 1-9, wobei der Ausführungsplan ein Distributed-Ledger implementieren soll.
  • Beispiel 11 beinhaltet Beispiel 10, wobei das Distributed-Ledger eine Blockchain beinhaltet.
  • Beispiel 12 beinhaltet Beispiel 11, wobei die Blockchain einen elektronischen Vertrag beinhaltet.
  • Beispiel 13 beinhaltet ein greifbares computerlesbares Speichermedium, das computerlesbare Befehle umfasst, welche bei Ausführung einen Prozessor veranlassen, wenigstens einen Sicherheitsmanager zu implementieren, um einen Sicherheitsdienst mit einem Befehlsausführungsfluss in einer verteilten Vorrichtungsumgebung zu integrieren. Der Sicherheitsmanager soll einen ausführbaren hierarchischen Zustandsautomaten zum Bereitstellen einer Berechtigungsnachweisverwaltung und Zugangsverwaltung in Verbindung mit einer Befehlsausführung gemäß einem Ausführungsplan implementieren. Der ausführbare hierarchische Zustandsautomat erzeugt einen Sicherheitskontext für den Ausführungsplan, um eine Schutzbedingung zu implementieren, die einen Übergang von einem ersten Zustand in einen zweiten Zustand gemäß dem Ausführungsplan regelt.
  • Beispiel 14 beinhaltet Beispiel 13, wobei der erste Zustand einen Eingangszustand beinhaltet und der zweite Zustand einen Ausgangszustand beinhaltet.
  • Beispiel 15 beinhaltet Beispiel 14, wobei der Ausführungsplan ein Verhalten des Empfangens eines Eingangs vom ersten Zustand beinhaltet, um einen Ausgang beim zweiten Zustand zu erzeugen.
  • Beispiel 16 beinhaltet Beispiel 15, wobei das Verhalten ein erstes Verhalten ist und wobei der Ausgang einen Eingang zum zweiten Verhalten bildet.
  • Beispiel 17 beinhaltet Beispiel 13, wobei der Sicherheitskontext die Durchsetzung von Schlüsselverwaltungs- und Zugangskontrollrichtlinien bereitstellt.
  • Beispiel 18 beinhaltet Beispiel 13, wobei die Schutzbedingung als ein Zustandsabhängigkeits-Tupel ausgedrückt ist, das einen oder mehrere vorherige Zustände beschreibt, von denen ein aktueller Zustand abhängt.
  • Beispiel 19 beinhaltet Beispiel 13, wobei eine Nichterfüllung der Schutzbedingung eine Rücksetzung in einen sicheren Zustand auslöst.
  • Beispiel 20 beinhaltet Beispiel 13, wobei der Ausführungsplan gemäß einem Publish-Subscribe-Modell implementiert ist und wobei Veröffentlicher und Abonnenten Informationen bezüglich eines Eingangs und/oder eines Ausgangs gemäß einem Abonnement empfangen.
  • Beispiel 21 beinhaltet Beispiel 20, wobei das Abonnement einen Eingangsfluss, einen Parameterfluss und/oder einen Ausgangsfluss beinhaltet.
  • Beispiel 22 weist ein Verfahren auf, um einen Sicherheitsdienst mit einem Befehlsausführungsfluss in einer verteilten Vorrichtungsumgebung zu integrieren. Das Verfahren beinhaltet das Erzeugen, durch Ausführen eines Befehls mit einem Prozessor, eines Sicherheitskontextes zum Implementieren einer Schutzbedingung. Das Verfahren beinhaltet das Bereitstellen, durch Ausführen eines Befehls mit dem Prozessor, des Sicherheitskontextes an einen hierarchischen Zustandsautomaten, um die Schutzbedingung zu implementieren, die einen Übergang von einem ersten Zustand in einen zweiten Zustand gemäß dem Ausführungsplan regelt. In dem Verfahren stellt der Prozessor einen ausführbaren hierarchischen Zustandsautomaten mit Berechtigungsnachweisverwaltung und Zugangsverwaltung in Verbindung mit Befehlsausführung gemäß dem Ausführungsplan bereit.
  • Beispiel 23 beinhaltet Beispiel 22, das ferner das Ausführen, als Teil des Ausführungsplans, eines Verhaltens basierend auf einem Eingang beinhaltet, der bei einem ersten Zustand empfangen wird, um einen Ausgang bei einem zweiten Zustand zu erzeugen.
  • Beispiel 24 beinhaltet Beispiel 22, wobei der Ausführungsplan gemäß einem Publish-Subscribe-Modell implementiert ist und wobei Veröffentlicher und Abonnenten Informationen bezüglich eines Eingangs und/oder eines Ausgangs gemäß einem Abonnement empfangen.
  • Beispiel 25 beinhaltet Beispiel 24, wobei das Abonnement einen Eingangsfluss, einen Parameterfluss und/oder einen Ausgangsfluss beinhaltet.
  • Beispiel 26 beinhaltet Beispiel 22 und beinhaltet ferner, bei Nichterfüllung der Schutzbedingung eine Rücksetzung in einen sicheren Zustand zu veranlassen.
  • Beispiel 27 beinhaltet eine Einrichtung, die ein Mittel zum Erzeugen eines Sicherheitskontext zum Implementieren einer Schutzbedingung aufweist; und ein Mittel zum Bereitstellen des Sicherheitskontextes an einen hierarchischen Zustandsautomaten, um eine Schutzbedingung zu implementieren, die einen Übergang von einem ersten Zustand in einen zweiten Zustand gemäß dem Ausführungsplan regelt.
  • Auch wenn in der vorliegenden Patentschrift gewisse beispielhafte Verfahren, Einrichtungen und Erzeugnisse offenbart werden, ist der Schutzbereich der vorliegenden Patentanmeldung nicht auf diese beschränkt. Die vorliegende Patentanmeldung erstreckt sich im Gegenteil auf sämtliche Verfahren, Einrichtungen und Erzeugnisse, die billigerweise in den Schutzbereich der Patentansprüche fallen.

Claims (15)

  1. Einrichtung, umfassend: einen Sicherheitsmanager (222) zum Integrieren eines Sicherheitsdienstes mit einem Befehlsausführungsfluss in einer verteilten Vorrichtungsumgebung, wobei der Sicherheitsmanager (222) aufweist: einen Prozessor (302, 1012), der dafür ausgelegt ist, wenigstens Folgendes zu implementieren: einen ausführbaren hierarchischen Zustandsautomaten (700) zum Bereitstellen einer Berechtigungsnachweisverwaltung und Zugangsverwaltung in Verbindung mit einer Befehlsausführung gemäß einem Ausführungsplan, wobei der ausführbare hierarchische Zustandsautomat (700) einen Sicherheitskontext für den Ausführungsplan erzeugen soll, um eine Schutzbedingung zu implementieren, die einen Übergang von einem ersten Zustand in einen zweiten Zustand gemäß dem Ausführungsplan regelt.
  2. Einrichtung nach Anspruch 1, wobei der erste Zustand einen Eingangszustand beinhaltet und der zweite Zustand einen Ausgangszustand beinhaltet.
  3. Einrichtung nach Anspruch 2, wobei der Ausführungsplan ein Verhalten des Empfangens eines Eingangs von einem ersten Zustand beinhaltet, um einen Ausgang beim zweiten Zustand zu erzeugen.
  4. Einrichtung nach Anspruch 3, wobei das Verhalten ein erstes Verhalten ist und wobei der Ausgang einen Eingang zu einem zweiten Verhalten bildet.
  5. Einrichtung nach Anspruch 1, wobei der Sicherheitskontext die Durchsetzung von Schlüsselverwaltungs- und Zugangskontrollrichtlinien bereitstellt.
  6. Einrichtung nach Anspruch 1, wobei die Schutzbedingung als ein Zustandabhängigkeits-Tupel ausgedrückt ist, das einen oder mehrere vorherige Zustände beschreibt, von denen ein aktueller Zustand abhängt.
  7. Einrichtung nach Anspruch 1, wobei eine Nichterfüllung der Schutzbedingung eine Rücksetzung in einen sicheren Zustand auslöst.
  8. Einrichtung nach Anspruch 1, wobei der Ausführungsplan gemäß einem Publish-Subscribe-Modell implementiert ist und wobei Veröffentlicher und Abonnenten Informationen bezüglich eines Eingangs und/oder eines Ausgangs gemäß einem Abonnement empfangen.
  9. Einrichtung nach Anspruch 8, wobei das Abonnement einen Eingangsfluss, einen Parameterfluss und/oder einen Ausgangsfluss beinhaltet.
  10. Einrichtung nach einem oder mehreren der Ansprüche 1-9, wobei der Ausführungsplan ein Distributed-Ledger implementieren soll.
  11. Einrichtung nach Anspruch 10, wobei das Distributed-Ledger eine Blockchain beinhaltet.
  12. Einrichtung nach Anspruch 11, wobei die Blockchain einen elektronischen Vertrag beinhaltet.
  13. Verfahren (800, 900) zum Integrieren eines Sicherheitsdienstes mit einem Befehlsausführungsfluss in einer verteilten Vorrichtungsumgebung, wobei das Verfahren (800, 900) umfasst: Erzeugen, durch Ausführen eines Befehls mit einem Prozessor (302, 1012), eines Sicherheitskontextes zum Implementieren einer Schutzbedingung (812); Bereitstellen, durch Ausführen eines Befehls mit dem Prozessor (302, 1012), des Sicherheitskontextes an einen hierarchischen Zustandsautomaten (700), um eine Schutzbedingung zu implementieren, die einen Übergang von einem ersten Zustand in einen zweiten Zustand gemäß einem Ausführungsplan (814, 816, 818) regelt, wobei der Prozessor (302, 1012) einen ausführbaren hierarchischen Zustandsautomaten (700) mit Berechtigungsnachweisverwaltung und Zugangsverwaltung in Verbindung mit Befehlsausführung gemäß dem Ausführungsplan (818) bereitstellt.
  14. Verfahren (800, 900) nach Anspruch 13, das ferner das Ausführen, als Teil des Ausführungsplans, eines Verhaltens basierend auf einem Eingang, der bei einem ersten Zustand empfangen wird, beinhaltet, um einen Ausgang bei einem zweiten Zustand (912) zu erzeugen.
  15. Greifbares computerlesbares Speichermedium mit darauf gespeicherten Anweisungen, die bei Ausführung eine Maschine zum Durchführen des Verfahrens nach einem der Ansprüche 13-14 veranlassen.
DE102019103927.4A 2018-03-30 2019-02-15 Systeme und Verfahren zur Ausführung eines Sicherheitsprotokolls in einem durch hierarchische Zustandsautomaten gesteuerten Ausführungsplan Pending DE102019103927A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/941,206 2018-03-30
US15/941,206 US10938856B2 (en) 2018-03-30 2018-03-30 Systems and methods for security protocol execution in a hierarchical state machine-driven execution plan

Publications (1)

Publication Number Publication Date
DE102019103927A1 true DE102019103927A1 (de) 2019-10-17

Family

ID=65230722

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019103927.4A Pending DE102019103927A1 (de) 2018-03-30 2019-02-15 Systeme und Verfahren zur Ausführung eines Sicherheitsprotokolls in einem durch hierarchische Zustandsautomaten gesteuerten Ausführungsplan

Country Status (2)

Country Link
US (2) US10938856B2 (de)
DE (1) DE102019103927A1 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10938856B2 (en) * 2018-03-30 2021-03-02 Intel Corporation Systems and methods for security protocol execution in a hierarchical state machine-driven execution plan
US11122052B2 (en) * 2018-05-30 2021-09-14 International Business Machines Corporation Sensitive information accessibility in blockchain
WO2020144022A1 (en) * 2019-01-09 2020-07-16 British Telecommunications Public Limited Company Probabilistic shared secret validation
CN110007597B (zh) * 2019-04-01 2022-04-05 上海电气泰雷兹交通自动化系统有限公司 状态轮询和事件驱动软件状态机设计模式的优化方法
US11654635B2 (en) 2019-04-18 2023-05-23 The Research Foundation For Suny Enhanced non-destructive testing in directed energy material processing
US11551216B2 (en) 2019-05-01 2023-01-10 Sony Corporation Transaction security on distributed-ledger based MaaS platform
US11146594B2 (en) 2019-05-31 2021-10-12 Seagate Technology Llc Security incident blockchain
US11941625B2 (en) * 2019-06-04 2024-03-26 Jpmorgan Chase Bank, N.A. Systems and methods for real-time classification and verification of data using hierarchal state machines
US11196759B2 (en) 2019-06-26 2021-12-07 Microsoft Technology Licensing, Llc SIEM system and methods for exfiltrating event data
CN111325442A (zh) * 2020-01-09 2020-06-23 清华大学 实战型动态消防应急预案系统
CN115037807B (zh) * 2022-06-10 2023-08-18 湖南大学 一种工业机器人服务总线上集成dds协议的方法及系统

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6408262B1 (en) * 1998-03-27 2002-06-18 Iar Systems A/S Method and an apparatus for analyzing a state based system model
US6324496B1 (en) * 1998-06-18 2001-11-27 Lucent Technologies Inc. Model checking of hierarchical state machines
EP1594279A1 (de) * 2004-05-07 2005-11-09 Hewlett-Packard Development Company, L.P. Zugangskontrolle in einer world-wide-Anwendung mittels eines Ereignisfilters
US7877727B2 (en) * 2006-08-18 2011-01-25 Bitrouter Hierarchical state programming with a markup language
US8255384B2 (en) * 2009-09-30 2012-08-28 Fujitsu Limited Client-tier validation of dynamic web applications
US20120195200A1 (en) * 2011-01-31 2012-08-02 Joe Regan Method and apparatus for hierarchical policing
US20170287090A1 (en) * 2016-03-31 2017-10-05 Clause, Inc. System and method for creating and executing data-driven legal contracts
US10938856B2 (en) * 2018-03-30 2021-03-02 Intel Corporation Systems and methods for security protocol execution in a hierarchical state machine-driven execution plan

Also Published As

Publication number Publication date
US20190044976A1 (en) 2019-02-07
US10938856B2 (en) 2021-03-02
US20220021708A1 (en) 2022-01-20
US11799911B2 (en) 2023-10-24

Similar Documents

Publication Publication Date Title
DE102019103927A1 (de) Systeme und Verfahren zur Ausführung eines Sicherheitsprotokolls in einem durch hierarchische Zustandsautomaten gesteuerten Ausführungsplan
Ravidas et al. Access control in Internet-of-Things: A survey
DE112019003309T5 (de) Vorrichtung für einen sicheren sendungsempfang mit delegierungskette
DE112018006630T5 (de) Visual fog
DE112017006994T5 (de) Bereitstellung und verwaltung von microservices
CN107534568B (zh) 用于网络策略的合成约束
DE102015113054A1 (de) Sichern von Vorrichtungen bei Prozesssteuerungssystemen
DE102014113582B4 (de) Vorrichtung, Verfahren und System für die kontextbewusste Sicherheitssteuerung in einer Cloud-Umgebung
DE102017124866A1 (de) Gesicherte Prozesssteuerkommunikationen
DE112017007393T5 (de) System und verfahren für netzwerkvorrichtungssicherheits- und vertrauenswertbestimmung
CN105282160B (zh) 基于信誉的动态访问控制方法
DE102012203561A1 (de) Die Personifikation/Bevollmächtigung eines Benutzers in einem Merkmal-basierenden Authentifizierungssystem
DE112016002392T5 (de) Autorisierung in einem verteilten System unter Verwendung von Zugriffssteuerungslisten und Gruppen
DE102022114391A1 (de) Suchdienst in einem softwaredefinierten Steuerungssystem
DE102022114541A1 (de) Suchdienst in einem softwaredefinierten steuerungssystem
DE102022114267A1 (de) Systeme und verfahren zur dynamischen aufrechterhaltung der redundanz und des lastausgleichs in softwaredefinierten steuerungssystemen für industrielle prozessanlagen
DE102014219472A1 (de) Verfahren zum Übertragen von Daten, Netzknoten und Netzwerk
DE102022114306A1 (de) E/a-serverdienste, die so konfiguriert sind, dass sie die steuerung in einer prozesssteuerungsumgebung durch containerisierte steuerungsdienste erleichtern
DE102022114375A1 (de) Sicherheitsdienste in einem softwaredefiniertensteuerungssystem
DE102022114543A1 (de) Systeme und verfahren zur zuordnung von modulen in einem softwaredefinierten steuerungssystem für industrielle prozessanlagen
DE102022114250A1 (de) Systeme und Verfahren zur hierarchischen Organisation von softwaredefinierten Prozesssteuerungssystemen für industrielle Prozessanlagen
DE102022115178A1 (de) Visualisierung eines softwaredefinierten prozesssteuerungsstems für industrielle prozessanlagen
DE102020201885A1 (de) Technologien für beschleunigtes hierarchisches schlüssel-caching in edge-systemen
EP4154070A1 (de) Digital-twin basierte prozesssteuerung in einem iot-netzwerk
WO2020043581A1 (de) Blockbildungs-einrichtung und -verfahren, knoteneinrichtung und blockbestätigungs-verfahren