Bodén, R. + Winkler, T.: Sichere Anbindung von Embedded Systems

<BODY> <H1>www.duv24.net : Bodén, R. + Winkler, T.: Sichere Anbindung von Embedded Systems </H1> <P> <BR> [<A href="/">www.duv24.net</A>] [<A href="../index.html">back</A>] </P> <TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0> <TR> <TD VALIGN=top> <TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0> <TR> <TD VALIGN=TOP CLASS=detailBereichRedaktion>Bereich > Redaktion > <B><FONT color="#CC3300">Fachbeiträge</FONT></B></TD> <TD ALIGN=right VALIGN=bottom CLASS=detailDatum>20.04.2001</TD> </TR> </TABLE> </TD> <TD VALIGN=top> </TD> <TD VALIGN=top> </TD> </TR> <TR> <TD VALIGN=top CLASS=detailFirma ID=topSpace>OSE Systems GmbH:</TD> <TD VALIGN=top> </TD> <TD VALIGN=top> </TD> </TR> <TR> <TD VALIGN=top CLASS=detailTitel>Bodén, R. + Winkler, T.: Sichere Anbindung von Embedded Systems </TD> <TD VALIGN=top> </TD> <TD VALIGN=top> </TD> </TR> <TR> <TD VALIGN=top CLASS=detailSubtitel>Keine Unbefugten Zugriffe mehr aus dem Netz</TD> <TD VALIGN=top> </TD> <TD VALIGN=top> </TD> </TR> <TR> <TD VALIGN=top> <TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0> <TR> <TD VALIGN=top CLASS=detailContent>Erschienen in DESIGN & VERIFICATION 03/2001, S. 40-43<BR>(pdf-Version in toolbox unter "details")<BR><BR>Vorwort<BR><BR>Die Anbindung von Embedded Systemen an das Internet bietet enorme Vorteile, ließen sich doch viele Aufgaben einfach per Fernwartung erledigen. Trotzdem ist diese Methode noch nicht sehr weit verbreitet. Grund dafür ist mangelnder Schutz der Daten vor Hackerangriffen. Mit neuen Standards lässt sich dieses Sicherheitsleck jetzt schließen.<BR><BR>Einleigung<BR><BR>Serviceeinsätze und Updates bei Embedded Systemen erfordern im Moment noch die Anwesenheit eines Technikers vor Ort. Wäre ein Geräte mit dem Internet verbunden, ließen sich die meisten Aufgaben problemlos aus der Ferne erledigen. In der Industrie ist man sich dieser Möglichkeiten durchaus bewusst. Trotzdem ist in diesem Zusammenhang die Nutzung des Internets noch nicht sehr verbreitet. Der Hauptgrund liegt in der fehlenden Datensicherheit. Viele Embedded Systeme führen sicherheitskritische Aufgaben aus, wie zum Beispiel in der Flugzeug- oder Prozesssteuerung. In anderen Bereichen, wie der Data- oder Telekommunikation geht es um vertrauliche geschäftliche Daten. Falls es einem Hacker oder Mitbewerber gelänge, Zugriff zu erlangen, wären die Folgen schwerwiegend. Dank der Einführung moderner Sicherheitsprotokolle wie SSL, IPSec und IKE ist eine sichere Kommunikation über das ungeschützte Internet möglich.<BR><BR>Hauptteil<BR><BR>Internet-Protokoll ohne Schutz<BR>Das Internet-Protokoll IP an sich besitzt keine Sicherheitsfunktionen. Alle Daten, die auf diesem Weg übertragen werden, sind komplett ungeschützt. Daraus ergeben sich verschiedene Probleme:<BR><BR>Keine Überprüfung der Identität von Sender und Empfänger<BR>Während der Kommunikation über das IP-Portokoll wird die Identität der Kommunikationspartner nicht überprüft. Zwar ist die IP-Adresse bekannt, sie ist allerdings einfach zu simulieren und stellt daher keine zuverlässige Information dar. <BR>Daraus ergeben sich für die Sender- und Empfängerseite Probleme. Die Serverseite benötigt die Gewissheit der korrekten Identität um beispielsweise sicherzugehen, dass der Kommunikationspartner eine Berechtigung besitzt. Die Client-Seite muss sicher sein, mit dem richtigen Server verbunden zu sein, bevor zum Beispiel vertrauliche Daten übertragen werden.<BR><BR>Daten können von unautorisierten Personen gelesen werden<BR>Alle Daten werden unverschlüsselt über das Internet Protokoll übertragen. Das bedeutet, sie sind völlig ungeschützt vor unberechtigtem Lesen. So lassen sich Passwörter stehlen oder vertrauliche Informationen während der Übertragung aufzeichnen.<BR><BR>Daten lassen sich verändern<BR>Der Empfänger hat keine Möglichkeit festzustellen, ob die eingegangenen Daten seit ihrem Versand modifiziert wurden. Gelangen falsche Informationen in ein sensibles System, können die Konsequenzen schwerwiegend sein. <BR><BR>Nachrichten können aufgezeichnet und wiederholt werden<BR>Um Schaden anzurichten, muss ein Angreifer die Details einer Nachricht nicht notwendigerweise verstehen. Es reicht aus, diese aufzuzeichnen und zu einem späteren Zeitpunkt zu wiederholen. Der Angreifer kann zum Beispiel die Rekonfigurations-Kommandos an ein System aufzeichnen und später wiedergeben. Zu diesem späteren Zeitpunkt sind diese Befehle aber wahrscheinlich veraltet, wodurch das ganze System geschädigt werden kann. Hierbei handelt es sich um einen typischen Sabotage-Akt. Auch wenn der Angreifer daraus keinen persönlichen Nutzen zieht, sind diese heute im Internet weit verbreitet.<BR><BR>Sicherheit im Applikations-Protokoll<BR>Da es dem Internetprotokoll an jeglichen Sicherheitsfunktionen fehlt, bleibt die Verantwortung bei der Applikation. Jedes Applikationsprotokoll muss gezwungenermaßen eigene Sicherheitsvorkehrungen bieten. Zuverlässige Sicherheit zu designen, erfordert einen erheblichen Arbeitsaufwand; zu viel, um derlei Funktionen in jedes einzelne Protokoll zu implementieren. Aus diesem Grund beinhalten viele Applikationsprotokolle nur wenige und dazu schlechte Sicherheitsfunktionen. Manche Protokolle besitzen sogar keinerlei Sicherheit:<BR><BR>Telnet (Remote Terminal Protocol)<BR>Das Einloggen über ein Telnet-Protokoll erfordert meistens ein Passwort. Dieses wird dann unverschlüsselt im Netzwerk übertragen und ist somit eine leichte Beute für jeden, der den Internet-Verkehr abhören will.<BR><BR>FTP (File Transfer Protocol)<BR>FTP-Verbindungen sind ebenfalls unverschlüsselt. User-IDs und Passwörter für das Log-In können von jedem gestohlen werden, der sich in die Kommunikation einschaltet. Die ausgetauschten Daten sind ebenfalls vollkommen ungeschützt vor unberechtigtem Lesen oder Modifizierungen.<BR><BR>SNMP (Simple Network Management Protocol)<BR>Das SNMP-Protokoll dient zur Verwaltung von Netzwerkgeräten. Es verwendet einen gemeinschaftlichen Datenstrang zur Identifikation, was der Abfrage einer User-ID ohne Passwort gleich kommt. Dementsprechend ist es sehr einfach, eine gefälschte SNMP-Anfrage zu senden. Es besteht keine Garantie, dass eine Anfrage während des Transfers über das Netzwerk nicht verändert wurde. Ein Rekonfigurations-Befehl, der modifiziert wurde, könnte verheerende Auswirkungen hervorrufen, ebenso wie die Wiederholung von Anfragen. Aufgrund seiner Sicherheitsmängel wurde SNMP bisher nicht als Management-Protokoll eingesetzt.<BR><BR>HTTP (Hyper Text Transfer Protocol)<BR>Das HTTP-Protokoll beinhaltet die Funktion ‚Basic Authentication‘ zum Transport von User-ID und Passwort. Diese sind trotz einer Verschlüsselung im 64-bit-Algorithmus extrem einfach zu enträtseln. In den letzten Jahren erhielten bereits viele Embedded Systeme eine Web-Anbindung zur Verwaltung. Die Vorteile liegen auf der Hand, denn die Systeme erhalten ein sehr kostengünstige und vielseitige Benutzerschnittstelle. Die Auswirkungen auf die Sicherheit sind jedoch dementsprechend folgenschwer. Die benutzten Passwörter lassen sich problemlos ausspionieren, sensible Konfigurations-Informationen sind für dritte Personen leicht lesbar, es gibt keine Sicherheit, dass Konfigurations-Updates während des Transfers nicht geändert wurden, ungewollt wiederholte Nachrichten können nicht nachvollzogen werden.<BR><BR>Die Lösung: SSL, IPSec und IKE<BR>Secure Socket Layer (SSL), auch bekannt als Transport Layer Security (TLS), IP Security (IPSec) und Internet Key Exchange (IKE) sind moderne Sicherheitsprotokolle. Sie bieten Funktionen wie Authentifizierung, Verschlüsselung, Integrität und Wiederholungs-Schutz und schützen damit zuverlässig vor allen genannten Bedrohungen. SSL und IPSec/IKE bieten sehr ähnliche Sicherheitsdienste. Der Hauptunterschied zwischen den beiden Protokollen liegt darin, dass die Sicherheit auf verschiedenen Ebenen der Systemstruktur impliziert ist. SSL sitzt in der Applikation, IPSec im TCP/IP-Stack.<BR>Die Protokolle wurden so entworfen, dass eine minimale Beeinflussung der Applikation sichergestellt ist. IPSec ist für die Applikation völlig durchsichtig, während SSL nur geringe Änderungen in der Applikation erfordert. <BR>Da die Sicherheitsdienste auf einem unteren Level liegen, ist die Applikation selbst von allen Sicherheitsaspekten entlastet. Alle dort ankommenden Daten sind garantiert authentisch, vertraulich, unmodifiziert und nicht wiedeholt. Damit lassen sich Applikationen wesentlich einfacher designen. Ferner ermöglichen SSL, IPSec und IKE die Sicherung von ungeschützten Protokollen. Ein gutes Beispiel dafür ist SNMP, das aufgrund seiner Sicherheitslücken bisher nur beschränkt eingesetzt werden konnte. In Verbindung mit IPSec kann SNMP gesichert über offene Netzwerke kommunizieren, ohne dass eine einzige Codezeile in der SNMP-Implementation geändert werden muss.<BR>SSL und IPSec werden von der offiziellen Internet Engineering Task Force (IETF) spezifiziert. Dadurch ist eine Interoperabilität garantiert.<BR><BR>Beschreibung des SSL<BR>SSL sitzt zwischen dem TCP/IP-Stack und der Applikation. Wenn sich eine SSL-Verbindung aufbaut, wird zunächst eine ‚Handshake‘-Prozedur eingeleitet. Es erfolgt die Authentifizierung sowie der gesicherte Austausch von Codeschlüsseln. Die Algorithmen für die Verschlüsselung, Integrität und Wiederholungs-Suche werden ebenfalls festgelegt.<BR>Sämtliche Informationen aus dem Handshake-Prozess werden in einer sogenannten SSL-Session gespeichert. Diese Sessions können für eine spätere Kommunikation wiederverwendet werden, wodurch subsequentielle Verbindungen mit einem minimalen Overhead durchgeführt werden. Dies ist insbesondere für echtzeitfähige Embedded Systeme ein großer Vorteil, da ein kompletter Handshake in bestimmten Situationen zu lange dauern würde. Die Applikation kann bereits während des Startvorgangs eine SSL-Verbindung aufbauen, um eine SSL-Session zu speichern. Wenn ein echter Kommunikationsvorgang ansteht, ist der Verbindungsaufbau sehr schnell.<BR>Sobald eine SSL-Verbindung steht, werden alle Daten auf der Senderseite verschlüsselt und auf der Empfängerseite wieder entschlüsselt. Zusätzlich liefert der Sender Informationen, an Hand denen der Empfänger feststellen kann, ob die Nachricht tatsächlich vom Sender stammt, und das sie weder modifiziert noch wiederholt wurde. Alle Vorgänge sind für die Logik der Applikation völlig unsichtbar.<BR>SSL ist bereits der De-Facto-Standard für zahlreiche Applikations-Protokolle. Das bekannteste ist HTTP, weitere Beispiele sind LDAP, SMPT, IMAP und POP3.<BR><BR>Beschreibung von IPSEc und IKE<BR>IPSec bietet Authentifizierung, Verschlüsselung, Integritäts-Checks und Wiederholungssschutz auf Netzwerkebene. Daraus folgt, dass jedes IP-Paket geschützt werden kann und gleichzeitig die Sicherheitsfunktionen von der Applikation völlig unbemerkt ablaufen. Um seine Aufgaben auszuführen, benötigt IPSec mehrere Schlüssel. Diese werden über IKE sicher ausgetauscht.<BR>IPSec ist vielseitig konfigurierbar. So kann basierend auf Quell- und Zieladresse sowie Port spezifiziert werden, auf welche Pakete die Sicherheit angewandt werden soll. Auf diesem Weg lassen sich wahlweise die gesamte Kommunikation oder nur bestimmte Applikationen und festgelegte Ziele absichern. Die Konfiguration kann an die spezifische Notwendigkeit jeder Situation angepasst werden.<BR>Ein Vorteil von IPSec/IKE liegt darin, dass bereits bestehende Applikationen ohne weitere Modifikation gesichert werden können, da IPSec im TCP/IP-Stack sitzt. Die Applikation kommuniziert per TCP und/oder UDP und bemerkt von der aufgesetzten Sicherheit nichts. Mit den genannten Konfigurations-Optionen lässt sich die Sicherheit während der Laufzeit beliebig ein- oder ausschalten.<BR>Über IKE werden beim Startvorgang notwendige Schlüssel ausgetauscht. Diese stehen damit für das IPSec zur Verfügung, das die Sicherheit ohne Verzögerungen aufsetzen kann, sobald die Applikation zu kommunizieren beginnt. Diese Eigenschaft ist insbesondere wieder für embedded Echtzeitanwendungen von Bedeutung und ähnelt der bereits beschriebenen Vorgehensweise bei SSL-Sessions.<BR>IPSec und IKE erfreuen sich einer rasch wachsenden Akzeptanz in der Industrie und entwickeln sich eindeutig zu einem Standard für IP-Sicherheit. Eine große Anzahl an weitverbreiteten Server- und Desktop-Betriebssystemen unterstützen IPSec und IKE, wie zum Beispiel Solaris, Windows 2000, HP-UX oder Linux.<BR><BR>Zusammenfassung<BR><BR>Die Vorteile, die eine Anbindung von Embedded Geräten an das Internet mit sich bringt, sind verlockend. Aufgrund von Sicherheitsmängeln hat sich diese Vorgehensweise allerdings bisher noch nicht durchsetzen können. Mit dem Aufkommen der Protokolle SSL, IPSec und IKE ist es nun aber möglich, Embedded Systeme sicher anzubinden. Welches Protokoll Einsatz findet, hängt größtenteils von den Aspekten der Interoperabilität ab. Wird das Protokoll der Applikation mit SSL verwendet, wie bei HTTP oder LDAP, ist SSL die offensichtliche Wahl. Bei überwiegender IPSec-Nutzung oder wenn das Applikations-Protokoll keinen festgelegten Standard für eine gesicherte Kommunikation besitzt, bieten sich IPSec und IKE an.<BR>Die Protokolle SSL, IPSec und IKE existieren neben der Applikation, was den Einfluss auf das Design minimiert oder komplett eliminiert. Da die Protokolle von der IETF spezifiziert werden, garantiert dies eine gesicherte Interoperabilität. <BR><BR></TD> </TR> <TR> <TD CLASS=detailQuelle> </TD> </TR> </TABLE> </TD> <TD WIDTH=28 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=1 HEIGHT=1 ALT=""></TD> <TD WIDTH=174 VALIGN=top></TD> </TR> <TR> <TD VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=393 HEIGHT=1 ALT=""></TD> <TD WIDTH=28 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=28 HEIGHT=1 ALT=""></TD> <TD WIDTH=174 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=174 HEIGHT=1 ALT=""></TD> </TR> </TABLE> <P><I>Diese Seite wurde am 25.09.2004, 13:11 Uhr aktualisiert</I></P> </BODY>