Beschreibung

Verfahren und Ausführungsumgebung zum Ausführen von Programm code auf einem Feldgerät

Die Erfindung bezieht sich auf ein Verfahren und eine Ausfüh rungsumgebung zum Ausführen von Programmcode auf einem Feld gerät .

Der Schutz von Geräten vor Manipulation ist, insbesondere bei industriellen und bei Safety-relevanten Steuergeräten (z. B. Feldgeräte) oder bei industriellen Datenaustauschgateways o- der bei einem IoT-Edge-Connector-Gerät (IoT: Internet der Dinge), ein hohes Schutzziel. Speziell Linux-basierte Geräte kommen hierbei regelmäßig zum Einsatz. Weiterhin werden sol che Steuergeräte immer häufiger vernetzt und bieten somit ei ne größere Angriffsfläche für das Einschleusen von schadhaf ter Software oder für die Manipulation von bestehender Soft ware .

Insbesondere Steuergeräte, welche eine Funktion für nachlad baren Programmcode, z. B. Applikationen (Apps) , unterstützen, sind einem erhöhten Risiko ausgesetzt. Zum einen können der nachgeladenen Programmcode Schadcode oder sicherheitskriti sche Fehler enthalten.

Weiterhin kann auch die Ausführungsumgebung, z. B. die Lauf zeitumgebung, für den Programmcode als Ziel für einen Angriff verwendet werden, um den Programmcode selbst zu kompromittie ren .

Container-Technologien (z. B. Docker, runC, CoreOS rkt oder LXC) werden häufig im Zusammenhang mit dynamisch nachladbaren Applikationen in Linux-basierten Systemen verwendet. Die Laufzeitumgebung für Container-Applikationen (Container-Apps) wird dabei durch die Virtualisierung von globalen Ressourcen (z.B. Basis-Filesystem, Netzwerkinterfaces des Gerätes) er zeugt . Aktuell gibt es keine effiziente und vielseitige Methode, um schadhafte Änderungen am Programmcode zu erkennen und um da rauf zu reagieren, besonders solche, die während der Laufzeit eines Feldgerätes oder Steuergerätes auftreten. Diese können beispielsweise eine Anbindung an ein IoT-Backend realisieren. Auch ein IoT-Gateway oder allgemein ein Datenaustauschgateway zum Austausch von Industriedaten kann beispielsweise ein Steuergerät im Sinne der vorliegenden Erfindung.

Aus dem Stand der Technik sind das Dokument US 8,531,247 B2 , das Dokument US 8,892,616 B2, das Dokument US 8,300,811 B2, das Dokument US 9,147,088 B2 , das Dokument US 9584311 B2 , das Dokument EP 2976707 Bl, das Dokument EP 2 605 445 Bl, das Do kument EP 2 870 565 Al, das Dokument EP 2 891 102 Al, das Do kument WO 2017137256 Al, das Dokument EP 2870565 Bl, das Do kument EP 3028140 Bl, das Dokument EP 17175275 und das Doku ment US 8 843 761 B2 bekannt. Außerdem kennt man das Dokument US 2013/326216 Al.

Eine Aufgabe der vorliegenden Erfindung ist es, ein Verfahren und eine Ausführungsumgebung bereitzustellen, die Programm code sicher auf Feldgeräten bzw. Steuergeräten ausführt.

Die Aufgabe wird durch die in den unabhängigen Ansprüchen an gegebenen Merkmale gelöst. In den abhängigen Ansprüchen sind vorteilhafte Weiterbildungen der Erfindung dargestellt.

Ein erster Aspekt der Erfindung betrifft eine Ausführungsum gebung zum Ausführen von Programmcode auf einem Steuergerät aufweisend :

einen Funktionsspeicher, der zum Speichern von Überprü fungsfunktionen eingerichtet ist;

einen Konfigurationsspeicher, der zum Speichern von Aus führungsanforderungen für Überprüfungsbereiche einge richtet ist,

wobei der Konfigurationsspeicher mittels eines Ma nipulationserkennungsmoduls geschützt ist, und wobei die Ausführungsanforderungen in einem Konfi gurationsmodus der Ausführungsumgebung konfiguriert wer den können;

eine Ausführungseinheit,

wobei die Überprüfungsbereiche zumindest einer von

dem Programmcode,

zumindest einem ersten Teil der Programmbefeh le des Programmcodes

der Ausführungsumgebung und/oder der Ausführungseinheit sind;

wobei den Überprüfungsbereichen mittels der Ausfüh rungsanforderungen die Überprüfungsfunktionen zuge ordnet sind,

wobei die Ausführungseinheit eingerichtet ist, mit tels der Überprüfungsfunktionen ein Prüfergebnis zu ermitteln, das angibt ob der jeweilige Überprü fungsbereich die Ausführungsanforderungen erfüllt, wobei die Ausführungseinheit eingerichtet ist, den jeweiligen Programmbefehl und/oder Programmcode ab hängig vom Prüfergebnis auszuführen.

Sofern es in der nachfolgenden Beschreibung nicht anders an gegeben ist, beziehen sich die Begriffe "durchführen", "be rechnen", "rechnergestützt", "rechnen", "feststellen", "gene rieren", "konfigurieren", "rekonstruieren" und dergleichen vorzugsweise auf Handlungen und/oder Prozesse und/oder Verar beitungsschritte, die Daten verändern und/oder erzeugen und/oder die Daten in andere Daten überführen, wobei die Da ten insbesondere als physikalische Größen dargestellt werden oder vorliegen können, beispielsweise als elektrische Impul se. Insbesondere sollte der Ausdruck "Computer" möglichst breit ausgelegt werden, um insbesondere alle elektronischen Geräte mit Datenverarbeitungseigenschaften abzudecken. Compu ter können somit beispielsweise Personal Computer, Server, speicherprogrammierbare Steuerungen (SPS) , Handheld-Computer- Systeme, Pocket-PC-Geräte, Mobilfunkgeräte und andere Kommu nikationsgeräte, die rechnergestützt Daten verarbeiten kön- nen, Prozessoren und andere elektronische Geräte zur Daten verarbeitung sein.

Unter „rechnergestützt" kann im Zusammenhang mit der Erfin dung beispielsweise eine Implementierung des Verfahrens ver standen werden, bei dem insbesondere ein Prozessor mindestens einen Verfahrensschritt des Verfahrens ausführt.

Unter einem „Prozessor" kann im Zusammenhang mit der Erfin dung beispielsweise eine Maschine oder eine elektronische Schaltung verstanden werden. Bei einem Prozessor kann es sich insbesondere um einen Hauptprozessor (engl. Central Proces sing Unit, CPU), einen Mikroprozessor oder einen Mikrocon troller, beispielsweise eine anwendungsspezifische integrier te Schaltung oder einen digitalen Signalprozessor, möglicher weise in Kombination mit einer Speichereinheit zum Speichern von Programmbefehlen, etc. handeln. Bei einem Prozessor kann es sich beispielsweise auch um einen IC (integrierter Schalt kreis, engl. Integrated Circuit), insbesondere einen FPGA (engl. Field Programmable Gate Array) oder einen ASIC (anwen dungsspezifische integrierte Schaltung, engl. Application- Specific Integrated Circuit), oder z. B. ein Multi-Chip- Modul, z. B. ein 2 , 5D oder 3D Multi -Chip-Modul , bei dem ins besondere mehrere sogenannte Dies direkt oder über einen In- terposer miteinander verbunden sind oder einen DSP (Digitaler Signalprozessor, engl. Digital Signal Processor) oder einen Grafikprozessor GPU (Graphic Processing Unit) handeln. Auch kann unter einem Prozessor ein virtualisierter Prozessor, ei ne virtuelle Maschine oder eine Soft-CPU verstanden werden.

Es kann sich beispielsweise auch um einen programmierbaren Prozessor handeln, der mit Konfigurationsschritten zur Aus führung des genannten erfindungsgemäßen Verfahrens ausgerüs tet wird oder mit Konfigurationsschritten derart konfiguriert ist, dass der programmierbare Prozessor die erfindungsgemäßen Merkmale des Verfahrens, der Komponente, der Module, oder an derer Aspekte und/oder Teilaspekte der Erfindung realisiert. Unter einer „Speichereinheit" oder „Speichermodul" und der gleichen kann im Zusammenhang mit der Erfindung beispielswei se ein flüchtiger Speicher in Form von Arbeitsspeicher (engl. Random-Access Memory, RAM) oder ein dauerhafter Speicher wie eine Festplatte oder ein Datenträger oder z. B. ein wechsel bares Speichermodul verstanden werden.

Unter einem „Modul" kann im Zusammenhang mit der Erfindung beispielsweise ein Prozessor und/oder eine Speichereinheit zum Speichern von Programmbefehlen verstanden werden. Bei spielsweise ist der Prozessor speziell dazu eingerichtet, die Programmbefehle derart auszuführen, damit der Prozessor Funk tionen ausführt, um das erfindungsgemäße Verfahren oder einen Schritt des erfindungsgemäßen Verfahrens zu implementieren oder realisieren.

Unter einer „Prüfsumme" kann im Zusammenhang mit der Erfin dung beispielsweise eine kryptographische Prüfsumme oder kryptographischer Hash bzw. Hashwert verstanden werden, die insbesondere mittels einer kryptographisehen Hashfunktion ge bildet oder berechnet werden. Weiterhin kann darunter insbe sondere auch eine digitale Signatur oder ein kryptographi - scher Nachrichtenauthentisierungscode verstanden werden.

Unter „extern" kann im Zusammenhang mit der Erfindung bei spielsweise verstanden werden, dass z. B. eine Komponente (z. B. Modul oder Einheit) kein integraler Bestandteil einer an deren entsprechenden Komponente ist. Ist etwas beispielsweise extern von einem Prozessor so ist diese entsprechende Kompo nente kein integraler Bestandteil des Prozessors.

Unter „Ausführungsanforderungen" können im Zusammenhang mit der Erfindung beispielsweise Sicherheitsanforderungen an die Ausführungsumgebung oder den Programmcode bzw. an die Pro grammbefehle des Programmcodes verstanden werden.

Unter „Ausführungsumgebung" kann im Zusammenhang mit der Er findung beispielsweise ein Gerät oder eine Vorrichtung sein, die derart eingerichtet sind, einen Programmcode auszuführen. Hierzu kann das Gerät oder die Vorrichtung beispielsweise ei nen Prozessor aufweisen, der den Programmcode ausführt. Die Ausführungseinheit kann beispielsweise selbst in Software o- der in Hardware realisiert sein. Die Ausführungseinheit er möglicht beispielsweise die Ausführung von Programmcode.

Das Gerät kann beispielsweise einen Aktor umfassen, der z. B. über den Programmcode gesteuert wird. Eine Ausführungsumge bung kann beispielsweise auch ein Betriebssystem sein oder ein Betriebssystem umfassen. Eine Ausführungsumgebung kann beispielsweise eine Laufzeitumgebung (z. B. eine Java virtual Machine mit Klassenbibliotheken oder eine modifizierte Vari ante davon) sein oder eine Laufzeitumgebung (z. B. eine Java virtual Machine mit Klassenbibliotheken oder eine modifizier te Variante davon) umfassen. Weiterhin kann es sich bei spielsweise bei einer Laufzeitumgebung um die Gesamtheit der von Benutzerapplikationen verwendeten Ressourcen (z. B. ande re ausführbare Programmdateien im Dateisystem, vorhandene Netzwerkinterfaces , Interprozesskommunikationsmechanismen) handeln. Eine Ausführungsumgebung kann beispielsweise eine Container-Ausführungsumgebung, z.B. Docker oder runC oder ei ne modifizierte Variante davon sein oder umfassen.

Unter „Programmcode" kann im Zusammenhang mit der Erfindung beispielsweise eine Applikation und/oder ein Programm

und/oder Programmbefehle und/oder eine App und/oder ein Con tainer-Image und/oder eine Container-App verstanden werden. Linux Container, z.B. Docker oder runC, ermöglichen bei spielsweise die Ausführung eines Container-Abbilds (Contai ner-Image) und der darin enthaltenen Software in einer iso lierten Ausführungsumgebung. Container können beispielsweise verwendet werden, um flexibel unterschiedliche Funktionalität auf einem Steuergerät bzw. Feldgerät auszuführen. Ein Contai ner bzw. das Container- Image wird beispielsweise daher auch als Container-App bezeichnet, da sich auf Basis von Contai nern eine App-Funktionalität realisieren lässt. Apps lassen sich beispielsweise aber auch z.B. mit einer Java Virtual Ma chine realisieren.

Unter einem „Steuergerät" kann im Zusammenhang mit der Erfin dung beispielsweise ein Feldgerät, eine Fertigungsmaschine oder ein Steuergerät für ein Energieversorgungsnetz gemeint sein .

Die Erfindung ist insbesondere dahingehend vorteilhaft, um z. B. eine Konfigurierbarkeit und Realisierung einer Methode für die Verifizierung der Laufzeitumgebung von Programmcode zu realisieren, bevor in dieser der Programmcode bzw. Programm befehle des Programmcodes ausgeführt werden. Die Erfindung kann beispielsweise in den Kernel eines Betriebssystems inte griert werden, so dass die Erfindung insbesondere ein integ rales Element des Betriebssystem-Kernels bildet. Zusätzlich ist die Erfindung beispielsweise dahingehend vorteilhaft, um aktiv in die Einrichtung einer Ausführungsumgebung für Pro grammcode einzugreifen.

Vorteilhaft ist beispielsweise darüber hinaus, dass Programm code mit einer erhöhten Sicherheit ausgeführt werden können, da z. B. das Starten eines Programmcodes mit einer manipu lierten (zur Laufzeit oder Offline) Ausführungsumgebung stark erschwert wird. Dies wird z. B. dadurch erreicht, dass die Überprüfung im Gegensatz zu bekannten Methoden vor jedem Starten eines entsprechenden Programmcodes oder Programmbe fehlen durchgeführt wird.

Zudem kann die Erfindung beispielsweise in den Betriebssys tem-Kernel integriert werden und somit vor kompromittierten, privilegierten Prozessen besser geschützt werden. Zudem kann die Erfindung beispielsweise auch verwendet werden um schon laufenden Programmcode über Veränderungen mittels Steuerfunk tionen zu benachrichtigen oder anderweitig zu reagieren.

Bei einer weiteren Ausführungsform der Ausführungsumgebung legen die Ausführungsanforderungen Ressourcen oder vorgegebe- ne Programmbefehle fest, deren Ausführung oder deren Verwen dung unzulässig sind.

Die Ausführungsumgebung ist dahingehend vorteilhaft, um ins besondere kritische Befehle oder Zugriffe auf Ressourcen zu unterbinden, deren Zugriff ein hohes Sicherheitsrisiko birgt. Beispielsweise kann ein Zugriff auf Programmdaten der Ausfüh rungsumgebung gesperrt werden oder Programmbefehle gesperrt werden, die einen Prozess auf einer unerlaubten Berechti gungsstufe ausführen (z. B. mit Root-Rechten) .

Bei einer weiteren Ausführungsform der Ausführungsumgebung legen die Ausführungsanforderungen Ressourcen oder vorgegebe ne Programmbefehle fest deren Ausführung oder deren Verwen dung zulässig sind.

Die Ausführungsumgebung ist dahingehend vorteilhaft, um ins besondere nur die Ressourcen oder Programmbefehle zuzulassen, die für den Betrieb des Steuergerätes tatsächlich notwendig sind. Die Ausführungsumgebung ist beispielsweise weiterhin dahingehend vorteilhaft, um insbesondere nur die Ressourcen oder Programmbefehle zuzulassen, die für die Ausführung einer App auf einem Steuergerätes tatsächlich notwendig sind.

Bei einer weiteren Ausführungsform der Ausführungsumgebung legen die Ausführungsanforderungen für Ressourcen Zustände für die Ausführung des Programmcodes oder der jeweiligen Pro grammbefehle fest .

Die Ausführungsumgebung ist dahingehend vorteilhaft, um bei spielsweise für die Ausführungsumgebung und/oder die Ausfüh rungseinheit einen vorgegebenen Zustand zu fordern, der für eine sichere Ausführung des Programmcodes erforderlich ist. Als Zustand kann beispielsweise eine bestimmte Version der Ausführungseinheit (z. B. der Laufzeitumgebung) bzw. derer Programmbibliotheken gefordert sein. Es kann beispielsweise auch gefordert sein, dass bestimmte Ressourcen (Passwörter, kryptographische Schlüssel, Algorithmen mit firmenspezifi - schem Know-How) verschlüsselt sind oder vor und nach deren Nutzung verschlüsselt werden. Die Ausführungsumgebung bzw. die Ausführungseinheit überprüfen beispielsweise, ob die An forderungen an die Zustände erfüllt sind. Abhängig von dem Prüfergebnis werden z. B. der Programmcode bzw. die jeweili gen Programbefehle ausgeführt (wenn die Anforderungen erfüllt sind) oder die Ausführung wird unterbunden (wenn die Anforde rungen nicht erfüllt sind) . Unter einem Zustand kann bei spielsweise auch ein Zustand des Steuergerätes und eines sei ner Komponenten verstanden werden. Beispielsweise kann gefor dert werden, dass ein Aktor sich in einer bestimmten Aus gangsposition befindet, bevor die Programmbefehle ausgeführt werden. Wird beispielsweise festgestellt, dass der gewünschte Zustand nicht gegeben ist, kann die Ausführungseinheit oder Ausführungsumgebung mittels Steuerbefehlen den gewünschten Zustand hersteilen. Ist dies beispielsweise nicht möglich, kann eine Ausführung des Programmcodes oder der entsprechen den Programbefehle z. B. unterbunden werden.

Bei einer weiteren Ausführungsform der Ausführungsumgebung geben die Ausführungsanforderungen eine Prüfsumme für den Programmcode und/oder die Programmbefehle und/oder die Aus führungsumgebung und/oder die Ausführungseinheit vor.

Die Ausführungsumgebung ist dahingehend vorteilhaft, um ins besondere den Programmcode dahingehend zu überprüfen, ob die ser verändert wurde. Hierzu bildet dann die Ausführungsein heit bzw. die Ausführungsumgebung z. B. eine weitere Prüfsum me über den Programmcode bzw. die entsprechenden Programmbe fehle und vergleicht diese weitere Prüfsumme mit der Prüfsum me die durch die Ausführungsanforderungen vorgegeben ist.

Die Ausführungsumgebung bzw. die Ausführungseinheit ver gleicht beispielsweise, ob die beiden Prüfsummen übereinstim men. Abhängig von dem Vergleichsergebnis werden z. B. der Programmcode bzw. die jeweiligen Programmbefehle ausgeführt (wenn die Prüfsummen identisch sind) oder die Ausführung wird unterbunden (wenn die Prüfsummen abweichen) . Bei einer weiteren Ausführungsform der Ausführungsumgebung wird das Prüfergebnis zumindest zum Teil anhand der zugeord neten Überprüfungsfunktionen ermittelt.

Die Ausführungsumgebung ist dahingehend vorteilhaft, um ins besondere spezifische Überprüfungsfunktionen mit den entspre chenden zu überprüfenden Ausführungsanforderungen zu nutzen. Beispielsweise kann so eine Funktion ausgeführt werden, die eine Prüfsumme für den Programmcode umfasst oder einen Funk tionstest des Steuergerätes ausführt, um festzustellen, ob das Gerät ordnungsgemäß funktioniert.

Bei einer weiteren Ausführungsform der Ausführungsumgebung ist der Konfigurationsspeicher mittels eines Manipulationser kennungsmoduls geschützt.

Die Ausführungsumgebung ist dahingehend vorteilhaft, um kri tische Daten im Konfigurationsspeicher vor einer Manipulation zu schützen. Das Manipulationserkennungsmodul kann dabei bei spielsweise auf unterschiedliche Weise realisiert sein. Bei spielsweise kann es sich hierbei um mechanische und/oder elektrische Sicherheitseinheiten handeln. Dies ist z. B. eine Bohrschutzfolie, die bei einer Beschädigung die sensiblen Da ten des entsprechenden Konfigurationsspeichers löscht. Alter nativ oder zusätzlich kann es sich beispielsweise auch um ein schwer zu öffnendes Gehäuse des Speichers handeln, da bei spielsweise das Gehäuse aus Stahl gefertigt ist und zuge schweißt ist. Alternativ oder zusätzlich kann es sich bei spielsweise auch um eine elektromagnetische Abschirmung han deln um Seitenkanalangriffe auf den Konfigurationsspeicher zu unterbinden. Der Konfigurationsspeicher kann insbesondere in einer Variante Tampersensoren, z. B. Gehäuseschalter, Schwin gungssensoren, Temperatursensoren, Lichtsensoren, Strahlungs sensoren oder ein extern bereitgestelltes Tamperalarmsignal auswerten. Es ist beispielsweise auch möglich, dass die Aus führungsumgebung oder das Steuergerät auf die gleiche Weise mit einem analog ausgebildeten Manipulationserkennungsmodul gesichert bzw. dieses umfasst. Bei einer weiteren Ausführungsform der Ausführungsumgebung können die Ausführungsanforderungen in einem Konfigurations modus der Ausführungsumgebung konfiguriert werden.

Die Ausführungsumgebung ist dahingehend vorteilhaft, um ins besondere nur bzw. exklusiv in diesem Konfigurationsmodus die Ausführungsanforderungen konfigurieren zu können. Der Konfi gurationsmodus kann beispielsweise durch eine Eingabe eines Passwortes an der Ausführungsumgebung bzw. an dem Steuergerät eingeschaltet werden. Alternativ oder zusätzlich kann eine kryptographische Sicherung vorgesehen sein, bei der z. B. ein Anwender zum Konfigurieren sich z. B. mittels eines Sicher heitstoken (z. B. Smart-Card, USB-Token) authentisieren muss.

Bei einer weiteren Ausführungsform der Ausführungsumgebung überprüfen die Überprüfungsfunktionen die Ausführungsumgebung anhand der Ausführungsanforderungen und das Prüfergebnis wird zumindest zum Teil anhand des Überprüfens der Ausführungsum gebung ermittelt.

Die Ausführungsumgebung ist dahingehend vorteilhaft, um bei spielsweise mehrere unterschiedliche Prüfungen und Anforde rungen parallel durchzuführen. Die Ergebnisse der Einzelprü fungen gehen dann beispielsweise in das Prüfergebnis ein. Der Programmcode und/oder die Programmbefehle werden z. B. nur dann ausgeführt, wenn zumindest eine vorgegebene Anzahl von Einzelprüfungen erfolgreich war und/oder eine vorgegebene An zahl von Einzelprüfungen mit einem vorgegenen Sicherheitsni veau erfolgreich durchgeführt wurde. Alternativ oder zusätz lich kann z. B. auch gefordert werden, dass vorgegebene kri tische Einzelprüfungen erfolgreich sind und nur ein Teil von vorgegebenen weniger kritischen Einzelprüfungen erfolgreich geprüft werden müssen.

Bei einer weiteren Ausführungsform der Ausführungsumgebung wird eine Steuerfunktion ausgeführt, wenn eine Prüfung der Ausführungsanforderungen für den Programmcode oder einen der jeweiligen Programmbefehle fehlschlägt. Dabei legen bei spielsweise die Ausführungsanforderungen die jeweilige Steu erfunktion fest, wobei die Steuerfunktionen beispielsweise im Funktionsspeicher gespeichert sind.

Die Ausführungsumgebung ist dahingehend vorteilhaft, um bei spielsweise zu konfigurieren, wie die Ausführungsumgebung sich verhalten soll, wenn die Ausführungsanforderungen nicht erfüllt sind. Wurde beispielsweise festgestellt, dass der Programmcode manipuliert wurde (z. B. eine Prüfsummenüberprü- fung ist fehlgeschlagen), kann so das Steuergerät z. B. in einen sicheren Zustand versetzt werden, der keine weitere Ausführung von Programmcode zulässt, der insbesondere den Zu griff auf festgelegte Ressourcen (z. B. externe Interfaces) einschränkt und/oder es wird ein zuständiger Wartungstechni ker über ein Steuersignal oder Alarmsignal benachrichtigt.

Gemäß einem weiteren Aspekt betrifft die Erfindung ein Ver fahren zum rechnergestützten Ausführen eines Programmcodes auf einem Steuergerät mit folgenden Verfahrensschritten:

Speichern von Überprüfungsfunktionen;

Speichern von in einem Konfigurationsmodus der Ausfüh rungsumgebung konfigurierbaren Ausführungsanforderungen für Überprüfungsbereiche Überprüfungsbereiche in einem mittels eines Manipulationserkennungsmoduls geschützten KonfigurationsSpeicher,

wobei die Überprüfungsbereiche zumindest einer von dem Programmcode,

zumindest einem ersten Teil der Programmbefeh le des Programmcodes,

einer Ausführungsumgebung und/oder

einer Ausführungseinheit sind;

den Überprüfungsbereichen mittels der Ausführungs anforderungen die Überprüfungsfunktionen zugeordnet werden;

Ermitteln eines Prüfergebnisses mittels der Überprü fungsfunktionen, das angibt ob die Überprüfungsbereiche die Ausführungsanforderungen erfüllen, Ausführen des jeweiligen Programmbefehls und/oder des Programmcodes abhängig vom Prüfergebnis.

Bei einer weiteren Ausführungsform oder mehreren weiteren Ausführungsformen des Verfahrens umfasst das Verfahren zumin dest ein weiteres Merkmal oder mehrere weitere Merkmale, um Ausführungsformen (z. B. funktionale Merkmale) der Ausfüh rungsumgebung analog nachzubilden.

Des Weiteren wird ein Computerprogrammprodukt mit Programmbe fehlen zur Durchführung der genannten erfindungsgemäßen Ver fahren beansprucht, wobei mittels des Computerprogrammpro dukts jeweils eines der erfindungsgemäßen Verfahren, alle er findungsgemäßen Verfahren oder eine Kombination der erfin dungsgemäßen Verfahren durchführbar ist.

Zusätzlich wird eine Variante des Computerprogrammproduktes mit Programmbefehlen zur Konfiguration eines Erstellungsge räts, beispielsweise ein 3D-Drucker, ein Computersystem oder ein zur Erstellung von Prozessoren und/oder Geräten geeignete Herstellungsmaschine, beansprucht, wobei das Erstellungsgerät mit den Programmbefehlen derart konfiguriert wird, dass die erfindungsgemäße Ausführungsumgebung erstellt wird.

Darüber hinaus wird eine Bereitstellungsvorrichtung zum Spei chern und/oder Bereitstellen des Computerprogrammprodukts be ansprucht. Die Bereitstellungsvorrichtung ist beispielsweise ein Datenträger, der das Computerprogrammprodukt speichert und/oder bereitstellt. Alternativ und/oder zusätzlich ist die Bereitstellungsvorrichtung beispielsweise ein Netzwerkdienst, ein Computersystem, ein Serversystem, insbesondere ein ver teiltes Computersystem, ein cloudbasiertes Rechnersystem und/oder virtuelles Rechnersystem, welches das Computerpro grammprodukt vorzugsweise in Form eines Datenstroms bereit stellt und speichert.

Diese Bereitstellung erfolgt beispielsweise als Download in Form eines Programmdatenblocks und/oder Befehlsdatenblocks, vorzugsweise als Datei, insbesondere als Downloaddatei, oder als Datenstrom, insbesondere als Downloaddatenstrom, des vollständigen Computerprogrammprodukts. Diese Bereitstellung kann beispielsweise aber auch als partieller Download erfol gen, der aus mehreren Teilen besteht und insbesondere über ein Peer-to-Peer Netzwerk heruntergeladen oder als Datenstrom bereitgestellt wird. Ein solches Computerprogrammprodukt wird beispielsweise unter Verwendung der Bereitstellungsvorrich tung in Form des Datenträgers in ein System eingelesen und führt die Programmbefehle aus, sodass das erfindungsgemäße Verfahren auf einem Computer zur Ausführung gebracht wird o- der das Erstellungsgerät derart konfiguriert, dass es die er findungsgemäße Ausführungsumgebung erstellt.

Die oben beschriebenen Eigenschaften, Merkmale und Vorteile dieser Erfindung sowie die Art und Weise, wie diese erreicht werden, werden klarer und deutlicher verständlich im Zusam menhang mit der folgenden Beschreibung der Ausführungsbei spiele, die im Zusammenhang mit den Figuren näher erläutert werden. Dabei zeigen in schematischer Darstellung:

Fig. 1 ein erstes Ausführungsbeispiel der Erfindung;

Fig. 2 ein zweites Ausführungsbeispiel der Erfindung;

Fig. 3 ein drittes Ausführungsbeispiel der Erfindung;

In den Figuren sind funktionsgleiche Elemente mit denselben Bezugszeichen versehen, sofern nichts anderes angegeben ist.

Die nachfolgenden Ausführungsbeispiele weisen, sofern nicht anders angegeben oder bereits angegeben, zumindest einen Pro zessor und/oder eine Speichereinheit auf, um das Verfahren zu implementieren oder auszuführen.

Auch sind insbesondere einem (einschlägigen) Fachmann in Kenntnis des/der Verfahrensanspruchs/Verfahrensansprüche alle im Stand der Technik üblichen Möglichkeiten zur Realisierung von Produkten oder Möglichkeiten zur Implementierung selbst verständlich bekannt, sodass es insbesondere einer eigenstän digen Offenbarung in der Beschreibung nicht bedarf. Insbeson dere können diese gebräuchlichen und dem Fachmann bekannten Realisierungsvarianten ausschließlich per Hard

ware (komponenten) oder ausschließlich per Soft

ware (komponenten) realisiert werden. Alternativ und/oder zu sätzlich kann der Fachmann im Rahmen seines fachmännischen Könnens weitestgehend beliebige erfindungsgemäße Kombinatio nen aus Hardware (komponenten) und Software (komponenten) wäh len, um erfindungsgemäße Realisierungsvarianten umzusetzen.

Eine erfindungsgemäße Kombination aus Hardware (komponenten) und Software (komponenten) kann insbesondere dann eintreten, wenn ein Teil der erfindungsgemäßen Wirkungen vorzugsweise ausschließlich durch Spezialhardware (z. B. einem Prozessor in Form eines ASIC oder FPGA) und/oder ein anderer Teil durch die (prozessor- und/oder speichergestützte) Software bewirkt wird .

Insbesondere ist es angesichts der hohen Anzahl an unter schiedlichen Realisierungsmöglichkeiten unmöglich und auch für das Verständnis der Erfindung nicht zielführend oder not wendig, all diese Realisierungsmöglichkeiten zu benennen. In sofern sollen insbesondere all die nachfolgenden Ausführungs beispiele lediglich beispielhaft einige Wege aufzeigen, wie insbesondere solche Realisierungen der erfindungsgemäßen Leh re aussehen könnten.

Folglich sind insbesondere die Merkmale der einzelnen Ausfüh rungsbeispiele nicht auf das jeweilige Ausführungsbeispiel beschränkt, sondern beziehen sich insbesondere auf die Erfin dung im Allgemeinen. Entsprechend können vorzugsweise Merkma le eines Ausführungsbeispiels auch als Merkmale für ein ande res Ausführungsbeispiel dienen, insbesondere ohne dass dies expliziet in dem jeweiligen Ausführungsbeispiel genannt sein muss . Die Fig. 1 zeigt ein erstes Ausführungsbeispiel der Erfin dung. Im Einzelnen ist dabei eine Ausführungsumgebung zum Ausführen von Programmcode auf einem Steuergerät gezeigt. Ein Steuergerät kann beispielsweise ein Feldgerät sein, eine speicherprogrammierbare Steuerung, eine Steuereinheit, eine Überwachungseinheit, ein Schutzschalter, eine Safety- Überwachung, ein industrielles Datenaustauschgateway oder ein IoT-Gateway. Ein Steuergerät wird in einem Automatisierungs system zur Überwachung und/oder Steuerung eines technischen Prozesses verwendet, z.B. einer Werkzeugmaschine, einer Pro duktionsanlage, einer verfahrenstechnischen Anlage, eines Energieverteilnetzes, eines Energietransportnetzes, eines Kraftwerks, eines Bahnleitsystems , eines Zugsicherungssystem, einer Gebäudeautomatisierung, eines Medizingeräts, eines au tonomen Fahrzeugs oder ähnlich verwendet.

Die Ausführungsumgebung umfasst einen Funktionsspeicher 120, einen Konfigurationsspeicher 110 und eine Ausführungseinheit 140. Zudem kann die Ausführungsumgebung ein Speichermodul 150 umfassen und einen Programmspeicher 130 umfassen. Der Pro grammspeicher 130 kann derart ausgebildet sein den Programm code oder mehrere Programmcodes in Form von Container Appli kationen zu speichern. Der Programmspeicher 130 kann zudem noch ein Programmcode-Management-Modul umfassen. Darüber hin aus kann die Ausführungseinheit 140 beispielsweise als Kernel eines Betriebssystems ausgebildet sein oder ein Teil eines solchen Kernels sein. Entsprechend kann die Ausführungsein heit 140 weitere Kernelressourcen und/oder Steuergeräteres sourcen umfassen oder eine Schnittstelle oder ein Management- Modul, das einen Zugriff auf diese erlauben kann. Der Pro grammspeicher 130 kann z. B. als Flash-Speicher ausgebildet sein. Der Programmcode kann direkt im Programmspeicher ausge führt werden, oder der im Programmspeicher gespeicherte Pro grammcode kann zur Ausführung in einen Arbeitsspeicher ko piert werden und dort ausgeführt werden.

Der Funktionsspeicher 120 ist zum Speichern von einer oder mehreren Überprüfungsfunktionen eingerichtet. Der Konfigurationsspeicher 110 ist zum Speichern von Ausfüh rungsanforderungen für Überprüfungsbereiche eingerichtet .

Die Überprüfungsbereiche sind dabei :

der Programmcode und/oder

zumindest ein erster Teil der Programmbefehle des Programmcodes und/oder

die Ausführungsumgebung und/oder

die Ausführungseinheit;

Ein Teil der Programmbefehle bedeutet dabei insbesondere, dass bestimmten Programmbefehlen (z. B. Zugriff auf das Da teisystem oder Ressourcen des Gerätes) entsprechende Ausfüh rungsanforderungen zugeordnet sind.

Insbesondere werden den Überprüfungsbereichen der Ausfüh rungsumgebung oder des Programmcodes die jeweiligen Ausfüh rungsanforderungen zugeordnet .

Insbesondere werden den Überprüfungsbereichen mittels der Ausführungsanforderungen die Überprüfungsfunktionen zugeord net .

Die Ausführungseinheit 140 ist dazu eingerichtet mittels der Überprüfungsfunktion ein Prüfergebnis zu ermitteln, das an gibt, ob ein jeweiliger Überprüfungsbereich die Ausführungs anforderungen erfüllt.

Die Ausführungseinheit 140 ist zudem dazu eingerichtet, den jeweiligen Programmbefehl und/oder Programmcode abhängig vom Prüfergebnis auszuführen.

Die Erfindung ist dazu geeignet, eine Integrität einer Aus führungsumgebung für Container-Applikationen zu schützen. Die Ausführungsumgebung kann dabei z. B. als Laufzeitumgebung für Container implementiert sein. Dies ist dahingehend vorteil haft, wenn ein Programmcode (z. B. eine Container-Applikation oder nur kurz Container) auf einem industriellen Feldgerät verwendet wird, um insbesondere das Nachladen und Aktualisie ren von einzelnen Gerätefunktionen zu unterstützen. Dies kann beispielsweise auch als App-Technologie bezeichnet werden.

In industriellen Umgebungen besteht ein besonders hoher Be darf, die Geräteintegrität, z. B. eines Steuergerätes, zu schützen. Unter einem Steuergerät kann hierbei insbesondere ein Feldgerät oder andere Geräte im industriellen Umfeld ver standen werden. Bei diesen Geräten besteht das Problem, dass häufig Patches nicht zeitnah eingespielt werden. Außerdem werden Apps (auch als Container oder Programmcode) im Allge meinen nur selten geladen oder aktualisiert, z. B. nur bei der Erstinbetriebnahme oder in einem definierten Wartungs fenster. Daher sind die aus dynamischen, agilen Cloud- Umgebungen bekannten Lösungen zum Schutz von Container- Umgebungen für diese Umgebung nicht anwendbar.

Mit der Erfindung kann die Integrität der Ausführungsumgebung für den Prorammcode vor dem Starten des Programmcodes auf dem Gerät (das den Programmcode ausführen soll) geprüft werden. Die erfindungsgemäße Ausführungsumgebung kann dabei auch als Container Runtime Verification Mechanism - CRVM genannt wer den .

Die Prüfung kann beispielsweise bei jedem Starten eines Pro grammcodes (z. B. einer Container-App) erfolgen, nur beim Starten von vorgegebenen Programmcodes (z. B. vorgegebene Container-Apps) , nur beim ersten Starten eines Programmcodes, oder beim erstmaligen Starten einer Container-App nach einem Geräteneustart. Weiterhin kann die Prüfung wiederholt zu vor gegebenen Zeitpunkten oder innerhalb vorgegebener Intervalle erfolgen, z. B. einmal täglich. Dies ist insbesondere bei Container-Apps vorteilhaft, die dauerhaft oder langandauernd laufen .

In einer Variante wird dazu die Container-App gegenüber einer Container-Zulässigkeitspolicy (Whitelist, Blacklist) geprüft. Diese kann eine ganze Container-App betreffen oder einzelne Software-Komponenten einer Container-App . Der Container wird nur gestartet, wenn die Prüfung ergibt, dass die Container- App bzw. deren Komponenten zulässig sind. Diese Prüfung ist vorzugsweise als Betriebssystem-Kernel-Funktion realisiert. Der erfindungsgemäße CRVM umfasst einen Satz an Funktionen (z. B. die Überprüfungsfunktionen), die der Kernel vor si- cherheitskritischen Operationen ausführt, die speziell zur Einrichtung und dem Starten von Containern verwendet werden. Durch die Überprüfungsfunktionen wird dann anhand der Ausfüh rungsanforderungen (z. B. eine CRVM-Konfiguration oder eine Policy) durch die Ausführungseinheit geprüft, ob ein entspre chender Teil der Laufzeitumgebung einen zulässigen, gewünsch ten Zustand besitzt. Beispielsweise kann ein solcher „Hook" vor dem Einrichten des für den Container sichtbaren root- Filesystems verwendet werden, um die Integrität des Filesys tems zu verifizieren, z. B. durch Berechnung einer kryptogra- phischen Prüfsumme über die Filesystem- Inhalte und dem an schließenden Abgleich mit einem in der Policy eingetragenen Wert. Hierzu kann zu einem sicheren Zeitpunkt bzw. beim er stellen der Ausführungsanforderungen eine entsprechende Refe renzprüfsumme für die Filesystem- Inhalte erzeugt und gespei chert werden. Wird später die Ausführungsanforderung über prüft wird eine erneute Prüfsumme über die Filesystem- Inhalte berechnet und mit der Referenzprüfsumme verglichen. Das Er gebnis dieses Vergleichens wird dann im Prüfergebnis gespei chert .

Fig. 1 zeigt insbesondere eine Ausführungsumgebung, die in einem Steuergerät, z. B. einem Embedded Gerät, installiert ist .

Hier sind die Überprüfungsfunktionen beispielsweise Teil des Kernel - Images . Die Ausführungsanforderungen können in einer Variante während des Bootvorgangs aus dem Filesystem in einen nur dem Kernel zugänglichen Teil des Arbeitsspeichers gela den. In einer anderen Variante ist diese statisch und somit in das Kernel-Image eingebettet. In den Ausführungsanforde rungen wird festgelegt, welche Teile der Ausführungsumgebung (Laufzeitumgebung) von den entsprechenden Überprüfungsfunkti onen überprüft bzw. verifiziert werden.

Das gezeigte Ausführungsbeispiel kann z. B. in den entspre chenden Ausführungsanforderungen einen Integritätsreferenz - wert (z. B. ein Hash-Wert) für den gespeicherten Programmcode (z. B. ein Container Basis-Images) umfassen. Mit anderen Wor ten findet also ein Whitelisting statt. Der Kernel lädt und startet einen Programmcode (z. B. einen Container) nur dann, wenn der Container einschließlich seiner Ausführungsumgebung gemäß den Ausführungsanforderungen zulässig ist. Dadurch wird gewährleistet, dass nur gemäß den Ausführungsanforderungen zulässige Container-Apps gestartet werden können, und nur in Kombination mit einer zulässigen Ausführungsumgebung. Es wird also die Kombination des durch die Container-App definierten Programmcodes und einem weiteren Programmcode der Ausfüh rungsumgebung auf Zulässigkeit geprüft. Da die Ausführungsan forderungen unabhängig vom Dateisystem und Dateisystemberech tigungen und -attributen verwaltet werden, kann der erfin dungsgemäße Schutz nicht durch eine Manipulation des Dateisy stems umgangen werden. Selbst wenn also kein integritätsge schütztes Dateisystem verwendet wird, ist der erfindungsgemä ße Schutzmechanismus wirksam. Dies hat den Vorteil, dass die Erfindung mit einem beliebigen Dateisystem verwendet werden kann, z. B. auch mit einem schreibbaren Dateisystem oder ei nem Wechselmedium (SDCard) . Es ist jedoch in einer Variante auch möglich, ein schreibgeschütztes oder integritätsge schütztes Dateisystem gemeinsam mit der erfindungsgemäßen Lö sung zu verwenden.

Mit der Erfindung können beispielsweise der Inhalt von Soft ware- und Konfigurationsdaten, Berechtigungen der Ausfüh rungsumgebung geprüft werden. Weiterhin kann überprüft wer den, dass die gemäß der Ausführungsanforderungen (z. B. eine Whitelist-Policy) zulässigen Inhalte vorhanden sind und keine zusätzlichen Dateien. Startet das Programmcode-Management-Modul einen Programmcode (z. B. einen Container), so wird die Operation zum Einrichten (z. B. „Mounten") des Container-Filesystems durch eine ent sprechende Überprüfungsfunktion (z. B. auch als Hook bezeich net) unterbrochen. Dabei kann das Container-Filesystem z. B. ein bestimmter Speicherbereich des Speichermoduls 150 sein, der dem entsprechenden Programmcode für einen Container zuge ordnet ist und/oder diesen umfasst. Das Programmcode- Management-Modul kann dabei z. B. als Container Management Software mit Hilfe von Docker oder runC auf einem Linux basierten System realisiert werden.

Anschließend wird z. B. eine Prüfsumme (z. B. ein Hashwert) für die entsprechenden Daten des Container-Filesystems be rechnet und mit der Referenzprüfsumme in den entsprechenden Ausführungsanforderungen (Whitelist) verglichen. Nur bei ei ner Übereinstimmung dieser Prüfsummen wird dann beispielswei se die Operation erlaubt und der Startvorgang des Containers fortgeführt .

Die Entscheidung liegt somit im Kernel und ist daher schwie riger zu manipulieren als in gängigen Technologien.

Die Ausführungsanforderungen (z. B. eine Container-App- Zulässigkeits-Policy) ist vorzugsweise nur in einer speziel len Betriebsart (z. B. einem Konfigurationsmodus) des Gerätes (z. B. ein Steuergerät) aktualisierbar. Im regulären operati ven Betriebsmodus des (Steuer- ) Gerätes ist sie dagegen unver änderbar. Sie kann z. B. in einer Variante nur dann aktuali siert werden, wenn das Gerät sich in einem Wartungsmodus be findet. Hierzu ist es beispielsweise erforderlich, dass sich ein Wartungstechniker, der die Ausführungsanforderungen aktu alisiert, sich gegenüber dem Gerät authentisiert (z. B. ein Passwort oder mittels einer Smart-Card und einer Pin) .

In einer weiteren Variante werden die Ausführungsanforderun gen (z. B. eine Policy) explizit konfiguriert, z. B. durch Laden einer Konfigurationsdatei. Diese kann z. B. von einem Projektierungstool, z.B. dem Siemens TIA-Portal, generiert werden .

In einer anderen Variante werden die Ausführungsanforderungen auf dem Gerät beim Beenden des Wartungsmodus des Gerätes ge neriert bzw. aktualisiert.

In einer weiteren Variante werden die Ausführungsanforderun gen beim Einspielen, Aktualisieren oder Löschen eines Pro grammcodes (z. B. eine Container-App) auf dem Gerät aktuali siert .

Die Erfindung kann insbesondere in Verbindung mit bestehenden Technologien zur Sicherung der Bootkette (z.B. Secure Boot, Measured Boot) verwendet werden. Somit wären auch die Ausfüh- rungsumgebungs-Komponenten des Kernels (z. B. die Überprü fungsfunktionen) in einem vertrauenswürdigen und integeren Zustand .

In einer weiteren Variante können die Überprüfungsfunktionen auch für die Verifizierung des Programmcode-Management -Moduls (z. B. die Container Management Software) und die von ihr be nutzen Ressourcen (Libraries, Binaries, Konfigurationsdatei en, etc.) verwendet werden, bevor diese ausgeführt wird. So können Container mit einer erhöhten Zuverlässigkeit richtig gestartet werden.

Die Konfiguration der Ausführungsumgebung umfasst dabei vor zugsweise in einer weiteren Variante zwei erfindungsgemäße Komponenten :

1. Konfiguration der Verifikation:

Die Ausführungsanforderungen können verwendet werden, um an zugeben, welche Teile der Laufzeitumgebung eines zu starten den Containers überprüft werden sollen.

In einer ersten Variante umfasst dies das Filesystem (dt. „Dateisystem") , auf dessen Basis das root-Filesystem des Con- tainers erzeugt wird. Die Überprüfung kann beispielsweise mittels einer kryptographisehen Prüfsumme erfolgen.

In einer weiteren Variante können auch virtualisierte Kernel- Level Ressourcen, welche Teile der neuen Ausführungsumgebung (z. B. eine Ausführungsumgebung) für den Container werden sollen, hinzugezogen werden.

Diese werden teilweise in einer Konfigurationsdatei für den jeweiligen Programmcode angegeben. Sollen beispielsweise die Firewall -Einstellungen für die Ausführungsumgebung des Con tainers eingerichtet werden, so wird die Einrichtung von ei ner entsprechenden Überprüfungsfunktionen unterbrochen und die Einrichtungsparameter für die Firewall mit denen in den Ausführungsanforderungen verglichen. So kann sichergestellt werden, dass die Einrichtung auf der Kernel -Ebene richtig durchgeführt wird. Versucht z. B. ein Angreifer, einen Pro grammcode (z. B. eine Container-App bzw. einen Container) mit veränderten Einstellungen zu starten, so wird dieses Verhal ten von der Ausführungsumgebung detektiert.

In der oben beschriebenen Variante wird ein Whitelist-Ansatz für die Ausführungsumgebung bzw. Überprüfung verfolgt.

In einer anderen Variante kann nach einem Blacklist-Prinzip gearbeitet werden. Beispielsweise kann mit einer entsprechen den Überprüfungsfunktion überprüft werden, ob einer von meh reren in der Ausführungsanforderungen aufgelisteten unzuläs sigen Zuständen eingerichtet werden soll.

Zudem kann die Ausführungsumgebung auch mit bestehenden Si- cherheitsmechanismen verbunden werden. In Linux-basierten Systemen kann z. B. verifiziert werden, ob eine Container-App in einer bestimmten SELinux Security-Domain ausgeführt, oder gewisse Privilegien (Linux capabilities) besitzt. Die Ausfüh rungsanforderungen können dabei sowohl lokale (für einzelne Container-Apps) , als auch globale Einstellungen (für alle Container-Apps) beinhalten. So kann z.B. sichergestellt wer- den, dass eine gestartete Container-App niemals gewisse Pri vilegien besitzen wird (z. B. die CAP_SYS_ADMIN capability) .

2. Konfiguration der Reaktion:

In den Ausführungsanforderungen kann die Reaktion auf eine fehlgeschlagene Verifikation festgelegt werden, z. B. wenn das Prüfergebnis ergibt, dass ein Programmcode nicht ausge führt werden darf. Im einfachsten Fall wird die Einrichtung des Containers unterbunden, möglicherweise im Zusammenhang mit der Bereitstellung eines Fehlersignals oder einem Log- Eintrag .

Eine weitere Möglichkeit umfasst die Fortführung des Start prozesses, allerdings unter veränderten, sicheren Bedingun gen. Mit anderen Worten wird der entsprechende Programmcode in einer sicheren Umgebung ausgeführt (z. B. eine abgesicher te virtuelle Maschine, die alle Programmbefehle (z. B. Opera tionen) virtuell durchführt und keine tatsächliche Ausführung der auf dem Gerät stattfindet) .

Die Ausführungsumgebung greift somit aktiv in die Einrichtung der Container-App ein. Stellt eine entsprechende Überprü fungsfunktion beispielsweise fest, dass die Container-App nicht in einer vorgegebenen SELinux Security-Domain ausge führt werden soll, so kann die Container-App in einer Art „Fallback"- oder „Default "-Domain ausgeführt und ein entspre chendes Warnsignal gesetzt werden. So kann beispielsweise ein möglicherweise bösartiges Verhalten der Container-App in ei ner sichereren Umgebung (Fallback-Domain) untersucht werden. Eine weitere Möglichkeit ist das Versetzen des gesamten Gerä tes in einen Idle- oder Error-Zustand .

In einer weiteren Variante können, je nach Art der Regelver letzung (also Verletzung der Ausführungsanforderungen) , auch andere, bereits laufende Container-Apps von einer möglichen Kompromittierung der Ausführungsumgebung betroffen und infor miert werden. Wird beispielsweise das (Basis- ) Filesystem für die Container von einem Angreifer manipuliert und im An- Schluss ein Container gestartet, so kann die Ausführungsumge bung entsprechend reagieren. Die möglichen Reaktionen ähneln hier denen, die bereits erwähnt wurden. Beispielsweise könn ten alle betroffenen Container in einen anderen, sicheren Zu stand versetzt, oder ihre Ausführung beendet werden. Die Aus führungsanforderungen können mit einem privaten Schlüssel signiert und beim Laden in den Kernel während des Bootvor gangs mit Hilfe eines in den Kernel statisch integrierten öf fentlichen Schlüssels verifiziert werden. Schlägt die Verifi kation fehl, kann der Bootvorgang z. B. abgebrochen werden. Die Ausführungsanforderungen können durch eine weitere, sig nierte Ausführungsanforderungen ersetzt oder aktualisiert werden, beispielsweise bei der Installation eines neuen Ba- sis-Filesystems , während sich das Gerät bereits im Feld be findet. Auch ohne die Möglichkeit, das Basis-Filesystem für Container-Apps zu aktualisieren, können Apps nachgeladen wer den, solange sie eines der bereits vorhandenen Basis- Filesysteme verwenden.

Die Fig. 2 zeigt ein weiteres Ausführungsbeispiel der Erfin dung. Im Einzelnen ist dabei eine Ausführungsumgebung zum Ausführen von Programmcode auf einem Steuergerät gezeigt.

Bei dem gezeigten Ausführungsbeispiel wird eine Kernel -level Ressource, in diesem Falle die Prozess-Datenstruktur 280 ei ner zu startenden Container-App, verifiziert. Das dargestell te Linux-System verwendet das SELinux Zugriffskontrollsystem, um Container-Apps in eingeschränkten Security-Domains auszu führen. Die SELinux Security-Domain ist in der SELinux-Policy definiert .

Die grundlegende Funktionsweise dieses Ausführungsbeispiel ist analog zu dem in Fig. 1 gezeigten Ausführungsbeispiel.

Die Ausführungsumgebung umfasst entsprechend einen Funktions speicher 120, einen Konfigurationsspeicher 110 und eine Aus führungseinheit 140. Zudem kann die Ausführungsumgebung ein Speichermodul 150 umfassen und einen Programmspeicher 130 um- fassen. Der Programmspeicher 130 kann derart ausgebildet sein, den Programmcode oder mehrere Programmcodes in Form von Container-Applikationen zu speichern. Der Programmspeicher 130 kann zudem noch ein Programmcode-Management-Modul umfas sen. Darüber hinaus kann die Ausführungseinheit 240 bei spielsweise als Kernel eines Betriebssystems ausgebildet sein oder ein Teil eines solchen Kernels sein. Entsprechend kann die Ausführungseinheit 240 weitere Kernelressourcen und/oder Steuergeräteressourcen umfassen oder eine Schnittstelle oder ein Management-Modul , das einen Zugriff auf diese erlauben kann. Die gezeigte Ausführungseinheit 240 umfasst beispiels weise eine Sicherheitspolicy 260 (z. B. eine SELinux Policy) und ein Zugriffskontrollsystem 270 (z. B. ein SELinux Modul) .

Die Ausführungsumgebung umfasst aus einer zur Bootzeit gela dene Ausführungsanforderungen, welche die Security-Domain für Container-Apps vorgibt. Zusätzlich werden die Überprüfungs funktionen durch LSM Module (LSM: Linux Security Modul) rea lisiert, welche mittels des LSM-Stacking Mechanismus hinter SELinux geschaltet sind. Versucht das Programmcode- Management-Modul des Programmspeichers 130 nun z. B. eine Container-App zu starten (1) , werden zunächst die entspre chenden Überprüfungsfunktionen (z. B. Hooks) des SELinux Mo duls und anschließend die Überprüfungsfunktionen des Funkti onsspeichers 120 aufgerufen, die durch die Ausführungsanfor derungen festgelegt wurden. Das SELinux Modul 270 ermittelt zunächst mit Hilfe der SELinux-Policy 260 die Security-Domain der Container-App (2) . Anschließend wird diese in der Kernel- Prozessdatenstruktur 280 festgelegt (3) . Wurde die SELinux- Policy beispielsweise durch einen Angreifer manipuliert, so könnte dies dazu führen, dass die Container-App nicht in ei ner eingeschränkten Security-Domain ausgeführt wird. Im An schluss an die SELinux-Überprüfungsfunktionen werden aller dings die entsprechenden Überprüfungsfunktionen des Funkti onsspeichers 120 aufgerufen. Diese verwenden die zugeordneten Ausführungsanforderungen um die erwartete SELinux Security- Domain der Container-App zu ermitteln (4) . Anschließend ver gleicht die Ausführungsumgebung oder die Ausführungseinheit diese mit der in der Prozess-Datenstruktur 280 gesetzten Do main (5) . Stimmen diese überein, wird der Startvorgang wei tergeführt. Entspricht die gesetzte Domain nicht der erwarte ten (bzw. durch die Ausführungsanforderungen vorgegebenen Werten), so wird der Startvorgang abgebrochen.

Die in Fig. 1 und Fig. 2 genannten Ausführungsumgebungen oder Geräte können beispielsweise zusätzlich noch eine weitere o- der mehrere weitere Komponente/n umfassen, wie beispielsweise einen Prozessor, eine Speichereinheit, weitere Kommunikati onsschnittstellen (z. B. Ethernet, WLAN) , ein Eingabegerät, insbesondere eine Computertastatur oder eine Computermaus, und ein Anzeigegerät (z. B. einen Monitor), und eine Ein- /Ausgabeeinheit zum Verbinden von Sensoren und/oder Aktoren. Der Prozessor kann beispielsweise mehrere weitere Prozessoren umfassen, die insbesondere zur Realisierung von weiteren Aus führungsbeispielen verwendet werden können. Die genannten Komponenten oder weitere/n Komponente/n können beispielsweise ebenfalls über einen Bus miteinander kommunikativ verbunden sein .

Bei dem Prozessor kann es sich beispielsweise um einen ASIC handeln, der anwendungsspezifisch für die Funktionen eines jeweiligen Moduls (oder einer Einheit) oder aller Module des Ausführungsbeispiels (und/oder weiterer Ausführungsbeispiele) realisiert wurde, wobei die Programmkomponente bzw. die Pro grammbefehle insbesondere als integrierte Schaltkreise reali siert sind. Bei dem Prozessor kann es sich beispielsweise auch um einen FPGA handeln, der insbesondere mittels der Pro grammbefehle derart konfiguriert wird, dass der FPGA die Funktionen eines jeweiligen Moduls oder aller Module des Aus führungsbeispiels (und/oder weiterer Ausführungsbeispiele) realisiert .

Die Fig. 3 zeigt ein weiteres Ausführungsbeispiel der Erfin dung . Im Einzelnen zeigt die Fig. 3 ein Ablaufdiagramm der Erfin dung, wobei die Erfindung als ein rechnergestütztes Verfahren implementiert wird.

Im Einzelnen wird in diesem Ausführungsbeispiel ein Verfahren zum rechnergestützten Ausführen eines Programmcodes auf einem Steuergerät realisiert.

Das Verfahren umfasst einen ersten Verfahrensschritt 310 zum Speichern von Überprüfungsfunktionen.

Das Verfahren umfasst einen zweiten Verfahrensschritt 320 zum Speichern von Ausführungsanforderungen für Überprüfungs- bereiche, wobei die Überprüfungsbereiche der Programmcode und/oder zumindest ein erster Teil der Programmbefehle des Programmcodes und/oder eine Ausführungsumgebung und/oder ei ne Ausführungseinheit sind.

Zudem werden die Überprüfungsbereiche mittels der Ausfüh rungsanforderungen den Überprüfungsfunktionen zugeordnet.

Das Verfahren umfasst einen dritten Verfahrensschritt 330 zum Ermitteln eines Prüfergebnisses mittels der Überprüfungsfunk tionen, das angibt ob die Überprüfungsbereiche die Ausfüh rungsanforderungen erfüllen.

Das Verfahren umfasst einen vierten Verfahrensschritt 340 zum Ausführen des jeweiligen Programmbefehls und/oder des Pro grammcodes abhängig vom Prüfergebnis.

Die Erfindung betrifft somit ein Verfahren und eine Ausfüh rungsumgebung, um beispielsweise auf Feldgeräten eine Ausfüh rung von manipuliertem Programmcode zu unterbinden bzw. eine Ausführung von Programmcode in einer manipulierten Ausfüh rungsumgebung zu unterbinden.

Obwohl die Erfindung im Detail durch die Ausführungsbeispiele näher illustriert und beschrieben wurde, ist die Erfindung nicht durch die offenbarten Beispiele eingeschränkt, und an dere Variationen können vom Fachmann hieraus abgeleitet wer den, ohne den Schutzumfang der Erfindung zu verlassen.