Gerät und Verfahren zur Einrichtung einer dienstbezogenen Au- thentisierung

Die vorliegende Erfindung betri f ft Mittel zur Einrichtung einer Authentisierung eines Dienstes mittels eines dienstbezogenen Zerti fikats .

Mit einer zunehmenden Implementierung cloudbasierter Architekturen in industriellen Fertigungsumgebungen halten auch in industriellen Geräten - also in intelligenten Feldgeräten, Sensoren, Aktoren und Steuerungseinheiten der Automatisierungstechnik sowie in Automatisierungssystemen selbst - Technologien Einzug, welche bislang einer servergestützten Datenverarbeitung vorbehalten waren . Zu diesen Technologien zählen auch Virtualisierungsumgebungen, also Aus führungsumgebungen, welche eine modulare Aus führung einzeln abgetrennter Softwaremodulen erlauben, wobei die Softwaremodule durch einen Orchestrierungsdienst auf eine Mehrzahl von Geräten verteilt und zum Einsatz gebracht werden können . Die Softwaremodule können j e nach eingesetzter Virtualisierungsumgebungen ein Container innerhalb einer Containervirtualisierung oder ein Gastsystem innerhalb einer durch einen Hypervisorumgebung definierten Virtualisierung sein . In Anwendung der Containertechnologie werden Anwendungen bzw . Apps sowie Mikrodienste bzw . Microservices j e nach verfügbaren Ressourcen auf einem oder mehreren Containern dynamisch ausgewählter Feldgerät zum Ablauf gebracht oder auch ein Container auf einem Feldgerät beendet und stattdessen ein Container auf einem anderen Feldgerät erzeugt , um Teile der Anwendungen dort zum Ablauf zu bringen . Durch dieses »elastische« Umfeld, welches durch eine Gerätegrenzen überschreitende Orchestrierung von Diensten geprägt ist , werden bisher selbstverständliche persistente Kopplungen eines Dienstes an »sein« Gerät und somit auch zu Kommunikationsparametern - wie z . B . einer MAC-Adresse des Geräts - aufgegeben, mit denen der Dienst zuverlässig ansprechbar und ggf . auch identi fi zierbar war . Im Zuge einer steigenden Komplexität industrieller Automatisierungssysteme entsteht ein zunehmender Bedarf , Feldgeräte bereits auf einer Feldebene mit einer Fähigkeit zur Kommunikation untereinander aus zustatten, um von diesen erfasste Daten nicht einfach nur in Richtung einer höhere Leitebene zu liefern, sondern die erfassten Daten bereits auf Feldebene zu strukturieren, aggregieren, interpretieren und/oder zusammenzuführen .

Da mit einer zunehmend vielschichtigen Vernetzung der industriellen Feldebene mit der Leitebene , einer Unternehmensebene oder sogar dem Internet eine Absicherung der Kommunikation durch eine physische Abtrennung von einzelnen Netzwerken oder Netzwerksegmenten nicht mehr möglich ist , wird zunehmend darüber nachgedacht , kryptographische Verfahren bereits auf der Feldebene einzusetzen, um in Softwaremodulen ablaufende Diensten eine sichere Kommunikation mit anderen Diensten zu ermöglichen .

Ein Einsatz kryptographischer Verfahren in modularen Diensten erfordert eine dienstbezogenen Authentisierung, also ein mit kryptographischen Mitteln fälschungssicher und belegbar gestaltetes Nachweismittel , mit dem ein Dienst seine eigene Identität belegen - sich also authentisieren - kann . Derzeit existieren zwar digitale Zerti fikate , welche eine Authentisierung des Geräts ermöglichen . Eine Vorlage eines solchen gerätbezogenen Zerti fikats allein ermöglicht j edoch nur die Authentisierung des Geräts und lässt keine Rückschlüsse auf die Echtheit , Überprüfbarkeit und Vertrauenswürdigkeit der auf dem Gerät zum Ablauf gebrachten Softwaremodule zu, zumal die Initialisierung dieser Dienste nicht dem Gerät obliegt , sondern dem Orchestrierungsdienst . Eine regelbasiert arbeitende Logik als Empfänger des gerätbezogenen Zerti fikats wird es ablehnen, dieses gerätbezogene Zerti fikat als Grundlage für eine Authentisierung eines am Gerät zum Ablauf gebrachten Softwaremoduls zu akzeptieren . Ein solcher Empfänger wird es auch ablehnen, dieses gerätbezogene Zerti fikat als Grundlage für eine Authentisierung eines durch das ablaufende Softwaremodul angebotenen Dienstes , also als Grundlage einer dienstbezogenen Authentisierung, zu akzeptieren .

Selbst wenn ein Empfänger eines gerätbezogenen Zerti fikats entscheidet , dass das empfangene Zerti fikat nicht nur bezüglich des Geräts vertrauenswürdig ist , sondern auch bezüglich eines angebotenen Dienstes der auf dem Gerät zum Ablauf gebrachten Softwaremodule , kann dieses gerätbezogene Zerti fikat nicht den Dienst identi fi zieren, da das Zerti fikat aufgrund seines Zerti fikat-inhärenten Schutzes gegen Veränderungen nicht so angepasst werden kann, dass es den Dienst angibt , für den es zur dienstbezogenen Authentisierung Verwendung finden soll . Es bleibt fest zuhalten, dass eine dienstbezogene Authentisierung für orchestrierte Dienste derzeit nicht zufriedenstellend gelöst ist .

Die vorliegende Erfindung ist somit vor die Aufgabe gestellt , Mittel zur Einrichtung einer dienstbezogenen Authentisierung von Diensten zu schaf fen, welche durch eine Gerätegrenzen überschreitende Orchestrierung geprägt sind .

Die Aufgabe wird durch ein Verfahren mit den Merkmalen des Patentanspruchs 1 gelöst .

Das erfindungsgemäße Verfahren zur Einrichtung einer dienstbezogenen Authentisierung, umfasst die Schritte : a) Initialisierung eines Softwaremoduls in einer Aus führungsumgebung eines Geräts auf Veranlassung eines Orchestrierungsdienstes , wobei das Softwaremodul mindestens einen Dienst umfasst ; b) Erstellen eines Zerti fikatsantrags unter Verwendung mindestens eines dienstbezogenen Attributs ; c) Übermittlung des Zerti fikatsantrags an eine gerätinterne Registrierungsstelle ; d) Übertragung des Zerti fikatsantrags mit einem öf fentlichen Schlüssel eines asymmetrischen Schlüsselpaars von der ge- rätinternen Registrierungsstelle an eine gerätexterne Registrierungsstelle ; e ) Empfang eines dem Zerti fikatsantrag entsprechenden dienstbezogenen Zerti fikats durch das Gerät ; und; f ) Verwendung des dienstbezogenen Zerti fikats zur Authenti- sierung des Dienstes .

Die Erfindung ist geprägt von einer gerätinternen Registrierungsstelle oder Local Registration Authority, kurz LRA, welche einen Zerti fikatsantrag von einem Dienst entgegennimmt und diesen Zerti fikatsantrag authentisch an eine gerätexterne Registrierungsstelle weitergibt . Mit dieser Maßnahme wird ein Bezug des Zerti fikatsantrags sowohl zu einem spezi fischen Dienst also auch zu einem spezi fischen Gerät hergestellt . Nach einer zerti fikatsantragsgemäßen Bewilligung und Zuweisung eines Zerti fikats wird dieses im Gerät vorgehalten und kann nun für eine dienstbezogene Authentisierung vorgelegt werden .

In Schritt a ) des erfindungsgemäßen Verfahrens ist eine Initialisierung eines Softwaremoduls in einer Aus führungsumgebung eines Geräts vorgesehen . Als Softwaremodule werden insbesondere Softwaremodule in einer virtualisierten Arbeitsumgebung verstanden, beispielweise in einer Containervirtuali- sierung oder in einer durch eine Hypervisorumgebung definierten Virtualisierung . Unter einer Initialisierung eines Softwaremoduls ist zu verstehen, dass Softwaremodule j e nach verfügbaren Ressourcen auf ausgewählten Geräten zum Ablauf gebracht oder auch beendet und stattdessen auf einem anderen Gerät erzeugt , zum Ablauf gebracht , oder, mit anderen Worten initialisiert werden . Die Überwachung der Ressourcen, die Auswahl von Geräten, die Initialisierung und Beendigung von Softwaremodulen bzw . Diensten erfolgt durch einen Server bzw . Serverdienst , auf welchen üblicherweise als Orchestrierungsdienst Bezug genommen wird . Ein Softwaremodul kann dabei einen oder mehrere Dienste umfassen und ein Dienst kann über mehrere Softwaremodule , auch Softwaremodulen auf verschiedenen Geräten, verteilt sein . In Schritt b ) des erfindungsgemäßen Verfahrens ist ein Erstellen eines Zerti fikatsantrags unter Verwendung mindestens eines dienstbezogenen Attributs , also eines einem Dienst vorzugsweise individuell zugewiesenen Attributs , vorgesehen . Vorzugsweise wird mit diesem dienstbezogenen Attribut ein Bezug zu dem Dienst hergestellt , durch den auch der Zerti fikatsantrag gestellt wird . Alternativ kann aber auch ein zweiter Dienst einen Zerti fikatsantrag für einen ersten Dienst , anstelle eines ersten Dienstes oder in Vertretung eines ersten Dienstes stellen, wobei vorzugsweise das dienstbezogene Attribut des ersten Dienstes zur Erstellung des Zerti fikatsantrags verwendet wird . Ein eindeutiger Bezug zu dem Dienst wird beispielsweise hergestellt , indem der Dienst einen ihm zugewiesenen Dienstnamen als dienstbezogenes Attribut verwendet . Optional wird ein signiertes dienstbezogenes Attribut verwendet , also ein dienstbezogenes Attribut einer von einer vertrauenswürdigen Stelle signierten Form . Die vertrauenswürdige Stelle kann beispielsweise der Orchestrierungsdienst sein, welche die Zuweisung vornimmt , indem dieser beispielsweise das dienstbezogene Attribut in das Softwaremodul , beispielsweise einem Container, bzw . dessen zugehörige Konfigurationsdaten einbringt .

In Schritten c ) und d) des erfindungsgemäßen Verfahrens ist eine Übermittlung des Zerti fikatsantrags - in der Fachwelt auch als Certi ficate Signing Request bzw . CSR bekannt - über eine gerätinterne Registrierungsstelle - Local Registration Authority, kurz LRA - an eine gerätexterne Registrierungsstelle - Registration Authority, kurz RA - vorgesehen . Die Übermittlung des Zerti fikatsantrags erfolgt mit einem öf fentlichen Schlüssel eines asymmetrischen Schlüsselpaars . Der zughörige private Schlüssel dieses asymmetrischen Schlüsselpaars verbleibt in einer Stelle des Geräts , welche Gegenstand weiterer Ausgestaltungen ist . Jedenfalls verbleibt der private Schlüssel vorzugsweise innerhalb des Geräts . Auch die Erzeugung dieses asymmetrischen Schlüsselpaars ist Gegenstand weiterer Ausgestaltungen . So kann das asymmetrische Schlüs- selpaar entweder aus Anlass des Zerti fikatsantrags erzeugt werden oder bereits in einer anderen gerätinternen Stelle hinterlegt sein . Bevorzugt ist diese Stelle ein Verwahrungsmodul oder auch Trusted Platform Module , kurz TPM, also ein im Gerät meist isoliert angelegtes Hardwaremodul zur Berechnung und/oder Verwahrung kryptographischer Daten . Der Zertifikatsantrag ist beispielsweise ein elektronisches Formular bzw . eine Textdatei in einem wohldefinierten Format und enthält neben textuellen Antragsdaten auch den öf fentlichen Schlüssel . Der in Schritt d) vorgeschlagenen Übertragung des Zerti fikatsantrags mit dem öf fentlichen Schlüssel des asymmetrischen Schlüsselpaars von der gerätinternen Registrierungsstelle an die gerätexterne Registrierungsstelle kann so entsprochen werden, dass der öf fentliche Schlüssel in Schritt b ) , also im Zuge einer Erstellung des Zerti fikatsantrags ; oder ; in Schritt c ) , also im Zuge einer Übermittlung des Zerti- f ikatsantrags an die gerätinterne Registrierungsstelle ; oder ; in Schritt d) , also vor oder im Zuge einer Übertragung des Zerti fikatsantrags von der gerätinternen Registrierungsstelle an die gerätexterne Registrierungsstelle ; dem Zerti fikatsantrag hinzugefügt wird . Alle oben genannten drei Ausgestaltungsvarianten sind durch die Erfindung umfasst und bilden eine Grundlage für mannigfaltige vorteilhafte Ausgestaltungen im Rahmen der Erfindung .

In Schritt e ) des erfindungsgemäßen Verfahren wird ein dem Zerti fikatsantrag entsprechendes dienstbezogenes Zerti fikat durch das Gerät empfangen und dort für eine spätere Verwendung abgelegt , beispielsweise in einem flüchtigen, dem Dienst zugewiesenen Speicherbereich oder in einem flüchtigen, dem Softwaremodul zugewiesenen Speicherbereich oder im Verwahrungsmodul bzw . Trusted Platform Module , kurz TPM, des Geräts , wo es auf Abruf durch einen Dienst - insbesondere durch den Dienst , für den das dienstbezogene Zerti fikat erstellt wurde - bereitsteht . Vorzugsweise wird das Zerti fikat nur dann ausgestellt , wenn der Zerti fikatsantrag über die gerätinterne Registrierungsstelle eingereicht wurde und durch einen Besitz faktor - also einer Vorlage mindestens eines dienstbezogenen Attributs - nachgewiesen ist , dass ein Zertifikat mit dem Zerti fikatsantraggemäßen Inhalt auf den Zertifikatsantrag dieser gerätinternen Registrierungsstelle ausgestellt werden soll .

In Schritt f ) des erfindungsgemäßen Verfahrens erfolgt nach Hinterlegung des dienstbezogenen Zerti fikats nun eine Verwendung dieses dienstbezogenen Zerti fikats zur Authentisierung und/oder zur Identi fi zierung des Dienstes .

Die Erfindung betri f ft weiterhin ein zur Erzeugung und Verwendung einer dienstbezogenen Authentisierung eingerichtetes Gerät , welches folgende Komponenten umfasst :

- eine Aus führungsumgebung zur Initialisierung eines mindestens einen Dienst umfassenden Softwaremoduls auf Veranlassung eines Orchestrierungsdienstes ;

- eine gerätinternen Registrierungsstelle zur Entgegennahme eines Zerti fikatsantrags unter Verwendung mindestens eines dienstbezogenen Attributs und zur Übertragung des Zerti fikatsantrags mit einem öf fentlichen Schlüssel eines asymmetrischen Schlüsselpaars an eine gerätexterne Registrierungsstelle ; und; eine Schnittstelle zum Empfang eines dem Zerti fikatsantrag entsprechenden dienstbezogenen Zerti fikats .

Die Erfindung wurde durch Probleme in einem »elastische« Umfeld motiviert , infolgedessen traditionelle Kopplungen - mit denen der Dienst zuverlässig ansprechbar und identi fi zierbar war - eines Dienstes an ein Gerät oder an Kommunikationsparameter - wie z . B . einer MAC-Adresse des Geräts - nicht mehr existieren . Ein Grundgedanke der Erfindung ist , dass es aus Sicht eines Servers oder eines auf einem anderen Gerät laufenden Dienstes unerheblich sein muss , auf welchem Gerät ein anzusprechender Dienst läuft . Der Server sollte idealerweise in der Lage sein, lediglich anhand des Zerti fikats zu ent- scheiden, ob sich der richtige Dienst bei ihm meldet . Die Erfindung löst dieses Bedürfnis durch ein dienstbezogenes Zerti fikat , in dessen Inhalt das dienstbezogene Attribut übernommen wird, das bereits Bestandteil des Zerti fikatsantrags war .

Das erfindungsgemäße Verfahren hat den weiteren Vorteil , dass es im Zuge eines vom Orchestrierungsdienst angeordneten Umzugs eines Softwaremoduls von einem ersten auf ein zweites Gerät nicht erfordert , dass private Schlüssel - als eine Grundlage kryptographischer Operationen - in Folge des Umzugs ausgetauscht werden müssten . Wird ein Softwaremodul unter Veranlassung eines Orchestrierungsdienstes umgezogen, also auf einem ersten Gerät beendet und auf einem zweiten Gerät neu initialisiert , wird das erfindungsgemäße Verfahren auf dem zweiten erfindungsgemäß ausgestalten Gerät erneut angewandt , indem ein Zerti fikatsantrag auf dem zweiten Gerät gestellt wird . Ein dabei erzeugter oder weiterverwendeter privater Schlüssel verbleibt im zweiten Gerät , während der vor dem Umzug verwendete private Schlüssel auf dem ersten Gerät verbleibt , ohne dass eine die Sicherheit potentiell kompromittierender Umzug des privaten Schlüssels erforderlich wäre . Eine noch sicherere Ausgestaltung sieht vor, dass die Schlüssel in einem TPM ( Trusted Plattform Module ) innerhalb des Geräts aufbewahrt bleiben und dieses nicht verlassen können .

Das erfindungsgemäße Verfahren zum Bezug der Zerti fikate hat den weiteren Vorteil , dass das Verfahren autonom, bedarfsgerecht und vollautomatisch erfolgt . Demgegenüber war in früheren Geräten eine Erstimplementierung von Geräten mit einer vorab geplanten Ausstattung mit kryptographischen Schlüsselpaaren vorgesehen, welche nur durch individuelle und daher weitgehend nicht-automatische Updates ergänzt oder ersetzt werden konnten . Diese Updates erzeugen naturgemäß eine zumindest vorübergehenden Aus fall Geräteverfügbarkeit . Demgegenüber gewährleistet der vollautomatische und bedarfsgerechte Bezug der Zerti fikate gemäß dem erfindungsgemäßen Verfahren eine hohe Verfügbarkeit insbesondere für den Fall , dass wei- tere Instanzen eines Dienstes oder einer Anwendung gestartet werden, welche ihrerseits dienstbezogene Zerti fikate zu deren Authentisierung erhalten sollen .

Die Erfindung kombiniert in vorteilhafter Weise zwei - oder auch mehrere - Berechtigungsnachweise , welche für die Ausstellung des Zerti fikats erforderlich gemacht werden :

- Ein erster Berechtigungsnachweis wird durch das Gerät be- reitgestellt : Vorzugsweise wird das Zerti fikat nur dann ausgestellt , wenn der Zerti fikatsantrag über die gerätinterne Registrierungsstelle eingereicht wird .

- Ein zweiter Berechtigungsnachweis wird durch den Orchestrierungsdienst bereitgestellt , welches das dienstbezogene Attribut zumindest indirekt bei der Initialisierung eines Softwaremoduls hinterlegt . Durch diesen zweiten Berechtigungsnachweise bzw . Besitz faktor - einer Vorlage mindestens eines dienstbezogenen Attributs - wird nachgewiesen ist , dass ein Zerti fikat mit dem Zerti fikatsantraggemäßen Inhalt auf den Zerti fikatsantrag der gerätinternen Registrierungsstelle ausgestellt werden soll .

Durch diese erfindungsgemäße Vorsehung, zwei - oder auch mehrere - Berechtigungsnachweise zu fordern, ist es einem Gerät in vorteilhafter Weise nicht möglich, Zerti fikate für beliebige Dienste anzufordern . Ebenso wenig ist es für einen Orchestrierungsdienst möglich, ohne die Mithil fe von Geräten überhaupt Zerti fikate ausstellen zu lassen .

Die Erfindung ermöglicht es , eine Bindung eines Zerti fikats an einen physischen Vertrauensanker, z . B . ein Verwahrungsmodul oder auch Trusted Platform Module , kurz TPM, dynamisch zu verändern und somit Dienste , Softwaremodule oder Container, welche über ein Zerti fikat verfügen, dynamisch zwischen

( Feld- ) Geräten umzuziehen .

Die Erfindung ermöglicht eine verschlüsselte Kommunikation auf Dienstebene unter Verwendung des TLS-Protokolls ( Transport Layer Security) und unter Vorlage einer dienstbezogenen Authentisierung - also des erfindungsgemäß hergestellten dienstbezogenen Zerti fikats bzw . Clientzerti f ikats . Ebenso wird es Diensten ermöglicht , sich gegenüber anderen Diensten zu authenti fi zieren . Die Vorlage eines Clientzerti f ikats für eine unilaterale oder bilaterale Authentisierung macht das Übertragungsprotokoll TLS noch sicherer bezüglich eines Mittelsmann- bzw . »Man in the Middle« -Angri f fs .

Weitere Ausgestaltungen der Erfindung sind Gegenstand der abhängigen Patentansprüche .

Gemäß einer möglichen Aus führungs form des erfindungsgemäßen Verfahrens ist vorgesehen, dass das Softwaremodul ein Container innerhalb einer Containervirtualisierung ist . Gemäß einer alternativen Aus führungs form des erfindungsgemäßen Verfahrens ist vorgesehen, dass das Softwaremodul ein Gastsystem innerhalb einer durch einen Hypervisorumgebung definierten Virtua- lisierung ist .

Gemäß einer möglichen Aus führungs form des erfindungsgemäßen Verfahrens ist vorgesehen, dass das Erstellen des Zerti fikatsantrags unter weiterer Verwendung mindestens eines gerätbezogenen Attributs erfolgt . Es kann also vorgesehen sein, dass im Zerti fikatsantrag - und demzufolge auch im antragsgemäß von einer Zerti fi zierungsstelle oder Certi ficate Authority bzw . CA erstellten und von der gerätexternen Registrierungsstelle rückgelieferten Zerti fikat - neben einer den Dienst identi fi zierenden Angabe auch eine das Feldgerät kennzeichnende Angabe vorhanden ist . Diese Maßnahme verbessert eine doppelte Kopplung des Zerti fikats an den Dienst und an das Gerät . Es kann auch vorgesehen sein, dass seitens einer der Zerti fi zierungsstelle oder Certi ficate Authority bzw . CA zugeordneten Stelle eine Liste geführt wird, welche Geräte für welche Dienste welche Zerti fikate erhalten haben . Basierend auf diesen Angaben kann ein Widerruf von Zerti fikaten bei einer De-Kommissionierung erfolgen . Es kann weiterhin bereits bei der Ausgabe der Zerti fikate durch die Zerti fi zierungsstelle oder alternativ auch bei Weitervermittlung des dienstbezogenen Zerti fikats von der gerätexternen Registrierungsstelle an die gerätinterne Registrierungsstelle vorgesehen sein, dass die Zerti fi zierungsstelle oder die gerätexterne Registrierungsstelle vor Ausstellung bzw . Weitervermittlung der Zerti fikate prüft , ob die in den Zerti fikaten Bezug genommenen Geräte bekannt sind, so dass Zerti fikate beispielsweise nur für solche Geräte bereitgestellt werden, welche einer Anlage zugeordnet sind .

Gemäß einer möglichen Aus führungs form des erfindungsgemäßen Verfahrens ist vorgesehen, dass das dienstbezogene Attribut zumindest einen dem Dienst zugewiesenen Dienstnamen umfasst .

Gemäß einer möglichen Aus führungs form des erfindungsgemäßen Verfahrens ist vorgesehen, dass das dienstbezogene Attribut mit einer digitalen Signatur, beispielweise der digitalen Signatur einer vertrauenswürdigen Stelle , signiert ist . Die vertrauenswürdige Stelle kann beispielsweise ein Orchestrierungsdienst sein, welche eine Initialisierung des Softwaremoduls bzw . Zuweisung des Dienstes vorgenommen hat . Ein solcher Orchestrierungsdienst kann beispielsweise Teil einer Containerorchestrierungssoftware - z . B . die Open-Source-Software Kubernetes zur Automatisierung einer Bereitstellung, Skalierung und Verwaltung von Container-Anwendungen - sein, welche die Zuweisung vornimmt , indem sie beispielsweise die Information in den Container bzw . die zugehörigen Konfigurationsdaten einbringt . Das signierte , d . h . authentische , dienstbezogene Attribut wird in den Zerti fikatsantrag eingefügt , welcher erfindungsgemäß durch die gerätinterne Registrierungsstelle an die gerätexternen Registrierungsstelle weitergereicht wird . Alternativ kann das signierte dienstbezogene Attribut wird auch in einer vertrauenswürdigen Datenbank abgelegt sein . In einer solchen Datenbank können das dienstbezogene Attribut sowie andere Informationen abgerufen werden, welche Dienste auf welchen Geräten zum Ablauf gebracht werden sollen . Ebenso ist alternativ denkbar, dass j eder Dienst oder auch j eder Instanz eines Dienstes eine geheime Kennung erhält , mittels derer sie gegenüber der gerätexterne Registrierungsstelle und/oder gegenüber der Zerti fi zierungsstelle einen Nachweis erbringen kann, dass eine Zerti fikatsausstellung auf eine bestimmte Identität durch einen Orchestrierungsdienst vorgesehen wird . Vorzugsweise wird ein Zerti fikat nur dann ausgestellt , wenn der Zerti fikatsantrag über die gerätinterne Registrierungsstelle eingereicht wurde und - z . B . durch einen Besitz faktor oder eine Datenbankabfrage - nachgewiesen ist , dass ein Zerti fikat mit dem Zerti fikatsantraggemäßen Inhalt auf den Zerti fikatsantrag dieser gerätinternen Registrierungsstelle ausgestellt werden soll .

Gemäß einer möglichen Aus führungs form des erfindungsgemäßen Verfahrens ist vorgesehen, dass die Übertragung des Zerti fikatsantrags transportgesichert , insbesondere durch Anwendung eines SSL-Protokolls , eines TLS-Protokolls ( Transport Layer Security) oder eines CMS-Protokolls ( Cryptographic Message Syntax ) erfolgt . Eine transportgesicherte Übertragung oder, mit anderen Worten, eine Verschlüsslung der zu übertragenden Daten ist neben einer Gewährleistung der Unveränderbarkeit der Daten ein wesentlicher Teilaspekt einer sicheren Kommunikation . Eine Verschlüsselung erfolgt heute überwiegend unter Verwendung von TLS ( Transport Layer Security) , welches den Aufbau von anonymen, unilateral authentisierten und/oder beiderseitig authentisierten gesicherten Verbindungen ermöglicht .

Das Übertragungsprotokoll TLS ist sicherer, wenn der transportgesichert auf zubauende Kommunikation ein digitales Zertifikat zur unilateralen Authentisierung zugrundgelegt wird . TLS ist nämlich ohne eine zerti fikatsbasierte Authenti fi zierung anfälliger für einen Mittelsmann- bzw . »Man in the Midd- le«-Angri f f . I st nämlich ein Mittelsmann vor einem Schlüsselaustausch aktiv, kann er beiden Seiten seine eigenen Schlüssel vortäuschen und so die Datenübertragung unbemerkt mithören und auch unbemerkt manipulieren . Gemäß einer Aus führungsform des erfindungsgemäßen Verfahrens ist vorgesehen, dass zur transportgesicherten Übertragung des Zerti fikatsantrags an die gerätexterne Registrierungsstelle ein gerätebezogenes Zerti fikat zur Authenti fi zierung gegenüber der gerätexterne Registrierungsstelle sowie , optional im weiteren, gegenüber der Zerti fi zierungsstelle verwendet wird . Die Verwendung eines gerätebezogenes Zerti fikat zur Authenti fi zierung gegenüber der gerätexterne Registrierungsstelle hat zwei Vorteile : Einerseits ist das gerätebezogene Zerti fikat ein Surrogat für das noch nicht existierende dienstbezogene Zerti fikat , andererseits kann das gerätebezogene Zerti fikat auch der gerätexternen Registrierungsstelle und/oder der Zerti fi zierungsstelle dazu dienen, den Zerti fikatsantrag bezüglich der dienstbezogenen und auch der gerätebezogenen Kopplung weiter zu untersuchen .

Gemäß einer möglichen Aus führungs form des erfindungsgemäßen Verfahrens ist vorgesehen, eine Gültigkeit des dienstbezogenen Zerti fikats auf einen Zeitraum oder auf ein Ablaufdatum zu beschränken . Bevorzugt ist die Gültigkeit eines Zerti fikats , gemessen an einem Zeitraum, in der ein Softwaremodul in einer Aus führungsumgebung aktiv bleibt , auf einen relativ kurzen Zeitraum beschränkt .

Im Folgenden werden weitere Aus führungsbeispiele und Vorteile der Erfindung anhand der Zeichnung näher erläutert . Dabei zeigt die einzige FIG . eine schematische Darstellung einer beispielhaften Aus führungs form eines Geräts .

Die FIG zeigt ein Gerät DVC, welches in Verbindung mit anderen - nicht dargestellten - Geräten von gleicher, ähnlicher oder anderer Bauart an einem paketorientierten Netzwerk NW derart teilhat , dass zumindest zeitweise drahtlose oder drahtgebundene Kommunikationsverbindungen zwischen dem Gerät DVC und anderen Partner der Kommunikationsverbindungen aufgebaut werden könne .

Über das paketorientierte Netzwerk NW ist weiterhin ein Orchestrierungsserver mit einem darauf ablaufenden Orchestrie- rungsdienst ORC sowie eine Registrierungsstelle RA verbunden, auf welche im Folgenden auch als gerätexterne Registrierungsstelle RA Bezug genommen . Die Registrierungsstelle RA ist zumindest zeitweise mit einer Zerti fi zierungsstelle CA oder auch Certi ficate Authority kommunikativ verbunden .

Das Gerät DVC umfasst in fachüblicher Weise eine Netzwerkschnittstelle I F, eine Aus führungseinheit CTR und ein Verwahrungsmodul TPM oder auch Trusted Platform Module , kurz TPM, also ein im Gerät DVC isoliert angelegtes Hardwaremodul zur Berechnung und/oder Verwahrung kryptographischer Daten .

Alternativ kann das Verwahrungsmodul TPM als Keymaster Trusted Application ausgestaltet sein, also als Software , die in einem sicheren Kontext ausgeführt wird . Der Keymaster hat Zugri f f auf ursprüngliches kryptografisches Material , das über einen Keystore verwaltet wird, und führt alle Keystore- Vorgänge aus . Alternativ kann das Verwahrungsmodul TPM als Trusted Execution Environment bzw . TEE ausgeführt sein, also beispielweise in einem ein Bereich auf einem der Aus führungseinheit CTR zugeordneten Chipsatz , welcher wie ein Trusted Platform Module arbeitet , j edoch nicht physisch vom Rest des Chips isoliert ist . Alternativ kann das Verwahrungsmodul TPM als Secure Element ausgestaltet sein . Secure Element ist ein ebenfalls physisch abgetrenntes , manipulationssicheres Speichermodul zur Speicherung kryptografischer Daten, welcher häufig als EMV-Chip auf Zahlungs-bzw . Debitkarten zum Einsatz kommt . Das Kürzel EMV bezeichnet drei Gesellschaften Europay International , MasterCard und VISA, die diesen Chip entwickeln ließen .

Das Gerät DVC umfasst des Weiteren eine Aus führungsumgebung CEN zur Initialisierung von Softwaremodulen D1 , D2 , D3 auf Veranlassung des Orchestrierungsdienstes ORC . Das Gerät DVC ist also eingerichtet zum Betrieb einer Virtualisierungsumgebung welche eine modulare Aus führung der logisch abgetrennten Softwaremodule D1 , D2 , D3 erlaubt . Die Softwaremodule D1 , D2 , D3 können j e nach eingesetzter Virtualisierungsumgebung als Gastsysteme innerhalb einer durch einen Hypervisorumgebung definierten Virtualisierung oder, wie im vorliegenden Aus führungsbeispiel , Container D1 , D2 , D3 innerhalb einer Container- virtualisierung eingerichtet sein .

In Anwendung der Containertechnologie werden - nicht dargestellten - Anwendungen bzw . Apps sowie Mikrodienste bzw . Microservices - im Folgenden allgemein als Dienste bezeichnet - j e nach verfügbaren Ressourcen auf einem oder mehreren Containern D1 , D2 , D3 zum Ablauf gebracht oder auch beendet und stattdessen ein Container auf einem anderen Gerät erzeugt , um den Dienst oder Teile des Dienstes dort zum Ablauf zu bringen . Die folgende Darstellung beschränkt sich lediglich aus Gründen der Übersichtlichkeit und ohne Beschränkung der Allgemeingültigkeit auf einen - nicht dargestellten - Dienst , welcher auf dem ersten Softwaremodul ausgeführt und/oder welcher auf dem ersten Softwaremodul Dl angeboten wird .

Das Gerät DVC umfasst eine gerätinternen Registrierungsstelle LRA zur Entgegennahme eines Zerti fikatsantrags CSR unter Verwendung mindestens eines dienstbezogenen Attributs des Dienstes und zur Übertragung des Zerti fikatsantrags CSR mit einem öf fentlichen Schlüssel eines asymmetrischen Schlüsselpaars an die gerätexterne Registrierungsstelle RA. Die Übergabe des Zerti fikatsantrag CSR von dem Dienst an die gerätinterne Registrierungsstelle LRA ist zeichnerisch strichliert dargestellt , um den aufgrund der modularen Natur sowie der komplexen Zusammenwirkung der Aus führungsumgebung CEN mit der Ausführungseinheit CTR außer Acht gelassenen physischen Weg der Übergabe aus zublenden zugunsten einer einfacher dargestellten logischen Übergabe . Das gleiche gilt für die später erläuterte Übergabe des dienstbezogenen Zerti fikat CTF von der gerätinternen Registrierungsstelle LRA an den Dienst .

Das Gerät DVC ist also insbesondere geprägt durch die gerätinternen Registrierungsstelle LRA, welche den Zerti fikatsantrag CSR vom Dienst entgegennimmt und diesen Zerti fikatsantrag CSR authentisch an die gerätexterne Registrierungsstelle RA weitergibt . Die gerätexterne Registrierungsstelle RA gibt diesen Zerti fikatsantrag CSR nach optionaler Prüfung an die Zerti fi zierungsstelle CA weiter .

Der Zerti fikatsantrag CSR wird unter Verwendung mindestens eines dienstbezogenen Attributs erstellt , also eines einem Dienst vorzugsweise individuell zugewiesenen Attributs . Vorzugsweise wird mit diesem dienstbezogenen Attribut ein Bezug zu dem Dienst hergestellt . Das dienstbezogene Attribut enthält zumindest einen dem Dienst zugewiesenen Dienstnamen .

Mit der Vorsehung der gerätinternen Registrierungsstelle LRA wird ein Bezug des Zerti fikatsantrags CSR sowohl zu dem spezi fischen Dienst also auch zu dem spezi fischen Gerät DVC hergestellt . Diese doppelte Kopplung des Zerti fikats an den Dienst und an das Gerät kann weiter verstärkt werden . Dazu ist dem Gerät DVC des Weiteren ein - nicht dargestelltes - gerätebezogenes Zerti fikat zugeordnet , das den öf fentlichen Schlüssel des Geräts DVC, Information über das Gerät DVC, wie beispielsweise Identität , Typ und möglicherweise Information über den Herausgeber des Zerti fikats enthält . Dabei kann vorgesehen sein, dass im Zerti fikatsantrag CSR neben einer den Dienst identi fi zierenden Angabe auch eine das Gerät kennzeichnende Angabe vorhanden ist .

Sowohl das - nicht dargestellte - gerätebezogene Zerti fikat als auch das dienstbezogene Zerti fikat CTF sind üblicherweise durch eine herausgebende Zerti fi zierungsstelle CA signiert , daher müssen die Zerti fikate nicht notwendigerweise im Verwahrungsmodul TPM gespeichert werden, sondern können in einem beliebigen Speicherbereich des Geräts DVC gespeichert werden .

Die Übermittlung des Zerti fikatsantrags CSR an die gerätexterne Registrierungsstelle RA sowie an die Zerti fi zierungsstelle CA erfolgt zusammen mit einem öf fentlichen Schlüssel eines asymmetrischen Schlüsselpaars . Dieses asymmetrische Schlüsselpaar kann vom Dienst generiert werden oder alternativ oder unter weiterer Beteiligung der Aus führungseinheit CTR und/oder dem Verwahrungsmodul TPM . Das asymmetrische Schlüsselpaar entweder aus Anlass des Zerti fikatsantrags CSR erzeugt werden oder bereits in einer anderen gerätinternen Stelle , insbesondere dem Verwahrungsmodul TPM hinterlegt sein . Der zugehörige private Schlüssel dieses asymmetrischen Schlüsselpaars verbleibt in einem vom Dienst , von der Aus führungseinheit CTR und/oder vom Verwahrungsmodul TPM verwalteten flüchtigen oder nicht flüchtigen Speicherbereich .

Nachdem dem Zerti fikatsantrag CSR durch die Zerti fi zierungsstelle CA zerti fikatsantragsgemäß entsprochen wurde , wird ein dem Zerti fikatsantrag CSR entsprechendes dienstbezogenes Zerti fikat CTF empfangen und im Gerät CSR für eine spätere Verwendung abgelegt , beispielsweise in einem flüchtigen, dem Dienst zugewiesenen Speicherbereich oder in einem flüchtigen, dem Softwaremodul Dl zugewiesenen Speicherbereich, wo das Zerti fikat CTF auf Abruf durch den Dienst bereitsteht . Das Zerti fikat CTF kann im Weiteren für eine dienstbezogene Au- thentisierung des Dienstes vorgelegt werden .

Die erfindungsgemäßen Mittel ermöglichen es dem Dienst , geprüfte Zerti fikate wie X . 509-Zerti f ikate in einer durch eine Gerätegrenzen überschreitende Orchestrierung von Diensten geprägten »elastischen« Umgebung abzurufen, ohne dass private Schlüssel außerhalb des Dienstes verfügbar gemacht werden müssen . Asymmetrische Schlüsselpaare , insbesondere private Schlüssel des Dienstes können im Verwahrungsmodul TPM gespeichert werden, so dass keine Spuren auf flüchtigen oder nichtflüchtigen Speicherbereichen des Geräts DVC verbleiben .