Fraunhofer-Gesellschaft zur Förderung der Angewandten Forschung e.V.

Fraunhofer AISEC

Datensouveränität im Internet der Dinge –Der Trusted Connector im Industrial Data SpaceDr. Julian Schütte, Gerd Brost, Sascha Wessel

Kapitel 1. Sicherheit im Industriellen Internet der Dinge

1 Sicherheit im Industriellen Internet der Dinge

Die Digitalisierung durchdringt alle Branchen und führt zu tiefgreifenden Veränderungen von Geschäftsmodellenund technischen Infrastrukturen. Insbesondere in Logistik und Produktion bietet die Vernetzung von Geräten undder Austausch von Daten über Unternehmensgrenzen hinweg die Chance, Abläufe zu beschleunigen, Kosten zureduzieren und Medienbrüche zu vermeiden. Das hierbei entstehende Industrielle Internet der Dinge (IIoT) bringtjedoch völlig neue Anforderungen an den Datenschutz und die Sicherheit der technischen Infrastrukturen mit sich.Diese Anforderungen adressiert die Initiative des „Industrial Data Space“ mit dem Trusted Connector.

Datenschutz Im industriellen Internet der Dinge (II-oT) werden Daten über Unternehmensgrenzen hinwegausgetauscht. Unternehmensgrenzen sind dabei auchmeist Vertrauensgrenzen, aus denen Daten herausge-geben werden. Hierzu zählen auch und insbesonderesensible Daten, aus denen sich Rückschlüsse über Ge-schäftsgeheimnisse ziehen lassen, wie beispielsweise An-gaben über verfügbare Produktionskapazitäten, Liefer-ketten oder Wartungsdaten von Sensoren. Aber auch per-sönliche Daten wie Bewegungsprofile oder Gesundheits-daten werden herangezogen und für Analysezwecke ver-arbeitet.

Zeitgleich sehen sich Unternehmen einer verschärften Da-tenschutzgesetzgebung gegenüber, nach der die Aus-kunft über den Verbleib persönlicher Daten und ihre Lö-schung auf Verlangen des Benutzers jederzeit möglichsein muss.

Um diesen Anforderungen gerecht zu werden, müssenArchitekturen für das Internet der Dinge die Herkunft vonDaten verfolgen und es Benutzern ermöglichen, nicht nurden Zugriff, sondern auch die Art und Weise der Verarbei-tung von Daten zu kontrollieren.

Sicherheit Wie die jüngste Vergangenheit gezeigt hat,sind eingebettete Systeme im Internet der Dinge häufigEinfallstor für Schadsoftware und Eintrittspunkt für ge-zielte Angriffe auf die interne Infrastruktur. Veraltete Soft-ware, das Fehlen von sicheren Update-Mechanismen so-wie die Langlebigkeit solcher Geräte lassen sie zu einemattraktiven Ziel für Angreifern werden.

Verwundbarkeiten lassen sich niemals völlig ausschlie-ßen. In heterogenen Infrastrukturen kommt jedoch dieHerausforderung hinzu, dass das Sicherheitsniveau einesKommunikationspartners initial vollkommen unbekanntist und zunächst ein gegenseitiges Vertrauen etabliertwerden muss. Hierzu ist es erforderlich, dass sich Kom-munikationspartner ihr technisches Sicherheitsniveau au-tomatisch nachweisen, so dass auf dieser Basis verlässlichbeurteilt werden kann, ob und welche Daten mit dem je-weiligen Kommunikationspartner geteilt werden dürfen.

Infrastrukturen für das industrielle Internet der Dinge

müssen daher einerseits Geräte unterschiedlicher Sicher-heitslevel zulassen, gleichzeitig jedoch Mechanismen an-bieten, über die Diensteanbieter die Verwendung ihrerDaten auf weniger sicheren Plattformen zuverlässig ein-schränken können.

Vertrauen Der Austausch von sensiblen Daten erfor-dert Vertrauen in die Teilnehmer, aber auch in die tech-nische Infrastruktur selbst. Die Tatsache, dass Low-Cost-Geräte wie Kameras oder Sensoren kompromittiert undfür Angriffe auf kritische IT-Infrastrukturen genutzt wer-den können, bedroht nicht nur die Sicherheit des Ge-samtsystems. Sie wirft auch die Frage auf, inwieweit Da-ten, die von solchen Geräten stammen, vertraut werdenkann und ob sie zuverlässig genug sind, um auf ihrer Basisautomatische Entscheidungen zu treffen. Datenaustauschüber Unternehmensgrenzen hinweg bedeutet meist auchDatenaustausch über die eigenen Vertrauensgrenzen hin-weg. Es sind daher Maßnahmen erforderlich, durch diedas Vertrauen in die Sicherheit der Komponenten im in-dustriellen Internet der Dinge nicht nur gesteigert, son-dern nachweisbar quantifizierbar wird. Erst durch eineautomatische und zuverlässige Attestierung des Sicher-heitsniveaus einer Komponente können Diensteanbieterentscheiden, ob sie Daten für diese Komponente freige-ben. Der Industrial Data Space ist eine Initiative der Indus-trie und der Fraunhofer- Gesellschaft zum Aufbau einerInfrastruktur für den sicheren Austausch von IIoT-Daten.Der Trusted Connector („Konnektor“) bietet hierbei einenSoftware-Stack für vertrauenswürdige Edge-Gateways,die sowohl im Industrial Data Space, aber auch in an-deren IIoT-Infrastrukturen eingesetzt werden können. Jenach Ausprägung kann der Trusted Connector-Stack zumAufbau von sicheren eingebetteten Edge-Devices mitoder ohne Hardware-Vertrauensanker oder als ressour-censtarker Cloud-Dienst für das Hosting anspruchsvollerDatenanalyse-Anwendungen eingesetzt werden. Er wur-de im Hinblick auf typische Sicherheitsanforderungen desIIoT entworfen und bietet Lösungen für das Identitäts-management von Teilnehmern und Gateways, geschützteAusführungsumgebungen für Anwendungen, sowie einebenutzerzentrische Kontrolle über den Zugriff auf Datenund die Art und Weise ihrer Nutzung.

Fraunhofer AISEC 1

Kapitel 2. Sicherheitseigenschaften des Trusted Connector

2 Sicherheitseigenschaften des Trusted Connector

Der Trusted Connector spezifiziert eine Softwareplattform für vertrauenswürdige, sichere IIoT-Gateways. Diese sinddie Schnittstelle zwischen Datenquellen wie physischen Sensoren und der externen Datenaustauschplattform. Wäh-rend letztere in vielen Fällen durch eine zentrale Cloud-Anwendung realisiert wird, legt der Industrial Data Spaceseinen Schwerpunkt auf die Datesouveränität und vermeidet eine zentrale Datenhaltung durch eine zwangsweisevertrauenswürdige Stelle. Statt dessen werden Daten lokal im Connector vorgehalten und über direkte Verbindungenzwischen Datenanbieter und -nutzer ausgetauscht. Neben der eigentlichen Vermittlung von Daten sind IIoT-Gatewaysfür die Vorverarbeitung (Aggregation, Filterung), das Message-Routing, die Bereitstellung von Diensten in der IIoT-Infrastruktur und die Herstellung sicherer Konnektivität verantwortlich. Gleichzeitig müssen Konnektoren eine großeBandbreite von Deployment-Varianten abdecken: Die Referenzimplementierung des Trusted Connector ist daher nichtan eine bestimmte Hardware gebunden, sondern kann aktuell bereits auf ARM, x86 und PowerPC-Plattformen auf-gesetzt werden.

Anforderungen an sichere eingebettete IIoT-Gateways wurden u.a. durch Microsoft definiert1 Die folgende Tabellezeigt, wie diese Anforderungen durch den Trusted Connector erfüllt werden. Tatsächlich geht der Trusted Connectorjedoch über diese Anforderungen hinaus, da er verschiedene Hardware-Plattformen und damit auch verschiedeneSicherheitsstufen zulässt, die dem jeweiligen Kommunikationspartner kommuniziert und nachgewiesen werden kön-nen.

Anforderung Motivation/Umsetzung

Hardware-based Root of TrustGeräte benötigen eine nicht-fälschbare und nicht-übertragbare eindeutige Identität. Schlüsselmaterialwird durch Hardware-Vetrauensanker geschützt.

SCDaemon-Komponente abstrahiert Zugriff auf Schlüsselmaterial und Zertifikate von zugrundeligenderSoftware/Hardware.

Small Trusted Computing BaseFunktionen sollten auf einer möglichst kleinen vertrauenswürdigen Basis aufbauen.

Vertrauenswürdige Basis sind Kernel & Container Management Layer.

Defense in DepthErgänzende Sicherheitsfunktionalitäten in mehreren Schichten zur Abwehr von Angriffen.

Whitelist-basierte Integritätsschutzmaßnahmen (Secure Boot, Container-Integritätsverifikation), Remote-Integritätsnachweis, Least-Privilege-based Isolation.

CompartmentalizationFunktionen dürfen sich nicht gegenseitig beeinflussen. Ein Fehler in einer Funktion darf keine Auswirkun-gen auf andere Funktionen haben.

Isolation von Apps in Linux-Containern, Least-Privilege-based Isolation mittels Linux Security Module(LSM).

Certificate-based AuthenticationGeräte müssen sich sicher und nicht-interaktiv – also ohne Eingabe von Passwörtern – authentisierenkönnen.

Automatisch ausgestellt ACME-Zertifikate für vertrauliche Kommunikation, Nicht-interaktiver Nachweisvon Identitätsattributen mittels OAuth2.0 und Attribute Provider.

Renewable SecurityFehlerhafte Komponenten müssen im Betrieb aktualisiert werden können.

Remote-Aktualisierung von Container-Images und Kernel

ReportingFehler und sicherheitskritische Ereignisse müssen nicht-abstreitbar aufgezeichnet werden.

Eventbasiertes Audit-Log mit Integritätsnachweis.

Kommunikation Konnektoren etablieren einen siche-ren Kommunikationskanal zwischen Endpunkten. NebenVerschlüsselung und Schutz der Datenintegrität muss imRahmen der Kommunikation das Sicherheitsniveau desGegenübers nachgewiesen werden. Je nach verfügba-rer Hardware-Plattform wird ein Trusted Platform Mo-dule (TPM) für eine Remote-Attestation der Plattformeingesetzt. Bietet die jeweilige Plattform keinen solchenHardware-Vertrauensanker, so kann der Trusted Connec-tor nichtsdestotrotz mit einem Software-basierten TPMverwendet werden. In diesem Fall kann sein Kommuni-

kationpartner das ggf. schwächere Sicherheitsniveau derPlattform im Rahmen der Remote Attestation feststellenund auf dieser Grundlage entscheiden, ob er Daten fürdiese Plattform freigibt. Zusammenfassend gilt:

• Kommunikation zwischen Konnektoren ist integer,authentisch und vertraulich.

• Konnektoren weisen sich gegenseitig ihren Sicher-heitsstatus nach.

• Datenaustausch kann auf vertrauenswürdige siche-re Konnektoren begrenzt werden.

1Galen Hunt and George Letey and Edmund B. Nightingale. The Seven Properties of Highly Secure Devices,Microsoft Research NExT OperatingSystems Technologies Group, März 2017

2 Fraunhofer AISEC

Kapitel 2. Sicherheitseigenschaften des Trusted Connector

Datensouveränität Unter dem Begriff „Datensouverä-nität“ wird verstanden, dass Datenanbieter bestimmenkönnen, wer ihre Daten erhält, wie sie verarbeitet werdendürfen und an welchen Zweck und an welche Auflagendie Nutzung gebunden sein soll. Diese Entscheidung mussanhand von Richtlinien definiert werden können, die fürden Benutzer verständlich und für Auditoren nachprüfbarsind. Sie müssen auf authentischen Informationen überdie Identität und das Sicherheitsniveau des Consumer-Connectors basieren. Im Bezug auf die Datansouveräni-tät zeichnet sich der Konnektors im Wesentlichen duchfolgende Attribute aus:

• Die Bereitstellung von Daten kann abhängig vomSicherheitsniveau des Datenkonsumenten erfol-gen.

• Die Bereitstellung von Daten kann jedoch auch anAuflagen bzgl. ihrer Verwendung gebunden wer-den.

• Unzulässige Arten der Datenverarbeitungen undDatenflüsse können unterbunden werden.

• Die Einhaltung von zulässigen Datenflüssen istnachweisbar und auditierbar.

Anwendungssicherheit Konnektoren dienen als Aus-führungsplattform für Apps, durch die Daten innerhalb

des Konnektors verarbeitet und für andere Konnektorenbereitgestellt werden können. Die Herkunft und Integri-tät von Apps muss während der Installation geprüft wer-den, um Manipulationen von Apps oder das Einschleu-sen von Schadsoftware zu verhindern. Bei der Ausfüh-rung von Apps muss die Trusted-Connector-Plattform si-cherstellen, dass sich Apps nicht gegenseitig beeinträch-tigen, die Ausführungsplattform selbst manipulieren oderDaten unkontrolliert preisgeben. Letzteres erfordert, dassApps zunächst nicht in der Lage sein dürfen, ausgehendeVerbindungen zu initiieren, sondern dieses Recht entwe-der explizit erteilt werden muss oder sämtliche Kommu-nikation über einen vertrauenswürdigen Referenzmonitor(„Core Platform“) erfolgt. Die Anwendungssicherheit desTrusted Connector umfasst damit die folgenden Kerna-spekte:

• Die Authentizität und Integrität von Apps ist sicher-gestellt.

• Apps können selbstständig keine Daten preisge-ben, jede Kommunikation (in/out) wird kontrolliertund protokolliert.

• Apps laufen in Konnektoren strikt voneinander iso-liert.

Fraunhofer AISEC 3

Kapitel 3. Identitäts- & Access-Management

3 Identitäts- & Access-Management

Das IIoT stellt besondere Anforderungen an das Identitäts- und Access-Management (IAM), da im Gegensatz zu klas-sischen Enterprise-Architekturen keine zentrale Instanz mehr über Zugriffe entscheiden kann. Ziel des IAM, das durchden Trusted Connector implementiert wird, ist daher, dem jeweiligen Konnektor-Betreiber die Kontrolle über seineDaten zu geben und diese Autorisierung von der darunterliegenden Authentisierung und Verschlüsselung zu tren-nen. Authentisierung und Verschlüsselung sind notwendige Voraussetzung für eine sichere Kommunikation, die nichtdurch Dritte abgehört oder modifiziert werden kann. Ein Zugriff auf Daten erfordert jedoch zusätzlich eine Autorisie-rung, die von verifizierten Identitätsattributen der Gegenstelle abhängt. Diese Attribute können unterschiedlich starkbeglaubigt sein und von einer unbestätigten Selbstauskunft bis hin zu geprüften und zertifizierten Attributen reichen.

Identitäten und Attribute Eine Identität im IndustrialData Space bezeichnet einen Trusted Connector und sei-nen Betreiber. Sie besteht aus mehreren Komponenten,durch die eine zunehmend starke Identifizierung realisiertwird. Zunächst werden Konnektoren über ein X509v3-Zertifikat identifiziert, das an ihren Hostnamen gebun-den ist. Für Konnektoren, die über das Internet erreich-bar sind, können diese Zertifikate durch einen öffentli-chen ACME-Dienst erstellt werden, für interne Konnek-toren können unternehmensinterne ACME-Server oderselbst generierte und mit einer eigenen CA signierte Zerti-fikate verwendet werden. Auf dieser Stufe ist bereits einevertrauliche und authentische Kommunikation zwischenKonnektoren möglich, allerdings sind noch keine weiter-gehenden Informationen über die Eigenschaften des Kon-nektors oder seines Betreibers verfügbar. Solche Informa-tionen werden in Form von Identitätsattributen bereitge-stellt, die durch einen Attribute Provider verwaltet wer-den. Mittels der Identitätsattribute werden Angaben zumBetreiber eines Konnektors, sowie zum Sicherheitsniveaudes jeweiligen Konnektors in einer Form hinterlegt, die esDatenanbietern ermöglicht Zugriffskontrollrichtlinien aufBasis dieser Attribute festzulegen. So wird es möglich, nurKonnektoren eines bestimmten Betreibers Zugriff auf Da-ten zu erteilen, oder nur Konnektoren mit einem Mindest-niveau an Sicherheit zuzulassen. Identitätsattribute desAttributeproviders sind von diesem beglaubigt. Nicht be-glaubigte Identitätsattribute können vom Betreiber einesKonnektors selbst angegeben und werden von diesem inForm einer Selbstauskunft bereitgestellt. Ihre inhaltlicheRichtigkeit ist also nicht sichergestellt und sie sind ledig-lich als eine ungeprüfte Beschreibung des Konnektors ausSicht des (authentischen) Betreibers eines Konnektors zuverstehen. Im Gegensatz dazu werden bestätigte Identi-tätsattribute durch eine unabhängige Zertifizierungsstelleverifiziert. Hierzu definiert der Industrial Data Space Zerti-fizierungskriterien und einen Prüfprozess, an dessen Endedie Erteilung einer Zertifizierung und die Signatur der je-weiligen Identitätsattribute steht.

Auf diese Weise kann grundsätzlich jedermann die IDS-Infrastruktur verwenden, indem er einen Trusted Connec-tor lediglich mit einem X509v3-Zertifikat betreibt, das bisauf die Richtigkeit des Hostnamens keine weiteren Zusi-

cherungen gibt. Andererseits können Betreiber von einerhöheren Sicherheitsstufe ihrer Konnektoren profitieren, indem sie Zugang zu höherwertigen Diensten erlangen, dieihre Daten nur vertrauenswürdigen und ggf. zertifizier-ten Konnektoren bereitstellen. Die Voraussetzung hierfürist, dass Datenanbieter und -konsument den selben At-tribute Provider verwenden und diesem vertrauen. Dabeiist es jedoch nicht erforderlich, dass für die gesamte IDS-Infrastruktur nur ein Attribute Provider existiert. Vielmehrkönnen mehrere Attribute Provider Identitätsattribute ver-schiedener Kontexte verwalten und parallel verwendetwerden. So ist es beispielsweise möglich, das Unterneh-men in Konsortien und Projekten zusammenarbeiten undfür den Zweck dieser Zusammenarbeit einen gemeinsa-men Attribute Provider verwenden, bei dem sich alle Mit-glieder des Konsortiums registrieren und fortan als solcheausgewiesen werden.

Konnektor B(Anbieter)

Attribute Provider

ACME-Server

Konnektor A(Konsument)

Fragt Token an

Erstellt Token

Erstellt X509v3-ZertifikatErstellt x509v3-Zertifikat

Token Validation

Komponenten des Identitätsmanagement

Technische Umsetzung Für das Identitäts- und Access-Management verwendet der Trusted Connector Stan-dardprotokolle aus dem Web-Umfeld. Beim erstmaligenInitialisieren eines Trusted Connector wird ein Public-/Private-Schlüsselpaar, sowie ein Signing Request für denHostnamen des Konnektors erzeugt und mittels ACME-Challenge verifiziert. Für öffentlich erreichbare Konnek-toren empfiehlt sich hierfür ein öffentlicher Dienst, des-sen CA in vielen Clients als vertrauenswürdig betrachtetwird. Für interne Konnektoren kann entweder ein eige-ner ACME-Server zum Einsatz kommen, oder es werdenselbstsignierte Zertifikate im Trusted Connector erstellt

4 Fraunhofer AISEC

Kapitel 3. Identitäts- & Access-Management

und manuell ausgetauscht.Diese Zertifikate werden während der Verbindung zwi-schen Trusted Connectors über das IDS-Protokoll fürden Aufbau der TLS-Verbindung benutzt – sowohl fürdie Client-Authentisierung, als auch für die Verschlüs-selung. Ist die TLS-Verbindung etabliert, so werden imRahmen des IDS-Protokolls JSON Web Tokens (JWT) fürden Zugriff auf Ressourcen des Trusted Connectors eta-bliert. Hierzu stellt der Client (Datenkonsument) einenOAuth2.0-konformen Token Request an den Attribute

Provider und authentisiert sich dabei mittels TLS ClientCredentials. Über einen OAuth 2.0 Assertion Flow erhälter ein JWT mit bestätigten oder unbestätigten Identitäts-attributen, signiert vom Attribute Provider. Dieses sendeter an den Datenanbieter, der auf Basis der enthaltenenAttribute wiederum entscheiden kann, ob er den Zugriffgestattet oder ablehnt. Wurde die Verbindung auf dieseWeise etabliert, können fortan Daten über die bestehen-de Sitzung ausgetauscht werden, ohne dass eine erneuteAuthentisierung erforderlich ist.

Fraunhofer AISEC 5

Kapitel 4. Der Trusted Connector als sichere Ausführungsplattform

4 Der Trusted Connector als sichere Ausführungsplattform

Konnektoren sind die Edge-Gateways, über die interne Datenquellen in der IDS-Infrastruktur bereitgestellt und ge-nutzt werden können. Sie sind das Kernelement der Sicherheitsarchitektur des IDS und realisieren sowohl die Proto-kolle für das Identitäts- & Access-Management und zur sicheren Datenübertragung, als auch eine vertrauenswürdigeAusführungsumgebung für Apps zur Datenvorverarbeitung und -Analyse.

Ein Trusted Connector verfügt über Sicherheitsmechanis-men, mit denen die Integrität des Software-Stacks, dieVertraulichkeit und Integrität der Daten sowie die Isola-tion von Apps sichergestellt werden können. Zusammenermöglichen diese Eigenschaften neue Anwendungssze-narien, die mit bisherigen Sicherheitsarchitekturen nichtrealisiert werden können:

Höherwertige Datenangebote bei höherer Sicher-heit Konnektoren können grundsätzlich in verschiede-nen Sicherheitsstufen existieren – als einfaches Software-Programm auf einem herkömmlichen Rechner, bis hin zusicheren integrierten Hard- und Softwarestacks auf einge-betteten Systemen. Das Sicherheitsniveau jedes Konnek-tors lässt sich mit Hilfe einer Remote-Attestation feststel-len und analog zu den Identitätsattributen unterschied-licher Stärke für die Entscheidung von Zugriffsanfragenverwenden. So können Betreiber eines Trusted Connectorfestlegen, dass sie ausschließlich mit Konnektoren mit ei-nem nachweisbar integeren Software-Stack und vertrau-enswürdigen Apps kommunizieren möchten.

Datenverarbeitung an der Quelle In vielen Fällenwerden Rohdaten von Sensoren für Analysezwecke benö-tigt. Im IIoT-Kontext sind diese Daten jedoch hochkritisch,da sich aus ihnen detaillierte Informationen über inter-ne Produktionsabläufe gewinnen lassen. Eine Lösung istes, die kritischen Daten innerhalb des Unternehmens zubelassen und stattdessen die Analysedienste in Form vonApps zu den Daten zu transportieren. Hierzu muss aller-dings sichergestellt sein, dass Apps zuverlässig ausgeführtund nicht manipuliert werden. Des Weiteren muss bei derAusführung fremder Apps durch den Daten-Provider ga-rantiert werden, dass diese keinerlei Zugriff auf das Netz-werk, andere Apps oder den Trusted Connector selbsterhalten, sondern von anderen Prozessen isoliert bleibenund die zu verarbeitenden Daten lediglich über eine defi-nierte Schnittstelle erhalten.

Übersicht Trusted Connector-Architektur Der Trus-ted Connector ist ein Software-Stack, der im wesentli-chen aus den Komponenten Kernel, Container Manage-ment Layer (CML) und Core Container besteht. Beim Ker-nel handelt es sich um einen Linux Kernel, der den Appseine POSIX-kompatible Laufzeitumgebung bereit stellt

und zugleich alle Kommunikation kontrolliert. Dies erfolgtinsbesondere mit Linux-Namespaces, Control Groups, Ca-pabilities und einem Linux Security Module (LSM). Optio-nal können zudem auch die KVM-Kernel-Module verwen-det werden.

Oberhalb des Kernels befindet sich das Container Ma-nagement Layer (CML), das den Lebenszyklus der Con-tainer, die Verifikation von Container-Images, sowie dasNachladen von Containern aus dem App-Store über-nimmt. Der Trusted Connector unterstützt zwei CML-Implementierungen: Docker und trust-me. Die Vorteiledes Docker-Ökosystems sind seine weite Verbreitung, dieUnterstützung verschiedenster Plattformen – angefangenbei eingebetteten Systemen wie dem Raspberry Pi bis hinzu skalierenden Cloud- und Cluster-Plattformen wie Ama-zon AWS/ECS und Kubernetes. Diese Mächtigkeit kannjedoch auch von Nachteil sein, wenn dedizierte einge-bettete Geräte für sicherheitskritische Anwendungen be-nötigt werden. Hier kommt das trust-me CML zum Zug,dessen Vorteile im Fokus auf starke Container-Isolationsowie nativer Unterstützung für Sicherheitsmechanismenwie Secure Boot, eine TPM-gestützte Full Disk Encryption(FDE) und in einer netfilter-Separierung von Containernbestehen.

Container beinhalten Apps, die Funktionalität zur Ver-arbeitung und Analyse von Daten bereitstellen können.Apps sind grundsätzlich isoliert und haben keinen Zu-griff auf Speicher oder Dateisystem anderer Apps oderden CML. Auch wird ihnen kein Netzwerkinterface zuge-teilt, über das sie mit dem externen Netz oder anderenApps kommunizieren könnten. Ihre Berechtigungen kön-nen weiter durch Kernel-Capabilities, sowie durch das Li-nux Security Module kontrolliert werden. Die Zuteilungvon Systemressourcen wie CPU und Speicher lässt sichebenfalls Container-spezifisch festlegen. In diesem Zu-stand sind Apps zwar vor dem Zugriff aufeinander undauf das darunterliegender System geschützt, aber we-nig nutzbringend. Um sie nutzen zu können, müssen siemit Daten versorgt werden und ihre Ergebnisse abruf-bar sein können. Dies geschieht durch einen besonde-ren, privilegierten Container – die sogenannte Core Plat-form. Die Core Platform ist der einzige Container, der einNetzwerkinterface mit externem Zugriff erhält und mit je-dem einzelnen App-Container über eine Netzwerk-Bridgekommunizieren kann. Somit muss jede Kommunikationinnerhalb eines Trusted Connector über die Core Plat-

6 Fraunhofer AISEC

Kapitel 4. Der Trusted Connector als sichere Ausführungsplattform

form laufen. Innerhalb der Core Platform befinden sichMechanismen zur Datenflusskontrolle, das IDS-Protokoll,über das Verbindungen mit externen Trusted Connec-tors aufgebaut werden können, sowie die Management-Schnittstellen, über die die Einstellungen des CML verwal-tet werden können.

...

Network Surface

Core Container Service Container 1

Message RouterApp 1

vService

Container Management Security Management

Service Container n

App n

vServiceNutzungskontrolle

Virtualization Layer

Linuxkernel

Hardware ...

Netfilter Cgroups

Namespaces Container Isolation LSM

TPMSensor/ Actor Interface

FDECapabilities

Komponenten des Trusted Connector-Stack

Integrität der Software durch Remote AttestationDie Integrität des Software-Stacks eines Trusted Connec-tor wird durch Hardwarevertrauensanker in Form einesTrusted Platform Module (TPM) realisiert. Ein TPM ist eindediziertes vertrauenswürdiges Hard- oder Softwaremo-dul, das eine sichere Verwaltung kryptografischer Schlüs-sel, Verschlüsselungs- und Signaturoperationen, sowieeinen sicheren Speicher bereitstellt. Mittels eines von derTrusted Computing Group standardisierten Secure Boot-Prozesses verifiziert der Trusted Connector beim Startdes Systems die Integrität aller Betriebssystemkompontenund hinterlegt ihre Hashwerte in den sog. PCR-Registern.Konnektoren verwenden diese Werte während des Ver-bindungsaufbaus, um sich gegenseitig im Rahmen desIDS-Protokolls mittels einer Remote-Attestation die Inte-grität ihres Software-Stacks nachzuweisen. Die Remote-Attestation unterstützt hierbei drei Sicherheitslevel: BeiLevel 0 wird de facto keine Attestierung durchgeführt –die Konnektoren tauschen lediglich den Hinweis aus, dasssie über kein TPM oder keinen Secure-Boot-Prozess verfü-

gen. Level 1 umfasst einen Integritätsnachweis von Boot-Firmware, Bootloader, Kernel und Core Platform. Diessind damit die unveränderlichen Bestandteile des TrustedConnector, die nicht modifiziert werden können, ohne diePCR-Hashes zu verändern. Da natürlich Software-Updatesdieser Komponenten nach wie vor möglich sein müssen,werden TPM 2.0 custom policies verwendet, um die Ent-scheidung über die Korrektheit eines PCR-Wertes an eineexterne Software Authority zu delegieren.Eine Remote-Attestation auf Level 2 umfasst zusätzlich zuden Komponenten des Level 1 auch die Messung der in-stallierten Apps. Hierzu werden die Container-Images derApps zusammen mit ihren Meta-Daten, d.h. der jeweili-gen App-Beschreibung geprüft und die Integrität der da-bei entstehenden PCR-Werte zusammen mit dem measu-rement log wiederum durch die Software Authority be-stätigt.

Core Platform Sämtliche Kommunikation zwischenApps und zwischen Trusted Connectors erfolgt über dieCore Platform. Diese dient daher als zentraler Punkt fürdas Erstellen von Audit-Logs und zur Kontrolle von Daten-flüssen zwischen Apps. Der Vorteil hierbei ist, dass Appsnicht vertrauenswürdig sein müssen und nicht von IDS-spezifischen Schnittstellen abhängen. Anstatt Apps spe-zifisch für den IDS zu entwickeln, können Konnektor-Betreiber so existierende Apps (z.B. Docker-Container)in den Trusted Connector laden und in ihre Datenfluss-Konfiguration einbinden. So lange die App eines der Pro-tokolle verwendet, die vom Message Router der Core-Plattform unterstützt werden, kann sie in eine Datenver-arbeitungskette in Form einer Message-Route eingebun-den werden. Message-Routes orchestrieren Nachrichtenzwischen einzelnen Apps, konvertieren sie in die erfor-derlichen Formate und stellen sie schließlich über das IDS-Protokoll anderen Konnektoren zur Verfügung, wobei dieCore Platform jeden einzelnen Verarbeitungsschritt imRahmen der Datenflusskontrolle prüft. Neben der zen-tralen Kommunikationschnittstelle beinhaltet die Core-Platform auch die Schnittstellen zum Management desTrusted Connectors. Betreiber konfigurieren ihren Kon-nektor entweder über ein Webinterface oder über einetextbasierte Konsole.

Fraunhofer AISEC 7

Kapitel 5. Datennutzungskontrolle mit dem Trusted Connector

5 Datennutzungskontrolle mit dem Trusted Connector

Souveränität über Daten zu wahren, ist das oberste Ziel des Industrial Data Space und zwingende Voraussetzung fürAnwendungsfälle, die über das reine Teilen von ohnehin öffentlichen Daten hinausgehen. Mit dem Trusted Connectorals vertrauenswürdigem Hardware-/Software-Stack verfügen die IDS-Teilnehmer über einen Endpunkt, über den sichfortgeschrittene Techniken der Datennutzungskontrolle umsetzen lassen. Datennutzungskontrolle unterscheidet sichvon herkömmlicher Zugriffskontrolle dadurch, dass nicht der Zugriff auf eine Ressource (z.B. einen Dienst) zu einemZeitpunkt kontrolliert wird, sondern die Nutzung der Daten über die Zeit hinweg. Dies ist erforderlich, um typischeAnforderung an die Kontrolle der Datennutzung zu realisieren, wie die folgenden Beispiele zeigen.

Beispiel: Einhaltung von Datenschutzanforderun-gen Bei der Verarbeitung persönlicher Daten müssenKonnektor-Betreiber jederzeit Auskunft über den Verbleibdieser Daten geben können, sie auf Anfrage des Eigentü-mers löschen und sicherstellen, dass die Verarbeitung aus-schließlich dem angegebenen Zweck folgt. Was schon Be-treiber herkömmlicher Anwendungen mit zentralen Da-tenbanken vor Herausforderungen stellt, wird für Daten-anbieter im Industrial Internet of Things zur Mammutauf-gabe. Die Herkunft jedes einzelnen Datums muss nach-verfolgbar sein und während der Verarbeitung muss be-urteilt werden können, in welchem VerarbeitungsschrittDaten als personenbezogen gelten.

Beispiel: Nutzungsrestriktionen für bereitgestellteDaten In dem Moment, in dem Daten von einem Dienstabgerufen werden, verliert dieser typischerweise die Kon-trolle über sie. Für viele IIoT-Anwendungen ist es jedocherforderlich, dass auch sensible Daten ausgetauscht undmit Nutzungsrestriktionen versehen werden können. Sol-che Nutzungsrestriktionen umfassen beispielsweise dieAuflage, die Daten nach einer bestimmten Zeit zu lö-schen, eine Einschränkung des Einsatzzwecks oder dieForderung, Daten nicht weiterzuleiten.

Datenflusskontrolle mit LUCON Der Trusted Connec-tor verwendet standardmäßig das LUCON Policy-Framework zur Kontrolle von Datenflüssen zwischenApps und Konnektoren. LUCON markiert Daten mit La-bels, sobald sie den Trusted Connector erreichen. Im wei-teren Verlauf der Datenverarbeitung in einer Message-Route werden Labels über Apps hinweg transportiertund durch diese ggf. erweitert, modifiziert, oder ent-fernt. Abhängig von den Labels, die an einer Nachrichthaften, können mit LUCON Einschränkungen und Auf-lagen – sogenannte Obligations – verbunden werden.So kann beispielsweise verhindert werden, dass als pri-vat markierte Daten an externe Dienste versendet wer-den oder zunächst einen Anonymisierungsdienst durch-laufen müssen. Durch Obligations können Aktionen aufdem Trusted Connector ausgeführt werden oder zusätzli-che Auflagen in Form von sticky policies mit den Datenverknüpft werden. Aktionen auf dem Trusted Connec-tor umfassen beispielsweise das Logging von Nachrichten

für Audit-Zwecke oder das Löschen von Daten aus einemDienst. Sticky Policies sind Richtlinien, die zusammen mitden Daten im Rahmen des IDS-Protokolls an den TrustedConnector der Gegenstelle übermittelt werden. Dies kön-nen einerseits wiederum LUCON-Policies sein, mit denendie Gegenstelle die Datenflussanforderungen des Daten-anbieters umsetzen wird, oder aber Nutzungsrestriktio-nen in Form von ODRL. Die Open Digital Rights Language(ODRL) ist ein Standard zur Spezifikation von Nutzungs-einschränkungen für Daten und kann beispielsweise dazuverwendet werden, die Nutzungsdauer, -häufigkeit oderdie Art der zulässigen Operationen auf Daten zu defi-nieren. Im Gegensatz zu LUCON-Policies können ODRL-Anforderungen jedoch nicht automatisch durchgesetztwerden, sondern dienen als nachweisbare Vereinbarungzwischen Konnektor-Betreibern.

Auditierbare Datenverarbeitung Neben der aktivenDurchsetzung von Datenflussanforderungen lässt sich mitLUCON auch überprüfen und ggf. nachweisen, dass dieDatenverarbeitung im Trusted Connector die Anforderun-gen einhält. Betreiber können so auf einen Blick erken-nen, ob die konfigurierten Message-Routen jederzeit ih-ren Anforderungen entsprechen, oder ob sie unter be-stimmten Konstellationen unzulässige Datenflüsse bewir-ken könnten (die wiederum zur Laufzeit blockiert wür-den). Hierzu verwendet LUCON intern eine formale Re-präsentation von Message-Routen und Richtlinien undprüft mittels Model-Checking mögliche Verletzungen derRichtlinien durch die Route.

Warnung bei Message-Routen, die Nutzungsrestriktionen verletzen

8 Fraunhofer AISEC

Kapitel 5. Datennutzungskontrolle mit dem Trusted Connector

Technische Umsetzung Der Trusted Connector ver-wendet Apache Camel als Message-Router – eine quel-loffene Lösung zur Realisierung von Enterprise Integra-tion Patterns, die in vielen großvolumigen Produktiv-Anwendungen erprobt wurde. Für die Erstellung vonLUCON-Policies existiert ein Xtext1-basierter Editor fürdie Eclipse-Plattform, der den Entwickler mit Auto-Vervollständigung und Syntax-Highlighting unterstütztund Policies automatisch kompiliert. Die kompiliertenPolicies werden anschließend über die Administrations-schnittstelle in den Trusted Connector geladen und dortohne weiteres Zutun des Benutzers zur Verifikation derCamel-Routen, sowie zur Durchsetzung der Richtlinienverwendet.

LUCON Datenfluss-Richtlinie in Eclipse-Editor

Obligations können in die Core Platform geladen werdenund stehen dann für die Durchsetzung von Richtlinien zur

Verfügung. So wird bspw. die Anforderung von ODRL-Nutzungsrestriktionen in Form einer Obligation realisiert,die ODRL-Daten an die jeweilige Nachricht bindet und anden Trusted Connector der Gegenstelle übermittelt.<http://example.com/policy:1111> a odrl:Offer ;odrl:permission [

odrl:action odrl:use ;odrl:target

↪→ <http://example.com/SpecificOperationOfADataService> ;odrl:assigner <http://example.com/Supplier> ;odrl:assignee <http://example.com/OEM> ;odrl:constraint [

odrl:purpose ids:RiskManagement;odrl:purpose ids:BottleNeckManagement;

];];odrl:prohibition [

odrl:action odrl:use ;odrl:target

↪→ <http://example.com/SpecificOperationOfADataService> ;odrl:assigner <http://example.com/Supplier> ;odrl:assignee <http://example.com/OEM> ;odrl:constraint [

odrl:purpose ids:Purchasing;odrl:purpose ids:Sales;

];].

ODRL-Nutzungsrestriktion

Die Kombination aus nachweisbarer Vertrauenswürdig-keit der Trusted Connector-Plattform und Datennut-zungskontrolle erlaubt es Betreibern, auch sensible Datenanzubieten und dabei ihren rechtlichen Anforderungentechnisch nachweisbar nachzukommen.

1 https://www.eclipse.org/Xtext/

Fraunhofer AISEC 9

Kontakt

Ansprechpartner

Dr. Julian SchütteGerd Brost

Fraunhofer AISECParkring 4, 85748 Garching bei München

T +49 (0) 89 3229986-292k info@aisec.fraunhofer.de

Autoren

Dr. Julian SchütteService & Application Security

Gerd BrostService & Application Security

Sascha WesselSecure Operating Systems

Open-Source-Projekt

https://github.com/industrial-data-space

Förderrahmen

Der Trusted Connector ist eine Komponente des Industrial Data Space, gefördert durch das Bundesministerium fürBildung und Forschung im Rahmen des Projektes InDaSpacePlus (Förderkennzeichen 01|S17031). Anwendungen desTrusted Connector werden im Rahmen der Aktivitäten des Forschungsclusters Cognitive Internet Technologies CITgefördert.