OPC-UA: Ein kritischer Vergleich der IT-Sicherheitsoptionen

Transkript

1 OPC-UA: Ein kritischer Vergleich der IT-Sicherheitsoptionen Melanie Gallinat 1, Stefan Hausmann 2, Markus Köster 1, Stefan Heiss 2 Weidmüller Gruppe 1 Klingenbergstraße Detmold, Deutschland Melanie.Gallinat@weidmueller.de, Markus.Koester@weidmueller.de Hochschule Ostwestfalen-Lippe 2 init Institut für industrielle Informationstechnik Liebigstraße Lemgo stefan.hausmann@hs-owl.de, stefan.heiss@hs-owl.de Abstract: Zukünftige Anlagenstrukturen in der Automatisierungstechnik werden stärker vermascht und dezentral organisiert sein, oder sogar weltweit mit anderen technischen Systemen über das Internet miteinander kommunizieren (Industrie 4.0, Cyber-Physical Systems (CPS) und Internet of Things (IoT)). Hierfür werden meist serviceorientierte Middleware-Systeme wie z.b. OPC-UA, Webservices oder openiot verwendet. Durch die Anwendung dieser Konzepte spielt die integrierte IT-Sicherheit aller beteiligten Komponenten eine immer größer werdende Rolle. Die fortschreitende Öffnung der Netzwerke zeigt, dass die bisher verfolgte Strategie der Abschottung von Automatisierungsanlagen durch weitere Maßnahmen ergänzt werden müssen. Mit OPC-UA ist eine Middleware für die Automatisierungstechnik spezifiziert worden, welche bereits integrierte IT-Sicherheitsfunktionalitäten bietet. Dieser Beitrag stellt die IT-Sicherheitsfunktionalitäten der UA Secure Conversation im Zusammenhang mit UA-Binary detailliert dar und vergleicht diese mit denen von SSL/TLS. Insbesondere werden diese im Hinblick auf ihre Sicherheit sowie die Eignung für eine Implementierung in kleinen eingebetteten Systemen untersucht. 1 Einleitung Der Trend der durchgängigen Integration von IT-Technologie bewirkt eine nachhaltige Veränderung in der Automatisierungstechnik. Die zunehmende Kommunikationsfähigkeit von Anlagenkomponenten ermöglicht diese stärker miteinander zu vernetzen, um Informationen über Ethernet-basierte Protokolle auszutauschen. Durch diese erweiterte Kommunikationsfähigkeit können Statusinformation weltweit flexibel abgerufen und so beispielsweise Fehlfunktionen früher erkannt werden (Industrie 4.0 [Fa13], Cyber-Physical Systems (CPS) [Le08] und Internet of Things (IoT) [Ho12]). Hierfür werden meist serviceorientierte Middleware-Systeme wie z.b. OPC-UA, Webservices oder openiot [IJ13] verwendet. Die Öffnung der Netzwerkstruktur ermöglicht also eine netzwerkübergreifende vertikale Kommunikation, wodurch sich allerdings auch neue IT- Sicherheitsrisiken ergeben. Aus diesem Grund muss die Strategie der Abschottung von Netzwerken um neue Konzepte und Maßnahmen ergänzt werden. In [Fa13] wird beispielsweise dargestellt, dass mit Industrie 4.0 die Bedeutung der IT-Sicherheit weiter zunehmen wird. An der deutschen Normungs-Roadmap zu Industrie 4.0 [VD13] ist zudem erkennbar, dass in diesem Kontext ein hoher Bedarf an standardisierten Vorgehensweisen und Modellen besteht. Eine Middleware-Lösung für die Automatisierungstechnik, die im Rahmen von Industrie 4.0 eine große Relevanz besitzt, ist OPC Unified Architecture (OPC UA). Vorteilhaft ist sowohl die Hersteller-, als auch Plattformunabhängigkeit. Darüber hinaus definiert OPC UA eigene IT-Sicherheitskonzepte, die den Untersuchungsgegenstand dieser Arbeit bilden. Feldgeräte verfügen nur über begrenzte Ressourcen bezüglich Rechenleistung und Speicherkapazität und stellen daher den Flaschenhals in Bezug auf die Performanz der Gesamtapplikation dar, wenn IT-Sicherheitsfunktionen zu der eigentlichen Funktionalität hinzugefügt werden. Somit bilden die Geräte der Feldebene die Untersuchungsgrundlage für Performanz- und Speicheranforderungen eines OPC UA Servers mit Sicherheitsfunktionalität. Dieser Beitrag stellt die IT-Sicherheitsfunktionalitäten der UA Secure Conversation (UA-SC) im Zusammenhang mit dem Binärprotokoll (UA-Binary) detailliert dar und vergleicht diese mit denen von SSL/TLS. Insbesondere werden diese im Hinblick auf ihre Sicherheit sowie die Eignung für eine Implementierung in kleinen eingebetteten Systemen untersucht. In Abschnitt 2 werden die Grundlagen bezüglich der IT-Sicherheitsmechanismen von OPC UA dargestellt, um in Abschnitt 3 die Protokollvariante, die UA-SC als Sicherheitsmechanismus verwendet, detailliert vorstellen zu können. In Abschnitt 4 wird der Verbindungsaufbau von SSL/TLS erläutert um im Abschnitt 5 eine Bewertung der OPC UA

2 Sicherheitsmechanismen vornehmen zu können. In Abschnitt 6 werden Messungen der Performanz dargestellt. Abschnitt 7 enthält ein kurzes Fazit. 2 OPC UA Überblick OPC UA unterstützt unterschiedliche Protokollvarianten, für die verschiedenen IT-Sicherheitsmechanismen verwendet werden. Die möglichen, in Abbildung 1 dargestellten Protokollpfade unterstützen entweder etablierte Verfahren wie SSL/TLS oder WS Secure Conversation (WS-SC) oder aber den durch OPC UA spezifizierten Sicherheitsmechanismus UA-SC. Im Fokus dieser Arbeit liegt der in Abbildung 1 links dargestellte Protokollpfad UA-TCP UA-SC UA-Binary. Generell setzt sich jeder Pfad aus verschiedenen Protokollen zusammen: der Kodierung, dem Transport- Protokoll, und dem Sicherheitsmechanismus. Der in dieser Arbeit detailliert untersuchte Protokollpfad verwendet die OPC UA binäre Kodierung zusammen mit der UA spezifischen Sicherheitsschicht UA-SC, die auf dem Transport-Protokoll TCP/IP aufsetzt. Eine weitere Protokolloption verwendet eine XML-Codierung, in Kombination mit WS-SC als Sicherheitsmechanismus über SOAP (Simple Object Access Protocol). Eine dritte Variante die, die Sicherheitsmechanismen von SSL/TLS verwendet, nutzt HTTP (Hypertext Transfer Protocol) als Transport und unterstützt sowohl die binäre, als auch die XML-Kodierung. Abbildung 1. OPC UA Protokollversionen basierend auf [MLD09, S ] 2.1 Sicherheitsrichtlinien OPC UA definiert verschiedene Sicherheitsrichtlinien (Security Policies), die Vorgaben bezüglich der zu verwendenden Algorithmen und Schlüssellängen machen. Je nach verwendeter Sicherheitsschicht (UA-SC, WS-SC oder SSL/TLS) wird ein anderer Richtliniensatz verwendet. Für UA-SC ist ein eigener Satz in der OPC UA Spezifikation definiert. WS-SC nutzt die durch die WebService-Spezifikation [OA] gegebenen Optionen und SSL/TLS verwendet die im Rahmen der SSL/TLS Spezifikation [DR08] definierten Chipher-Suites. Tabelle 1 zeigt die UA-SC spezifischen Sicherheitsrichtlinien, wobei jede Spalte eine Security Policy beschreibt. Die drei Policen stellen unterschiedliche Sicherheitslevel dar. Die Sicherheitslevel unterscheiden sich in den verwendeten kryptographischen Verfahren und vorgeschriebenen Schlüssellängen. Eine kritische Betrachtung der Sicherheitslevel befindet sich in Abschnitt 5.2. Alle drei gezeigten Policen verwenden den Advanced Encryption Standard (AES) für symmetrische Verschlüsselungen und das RSA-Verfahren für asymmetrische Verschlüsselungen und Signaturberechnungen.

3 Sicherheitsrichtlinie Basic128RSA15 Basic256 Basic256SHA256 Sym. Signatur HMAC SHA-1 HMAC SHA-1 HMAC SHA-256 Sym. Verschlüsselung AES-128 CBC AES-256 CBC AES-256 CBC Asym. Signatur RSA SHA-1 RSA SHA-1 RSA SHA-256 Asym. Verschlüsselung RSA 15 RSA OAEP RSA OAEP Asym. Schlüssellänge Bit Bit Bit Schlüsselableitungsverf. P_SHA-1 P_SHA-1 P_SHA-256 Tabelle 1: Sicherheitsrichtlinien der UA-SC 2.2 Nachrichtenaustausch zwischen Server und Client Jeder Nachrichtenaustausch von OPC UA Binary Nachrichten zwischen Server und Client findet nach einem bestimmten Muster statt (siehe Verlauf des Sequenzdiagramms in Bild 2). Zuerst wird eine TCP Verbindung aufgebaut. Auf diesem TCP-Kanal wird ein sicherer Kanal, der Secure Channel aufgebaut. Hierzu werden entsprechende Anfrage- und Antwort-Nachrichten zwischen Client und Server ausgetauscht. Wurde ein Secure Channel erfolgreich etabliert, so werden im Folgenden Session Nachrichten ausgetauscht. Innerhalb dieser Session Nachrichten werden die eigentlichen Prozessdaten übertragen. Zum Schutz der ausgetauschten Daten wird ein hybrides Verschlüsselungsverfahren verwendet: Die Secure-Channel-Nachrichten werden dabei durch asymmetrische und die Session-Nachrichten durch symmetrische Verfahren geschützt. Die Algorithmen werden entsprechend der unterstützten Security-Policen verwendet. Um die in den Policen definierten Algorithmen entsprechend verwenden zu können, müssen die vom Server unterstützten Security Policen beim Client bekannt sein. Diese Informationen werden vom Server mit einer Endpoint Description dem Client mitgeteilt. Die Endpoint Description ist eine Session Nachricht, die in einem eigenen Secure Channel übertragen wird, welcher noch keine Sicherheitsfunktionalitäten nutzt, da die benötigten Sicherheitsinformationen auf der Seite des Clients ja noch nicht bekannt sind. Erst nach dem Austausch der Endpoint Description ist eine gesicherte Kommunikation möglich. Mit der Endpoint Description überträgt der Server seine unterstützten Endpunkte. Jeder Endpunkt beinhaltet unter anderem die folgenden Informationen: das Zertifikat des Servers, den Sicherheits-Modus, und die Security Policy. Unter dem Sicherheits-Modus versteht man die Modi Signatur und Signatur & Verschlüsselung, mit denen der User wählen kann, welche Art des Schutzes er verwenden möchte. Der Begriff Signatur bezeichnet hier den Schutz einer Session-Nachricht gegen Manipulation mithilfe eines Message Authentication Codes (MAC). Neben den oben genannten Security Policen und den Sicherheits-Modi unterstützt OPC UA eine weitere Police, die Security Policy None. Diese wird in Zusammenhang mit dem Modus None verwendet und stellt eine Möglichkeit zur Nutzung eines OPC UA Servers ohne Sicherheitsfunktionen dar. Mit der Endpoint-Description bekommt der Client die unterstützten Sicherheitsrichtlinien des Servers und hat somit die Möglichkeit die folgenden Nachrichten mit diesem gesichert auszutauschen. Abbildung 2: Sequenzdiagramm eines OPC-UA Nachrichtenaustausches

4 3 UA Secure Conversation Die UA-SC ist für die Absicherung von OPC UA Binary spezifiziert. Nach einem Schlüsselaustausch mithilfe von RSA (OpenSecureChannel) werden alle weiteren Pakete mit symmetrischen Verfahren geschützt. Die UA-SC verwendet die in Abbildung 3 dargestellte Nachrichtenstruktur. Diese Grafik zeigt ebenfalls welcher Nachrichtenteil mit einem MAC geschützt und welcher Teil verschlüsselt wird. Je nachdem, ob es sich bei der Nachricht um eine Secure Channel oder eine Session Nachricht handelt, variiert der Security Header. Abbildung 3: Nachrichtenstruktur der UA Secure Conversation Nachrichten [OP12, S. 36] Der Austausch der symmetrischen Schlüssel erfolgt mithilfe der OpenSecureChannel-Nachrichten indem der Server und der Client eine Zufallszahl generieren. Diese Zufallszahl wird sicher übertragen. Aus beiden Zufallszahlen werden nun auf Client- und Serverseite die symmetrischen Schlüssel mithilfe einer key derivation function (KDF) [OP12, S. 42] gebildet. Kritisch ist bei diesem Verfahren, dass die Zufallszahlen geschützt sind, da auf ihnen allein die symmetrischen Schlüssel basieren. Außerdem muss die Authentizität von Server und Client sichergestellt werden. Um diese Anforderungen zu erfüllen werden die OpenSecureChannel-Nachrichten mit einer RSA-Signatur signiert und mit RSA verschlüsselt. Die verwendeten Schlüssel sind die RSA-Schlüsselpaare von Client und Server. Der Aufbau der OpenSecureChannel-Nachrichten ist in Abbildung 4 dargestellt. Zu erkennen ist, dass über die gesamte Nachricht eine RSA-Signatur gebildet wird und anschließend die gesamte Nachricht (die Signatur eingeschlossen) ab dem Sequence-Header mit RSA für die Gegenstelle verschlüsselt wird. Für eine Verschlüsselung mithilfe von RSA sind verschiedene Padding-Verfahren definiert, welche verhindern sollen, dass Klartextnachrichten ggf. anhand des Geheimtextes mit einem praktisch ausführbaren Brute-Force- Angriff ermittelt werden könnten. Für OPC UA sind das PKCS#1 v1.5 [JK03] sowie das OAEP-Padding [JK03] mit SHA-1 als Hashfunktion definiert. Durch das Padding wird zusätzlich die maximale Datenmenge begrenzt, die mit einer RSA-Operation verarbeitet werden kann. Die zusätzliche Größe des PKCS#1 v1.5 Padding beträgt 11 Byte und die zusätzliche Größe des OAEP-Paddings beträgt 42 Byte. Somit ergibt sich für eine RSA-Verschlüsselung mit einer Schlüssellänge von 2048 Byte eine maximale Blockgröße von 245 Byte für das PKCS#1 v1.5 Padding und 214 Byte für das OAEP-Padding. Die Signatur am Ende der Nachricht (die ja die volle RSA-Blockgröße einnimmt) muss also (gleiche Schlüssellängen von Client und Server vorausgesetzt) schon auf einen zweiten Block verteilt werden. Betrachtet man die Anzahl der benötigten privaten RSA-Operationen (die RSA-Berechnungen mit dem öffentlichen Schlüssel wurden vernachlässigt) auf einer Seite (Server oder Client) für eine Schlüssellänge von 2048 (Server und Client) ergibt sich die Darstellung in Tabelle 2. Die erhöhte Anzahl der benötigten Operationen in der Sicherheitsrichtlinie Basic256 begründet sich durch die Verwendung des OAEP-Paddings. Sicherheitsrichtlinie private RSA- Operationen Basic128Rsa15 3 Basic256 4 Tabelle 2: Benötigte RSA-Operationen bei verschiedenen Sicherheitsrichtlinien (2048 Bit RSA) Für die Session Nachrichten hingegen wird ein symmetrisches Verfahren und somit der symmetrische Security Header verwendet.

5 Abbildung 4: Struktur der OpenSecureChannel"-Nachrichten [OP12, S. 36] Des Weiteren werden mit den OpenSecureChannel -Nachrichten die öffentlichen RSA-Schlüssel jeweils an den Kommunikationspartner übertragen. Somit erlangt die Gegenseite Kenntnis über den Schlüssel und kann diesen für die Verschlüsselung von Nachrichten entsprechend nutzen. Der zugehörige private Schlüssel für die Entschlüsselung ist nur dem Besitzer dieses Schlüssels bekannt. Somit kann auch nur dieser eine mit dem öffentlichen Schlüssel verschlüsselte Nachricht wieder entschlüsseln. Wird eine andere Protokollversion von OPC UA verwendet und somit eine andere Sicherheitsschicht, so ändert sich entsprechend die Nachrichtenstruktur und die Elemente der einzelnen Nachrichten. Auffällig im Vergleich von UA-SC und WS-SC sind die Elemente der OpenSecureChannel Nachrichten. Bei UA-SC sendet der Server sein Zertifikat wiederholt an den Client mit seiner OpenSecureChannel Antwort, obwohl sein Zertifikat zuvor bereits mit seiner Endpoint Description übermittelt wurde. Bei WS-SC findet ein solcher wiederholter Austausch des Zertifikates nicht statt. In dem Anfragetyp der OpenSecureChannel Nachricht wird das Zertifikat als Element der Nachricht mitübertragen. Dieses Element fehlt für den Antworttyp, wodurch ein wiederholter Austausch des Zertifikates vermieden wird [OP12, S. 34f.]. 4 Transport Layer Security (SSL/TLS) Transport Layer Security (TLS) ist in seiner aktuellen Version 1.2 im RFC 5246 [DR08] definiert. TLS stellt eine sichere Kommunikationsschicht für TCP-Verbindungen zur Verfügung und wird beispielsweise für die Absicherung von HTTP-Verbindungen (HTTPS) verwendet. Auch für OPC UA sieht eine Verwendung von TLS im Zusammenhang mit HTTP vor (siehe Abbildung 1). Im Folgenden ist der Schlüsselaustausch von TLS beschrieben, um einen Vergleich mit dem Schlüsselaustausch von OPC-SC im Hinblick auf den Berechnungsaufwand zu ermöglichen. Ähnlich den Sicherheitsrichtlinien von OPC UA sind für TLS so genannte Chipher-Suiten definiert, die einen Satz von kryptographischen Algorithmen für den Schlüsselaustausch, die Authentifizierung, die Verschlüsselung und den Integritätsschutz der Nachrichten definieren. Für den Schlüsselaustausch sind unter anderen folgende Verfahren definiert: RSA: Schlüsselaustausch und Authentifizierung auf Basis von RSA. DHE_RSA: Schlüsselaustausch auf Basis von Diffie-Hellmann (kurzlebige Schlüssel) und Authentifizierung auf Basis von RSA. ECDHE_RSA: Schlüsselaustausch auf Basis von Elliptic Curve Diffie-Hellmann (kurzlebige Schlüssel) und Authentifizierung auf Basis von RSA. Zur Authentifizierung der Kommunikationspartner werden Zertifikate auf Basis von X.509 [Co08] verwendet. Dabei bietet TLS die Optionen nur den Server oder den Server und den Client zu authentifizieren.

6 4.1 Schlüsselaustausch RSA In diesen Abschnitt wird der TLS-Schlüsselaustausch (Handshake) auf Basis von RSA mit einer Authentifizierung des Clients beschrieben (Abbildung 5). Auf eine Darstellung ohne eine Clientauthentifizierung wurde verzichtet, da OPC UA diese Option nicht bietet. Server und Client besitzen jeweils ein RSA-Schlüsselpaar bestehend aus öffentlichen und privaten Schlüssel. Die öffentlichen Schlüssel sind mithilfe eines von einer vertrauenswürdigen CA erstellten X.509-Zertifikats an eine Identität gebunden. (1) Um einen TLS-Verbindungsaufbau zu starten, sendet der Client eine ClientHello -Nachricht an den Server. Diese Nachricht enthält eine neu generierte Zufallszahl des Clients, sowie eine Liste aller vom Client unterstützten Chipher-Suiten. (2)-(5) Der Server antwortet mit einer ServerHello -Nachricht in der unter anderem eine Zufallszahl des Servers sowie eine aus den Vorschlägen des Clients ausgewählte Chiper-Suite enthalten ist. In den nächsten Nachrichten sendet der Server sein Zertifikat (und damit seinen öffentlichen RSA-Schlüssel) zusammen mit einer optionalen Zertifikatskette, einen Zertifikats-Request und schließlich eine ServerHelloDone -Nachricht, welche dem Client mitteilt, dass der Server die Beantwortung der ClientHello -Nachricht abgeschlossen hat. (6)-(8) Im nächsten Schritt generiert der Client das Premaster Secret (PMS) und verschlüsselt es mit dem öffentlichen Schlüssel des Servers. Die Länge des PMS beträgt 48 Byte, so dass selbst bei kleinen RSA- Schlüssellängen nur eine RSA-Verschlüsselungsoperation benötigt wird. Das so verschlüsselte PMS wird innerhalb der ClientKeyExchange -Nachricht an der Server versendet. Außerdem versendet der Client sein Zertifikat mithilfe der Certificate -Nachricht an den Server. (9) Für die Authentifikation des Clients generiert der Client eine RSA-Signatur über alle bisher ausgetauschten Nachrichten und versendet diese in der CertificateVerify -Nachricht. (10) Der Client schließt mit der ChangeChiperSpec - und der Finished -Nachricht den Schlüsselaustausch ab. (11)-(12) Der Server kann nun das PMS entschlüsseln und die optionale Client-Signatur überprüfen. (13) Beide Seiten generieren nun das gemeinsame MasterSecret auf Basis vom PMS und den Zufallszahlen. Abbildung 5: TLS-Schlüsselaustausch RSA

7 4.2 Schlüsselaustausch DHE_RSA Bei einem Schlüsselaustausch mithilfe von DHE_RSA werden im ersten Nachrichtenaustausch dieselben Nachrichten wie bei RSA ( ClientHello, ServerHello, Certificate, CertificateRequest und ServerHelloDone ) ausgetauscht. Um einen Schlüsselaustausch mithilfe von Diffie-Hellmann (DH) zu ermöglichen generiert der Server seinen geheimen DH-Schlüssel X und generiert damit seinen öffentlichen DH-Wert dh_ys = g X mod p (2). Seinen öffentlichen DH-Wert sendet der Server in der ServerKeyExchange - Nachricht an den Client (3). Um den Besitz seines privaten RSA-Schlüssels nachzuweisen ist der öffentliche DH-Wert mit diesem signiert (4). Der Client verifiziert diese Signatur (5) und generiert anschließend ebenfalls einen privaten DH-Schlüssel Y und generiert damit den öffentlichen DH-Wert dh_yc = g Y mod p (6). Den öffentlichen DH-Wert versendet der Client in der ClientKeyExchange -Nachricht (7) an den Server. Der optionale Nachweis des Besitzes des privaten Schlüssels erfolgt wieder über die CertificateVerify -Nachricht (8). Die weiteren Nachrichten unterscheiden sich nicht. Server und Client können nun mithilfe von DH das PMS berechnen. Server: PMS = dh_yc X mod p, Client: PMS = dh_ys Y mod p (9). Der Server muss zusätzlich noch die Signatur vom Client überprüfen(10). Abbildung 6: TLS-Schlüsselaustausch DHE_RSA 4.3 Schlüsselaustausch ECDHE_RSA Der Schlüsselaustausch mithilfe von ECDHE_RSA funktioniert analog zu DHE_RSA mit dem Unterschied das Elliptic Curve Diffie-Hellmann verwendet wird.

8 5 Bewertung der OPC UA-SC Sicherheitsoptionen In diesem Abschnitt werden die Sicherheitsfunktionen von OPC UA-SC bewertet. Die Bewertung erfolgt getrennt in Hinblick auf den Verbindungsaufbau (Open Secure Channel) und die definierten Sicherheitsrichtlinien. 5.1 Verbindungsaufbau OPC UA-SC verschlüsselt die an die OpenSecureChannel -Nachrichten angehangene Signatur mit. Außerdem werden nicht geheime Teile der Nachricht wie der Sequence Header mit verschlüsselt. Aus diesen Gründen übersteigen die zu verschlüsselnden Daten die maximale Größe eines RSA-Blocks, so dass die RSA Ver-/Entschlüsselung mehrfach ausgeführt werden muss. Dies verursacht einen unnötigen Rechenaufwand der insbesondere auf kleinen eingebetteten Systemen die benötigte Zeit für einen erfolgreichen Verbindungsaufbau erheblich vergrößert. Die mehrfache Verschlüsselung macht insbesondere bei der Verwendung von Hardwaremodulen wie TPM bemerkbar, da diese bis zu 600ms [SEC_PRO] für die Ausführung einer privaten RSA-Operation (2048 Bit) benötigen. Innerhalb des Verbindungsaufbaus werden die zu den X.509-Zertifikaten gehörenden privaten Schlüssel für zwei unterschiedliche kryptographische Operationen (RSA-Signatur und RSA-Entschlüsselung) verwendet. Dies ist nicht empfehlenswert, da bedingt durch diese doppelte Verwendung unter Umständen Angriffe möglich sind [JGS13]. Eine Verwendung von Zertifikaten auf Basis von ECDSA (Elliptic Curve Digital Signature Algorithm) ist mit OPC UA in der so spezifizierten Form nicht möglich, da mit den zu diesen Zertifikaten gehörenden Schlüsseln nur Signaturen erstellt werden können. Auch ein ECDH-Schlüsselaustausch ist nicht möglich. Beispielsweise benötigt die Verwendung von ECDH und ECDSA-Zertifikaten bei einem SSL/TLS Verbindungsaufbau nur ungefähr ein Achtel der Rechenleistung im Vergleich mit RSA (2048 Bit RSA, 193 Bit ECC) [Gu02]. Tabelle 3 vergleicht die von OPC UA benötigten RSA-Operationen mit denen von SSL/TLS bei einer Schlüssellänge von 2048 Bit auf beiden Seiten und Verwendung der Sicherheitsrichtlinie Basic256 oder Basic256Sha256. Bei SSL/TLS ist unterschieden zwischen einem Verbindungsaufbau ohne Verwendung von Diffie-Hellmann und mit Verwendung von Diffie-Hellmann, wobei davon ausgegangen wird, dass der öffentliche DH-Schlüssel vorberechnet wurde. Für die Diffie-Hellmann Berechnung kann angenommen werden, dass diese vier privaten RSA-Operationen entspricht. OPC UA (Server) OPC UA (Client) SSL/TLS RSA (Server) SSL/TLS RSA (Client) SSL/TLS DH (Server) SSL/TLS DH (Client) RSA Entschlüsselung RSA Signatur Diffie- Hellmann Tabelle 3: Vergleich der benötigten asymmetrischen Operationen von OPC UA und SSL/TLS 5.2 Sicherheitsrichtlinien Die von OPC UA definierten Sicherheitsrichtlinien (Security Policies, vgl. Abschnitt 2.1) fassen verschiedene zu verwendende kryptographische Verfahren und Schlüssellängen in einer Gruppe zusammen. Zurzeit sind drei Gruppen definiert, welche anscheinend ein steigendes Sicherheitslevel darstellen sollen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) gibt in der Technischen Richtlinie TR [BSI] folgende Empfehlungen.

9 Schlüssellängen [Bu14, S. 15]: Blockchiffre MAC RSA DH ECDH ECDSA Tabelle 4: Empfohlene Schlüssellängen für verschiedene kryptographische Algorithmen [Bu14, S. 15] in Bit Außerdem gibt das BSI folgende relevante Empfehlung aus (Fett markiert sind die Algorithmen die auch für OPC UA definiert sind): Die Verwendung von Triple-DES, HMAC-MD5 und HMAC-SHA1 wird nicht empfohlen [Bu14, S. 18]. Für Blockchiffren wird der Einsatz von AES-128, AES-192 und AES-256 empfohlen [Bu14, S. 22]. Als Betriebsarten für Blockchiffren der GCM-, CBC- und CTR-Modus [Bu14, S. 23]. Als asymmetrische Verschlüsselungsverfahren RSA, ECIES und DLIES [Bu14, S. 28]. Als Paddingverfahren für RSA Ver- und Entschlüsselung OAEP [Bu14, S. 37]. Als Hashfunktionen: SHA-224, SHA-256, SHA-512/256, SHA-384, SHA-512, SHA-512/224 [Bu14, S. 38]. Als Message Authentication Codes: CMAC, HMAC und GMAC mit Schlüssellängen größer gleich 128 Bit [Bu14, S. 40]. Als Signaturverfahren RSA, DSA, ECDSA, ECKDSA und ECGDSA [Bu14, S. 42] Als Padding für eine RSA-Signatur: EMSA-PSS [Bu14, S. 43]. Für einen Schlüsselaustausch basierend auf asymmetrischen Verfahren: DH und ECDH [Bu14, S. 52] Angewendet auf die OPC UA Sicherheitsrichtlinien lassen sich folgende Aussagen über die Sicherheitsrichtlinien treffen: Die minimale asymmetrische Schlüsselänge (RSA) in Basic128RSA15 und Basic256 ist zu gering gewählt, hier sollte nur 2048 Bit erlaubt sein. Das Paddingverfahren für die RSA-Verschlüsselung (PKCS#1 v1.5) in Basic128RSA15 sollte laut BSI nicht mehr verwendet werden. Auf dieses Verfahren sind Angriffe bekannt [JSS12, Ba10]. Das Paddingverfahren für die RSA-Signatur von OPC UA (PKCS#1 v1.5) unterscheidet sich von der Empfehlung des BSI. Da der Einsatz von SHA-1 generell nicht mehr empfohlen wird, sollte für das Schlüsselableitungsverfahren, die Signatur und den HMAC in Basic128RSA15 und Basic256 auf SHA-256 gewechselt werden. Weiter lässt sich bei einem Vergleich der Sicherheitsrichtlinien feststellen, dass diese sich nur gering voneinander unterscheiden. Beispielsweise ändert sich zwischen Basic128RSA15 und Basic256 nur das Padding-Verfahren für die RSA-Verschlüsselung. 6 Untersuchungen des OPC UA Verbindungsaufbaus In [GKH14] wurde die Performanz von RSA sowie der OpenSecureChannel-Nachrichten auf einem eingebetteten System (SoC auf Basis eines ARM Cortex A9, 2 Kerne, 667 MHz) bestimmt. Insgesamt lässt sich sagen, dass der auf der beschriebenen Testumgebung realisierte OPC UA Server mit Sicherheitsfunktionalität (Police: Basic128Rsa15, Schlüssellänge: 2048 Bit) ca. eine halbe Sekunde benötigt um einen sicheren Kanal aufzubauen, in dem die Prozessdaten gesichert übertragen werden können.

10 7 Fazit In diesem Beitrag wurden die Sicherheitsoptionen von OPC UA betrachtet. Insbesondere wurde der Aufwand des Schlüsselaustauschs innerhalb der UPC UA-SC betrachtet und mit SSL/TLS verglichen. Außerdem wurden die von OPC UA definierten Sicherheitsrichtlinien mit aktuellen Empfehlungen vom BSI verglichen. Die Sicherheitsrichtlinien entsprechen nicht den aktuellen Empfehlungen des BSI, insbesondere die minimale RSA-Schlüssellänge von 1024 Bit in zwei Sicherheitsrichtlinien ist zu gering gewählt und sollte nicht verwendet werden. Die definierten Sicherheitsrichtlinien sind außerdem recht starr definiert und weisen eine mangelnde Flexibilität in Hinblick auf Erweiterungsmöglichkeiten auf. Beim Schlüsselaustausch (Verbindungsaufbau) der UA-SC wird die RSA-Verschlüsselung unnötig oft angewendet und verursacht somit im Vergleich zu einem SSL/TLS-Handshake eine etwa viermal so hohe Rechenlast. Insbesondere auf kleinen eingebetteten Systemen erhöht dies unnötig die Zeit, die für einen Verbindungsaufbau benötigt wird. 8 Literaturverzeichnis [Ba10] Bauer, A. et al.: On the Broadcast and Validity-Checking Security of pkcs#1 v1.5 Encryption. In (Zhou, J.; Yung, M. Hrsg.): Applied Cryptography and Network Security. Springer Berlin Heidelberg, 2010; S [Bu14] Bundesamt für Sicherheit in der Informationstechnik Bundesamt für Sicherheit in der Informationstechnik: BSI TR Kryptographische Verfahren: Empfehlungen und Schlüssellängen, [Co08] Cooper, D.; Santesson, S.; Farrell, S.; Boeyen, S.; Housley, R.; Polk, W. Cooper, D. et al.: Internet X.509 [DR08] Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. IETF, Dierks, T.; Rescorla, E. Dierks, T.; Rescorla, E.: The Transport Layer Security (TLS) Protocol Version 1.2. IETF, [Fa13] Forschungsunion; acatech: Umsetzungsempfehlungen für das Zukunftsprojekt Industrie 4.0. Abschlussbericht des Arbeitskreises Industrie 4.0. Deutschlands Zukunft als Produktionsstandort sichern., [GKH14] [Gu02] [Ho12] [IJ13] [JGS13] [JK03] [JSS12] Gallinat, M.; Köster, M.; Heiss, S.: Bewertung der IT-Sicherheitskonzepte von OPC-UA für den Einsatz in Feldgeräten: SPS/IPC/Drives, Gupta, V. et al.: Performance analysis of elliptic curve cryptography for SSL: Proceedings of the 1st ACM workshop on Wireless security, 2002; S Houyou, A. M. et al.: Agile manufacturing: General challenges and an IoT@Work perspective: Emerging Technologies & Factory Automation (ETFA), 2012 IEEE 17th Conference on, 2012; S Imtiaz, J.; Jasperneite, J.: Scalability of OPC-UA down to the chip level enables Internet of Things : Industrial Informatics (INDIN), th IEEE International Conference on, 2013; S Jager, T.; G. Paterson, K.; Somorovsky, J.: One Bad Apple: Backwards Compatibility Attacks on Stateof-the-Art Cryptography: Proceedings of the Network and Distributed System Security Symposium (NDSS), Jonsson, J.; Kaliski, B. Jonsson, J.; Kaliski, B.: Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1. IETF, Jager, T.; Schinzel, S.; Somorovsky, J.: Bleichenbacher s Attack Strikes again: Breaking PKCS#1 v1.5 in XML Encryption. In (Foresti, S.; Yung, M.; Martinelli, F. Hrsg.): Computer Security ESORICS Springer Berlin Heidelberg, 2012; S [Le08] Lee, E. A.: Cyber Physical Systems: Design Challenges: Object Oriented Real-Time Distributed Computing (ISORC), th IEEE International Symposium on, 2008; S [MLD09] Mahnke, W.; Leitner, S.-H.; Damm, M.: OPC unified architecture. Springer, Berlin u.a, [OA] OASIS: WS-SecureConversation [OP12] OPC Foundation: OPC Unified Architecture Specification Part 6: Mappings, [SEC_PRO] SEC_PRO: Sichere Produktion mit verteilten Automatisierungssystemen. [VD13] VDE/DKE: Die deutsche Normungs-Roadmap Industrie