Sicherheit

Verteilte Systeme im Internet nutzen Übertragungswege, die auch von anderen Partnern genutzt werden. Neben den Nutzern, die diese Wege in friedlicher Absicht mitbenutzen, hat man es auch mit solchen zu tun, die das Ziel verfolgen, Kommunikationen zu stören oder unrechtmäßig an vertrauliche Informationen zu kommen. Ein verteiltes System ist gegen solche Angreifer geeignet zu schützen. Nach [Web10, S. 285] ergeben sich vier Säulen für sichere Anwendungen:

  • Vertraulichkeit

    Ist die Fähigkeit, Daten vor dem Zugriff unberechtigter Dritter zu schützen.

  • Integrität

    Ist die Fähigkeit, Nachrichten während ihrer Übertragung vor Manipulation zu schützen.

  • Identität

    Ist die Fähigkeit, die Identität der Nutzer nachzuweisen. Die Durchführung eines solchen Nachweises bezeichnet man als Authentifizierung.

  • Vertrauen

    Ist die Fähigkeit, beteiligte Parteien für bestimmte Aktionen zu autorisieren.

Hier werden Mechanismen zur Sicherstellung der Vertraulichkeit und der Integrität beschrieben.

Grundsätzlich unterscheidet man zwischen nachrichtenbasierter und transportbasierter Sicherheit. Beim nachrichtenorientierten Ansatz wird die Nachricht geeignet geschützt, d. h. verschlüsselt und signiert und kann dann über einen ungesicherten Transportmechanismus übertragen werden. Bei der transportbasierten Sicherheit wird der Übertragungskanal gesichert. Die Nachricht kann dann unverschlüsselt übertragen werden.

Zunächst müssen die Sicherheitsanforderungen definiert werden. Diese Anforderungen nennt man Security Policy. Eine Security Policy legt genau fest, was in einem System erlaubt ist und was nicht. Aus der Security Policy werden dann die Maßnahmen festgelegt, die das gewünschte Verhalten sicherstellen. Diese Maßnahmen nennt man Security Mechanisms. Hierzu zählen insbesondere die Verschlüsselung, die Authentisierung, die Autorisierung und die Auditierung. Auditierung wird hier nicht weiter beschrieben.

Verschlüsselung

Bei der Verschlüsselung handelt es sich um das Umformen der Daten in etwas, was ein Angreifer nicht versteht. Hierdurch wird Geheimhaltung gewährleistet. Außerdem kann man durch Verschlüsselung erkennen, ob Daten verändert wurden, was den Grundsatz der Integrität unterstützt. Ver- und Entschlüsselung werden mittels kryptografischer Methoden realisiert, mit Schlüsseln als Parameter. Grundsätzlich unterscheidet man zwischen symmetrischer und asymmetrischer Verschlüsselung. Bei der symmetrischen Verschlüsselung sind die Schlüssel zum Ver- und Entschlüsseln gleich. Bei der asymmetrischen Verschlüsselung sind die Schlüssel ein eindeutiges Paar, jedoch zum Ver- und Entschlüsseln verschieden. Bei der asymmetrischen Verschlüsselung ist ein Schlüssel geheim und der andere öffentlich. Daher werden asymmetrische Verschlüsselungssysteme auch oft Public-Key Systeme genannt.

Ein schwieriges Thema im Bereich des Schüssel Managements ist die Verteilung von initialen Schlüsseln. Diese müssen in einem symmetrischen Verschlüsselungssystem über einen sicheren Übertragungskanal übertragen werden. Bei asymmetrischen Verschlüsselungssystemen muss der öffentliche Schlüssel in einer Form übertragen werden, die dem Empfänger sicherstellt, dass dieser Schlüssel tatsächlich zu einem bestimmten privaten Schlüssel gehört [Tan07, S. 430 ff.]. Um dieses Verteilungssystem zu lösen, werden Schlüssel über Zertifikate erzeugt.

Zertifikate

Ein öffentlich verschlüsseltes Zertifikat, üblicherweise nur Zertifikat genannt, ist ein digital signiertes Statement, das den Wert eines öffentlichen Schlüssels an die Identität einer Person oder eines Services bindet, das den korrespondierenden privaten Key hält. Öffentlich signierte Zertifikate stammen von einem sogenannten Stammzertifikat ab. Diese Stammzertifikate werden auf Rechnersystemen vorinstalliert, so dass der Client die Abstammung verifizieren kann. Einer der Vorteile von Zertifikaten ist, dass der Host nicht mehr die Kennwörter der Nutzer und deren individuellen Authentifizierungsinformationen pflegen muss, sondern dem Herausgeber des Zertifikates vertrauen kann.

Zertifikate spielen in der abgesicherten Kommunikation über das Internet eine wichtige Rolle. Die Kommunikationspartner können damit ihre Identität beweisen und gleichzeitig einen privaten, verschlüsselten Kanal zueinander aufbauen. Ein Zertifikat ermöglicht diese Verschlüsselung. Die Authentifizierung des Kommunikationspartners ist wichtig für das Vertrauen. Sicherheitsproblem hier ist, zu verifizieren, ob der Public Key von einer Webseite wirklich zum gewünschten Kommunikationspartner gehört. Die Garantie selber wird Zertifikat genannt [Kri08, S. 90]. Jedes Zertifikat enthält daher eindeutige authentifizierende Informationen über den Eigentümer des Zertifikats. Dazu gehört die Identität des Antragstellers, die der zertifizierenden Stelle, Gültigkeitsperiode des Zertifikats und natürlich der Public Key des Antragstellers nebst Informationen über die eingesetzten Algorithmen [Kri08, S. 91]. Ein Zertifikat ist im Wesentlichen eine von einer vertrauenswürdigen Instanz, der Certification Authority (CA), digital signierte Bestätigung, dass eine bestimmte Identität und ein bestimmter Public Key zusammen gehören [Kri08, S. 91]. Die CA verifiziert die Identität des Zertifikateigentümers, bevor das Zertifikat ausgestellt wird. Je nach Einsatzfeld des ausgestellten Zertifikats kann die CA auch eine innerbetriebliche Instanz sein, sofern die in den Zertifikaten enthaltenen Public Keys nur innerhalb einer bestimmten Firma bzw. Domäne verwendet werden [Kri08, S. 92]. Um eine möglichst weitreichende Kompatibilität auch über System- und Firmengrenzen hinweg zu gewährleisten, existiert für das Format von Zertifikaten ein Standard, nämlich das X.509 Format der ITU (International Telecommunications Union) [Kri08, S. 90]. Zertifikate lösen das Verteilungsproblem und können zur Authentifizierung eines Systems herangezogen werden.

Transport Layer Security (TLS) / Secure Sockets Layer (SSL)

Eine wichtige Implementierung des Public-Key-Verfahrens ist SSL/TLS und ist in RFC 2246 [Die99] spezifiziert. SSL steht für Secure Socet Layer und wurde von der IETF 1999 definiert. Der Nachfolger von SSL ist TLS (Transport Layer Security), welches auf SSL v3 aufbaut, damit jedoch nicht kompatibel ist. SSL/TLS sitzt zwischen dem Application Layer und dem Transport Layer und wird hauptsächlich zusammen mit TCP verwendet. Weiterhin unterstützt SSL/TLS eine Vielzahl an Verschlüsselungs- und Komprimierungsmethoden und verwendet sowohl symmetrische als auch asymmetrische Verschlüsselung. Das SSL/TLS-Protokoll besteht aus zwei wichtigen und voneinander unabhängigen Prozessen: Der Authentifizierung und der Datenstromverschlüsselung.

Das SSL/TLS-Protokoll funktioniert folgendermaßen: Ein Client versucht, eine Verbindung zu einem mit SSL/TLS gesicherten Service herzustellen. Der Client fordert die Identität des Servers an, der eine Kopie seines SSL/TLS-Zertifikats an den Client sendet. Der Client überprüft, ob das SSL/TLS-Zertifikat glaubwürdig ist. Bei erfolgreicher Überprüfung sendet er eine Nachricht an den Server. Der Server sendet anschließend eine digital signierte Bestätigung zurück, um eine SSL/TLS-verschlüsselte Sitzung einzuleiten. Danach sind Client und Server in der Lage, Daten über einen verschlüsselten, privaten Kanal über das öffentliche Internet auszutauschen. Dieser Sitzungsschlüssel wird auch Session-Key genannt und ist ein gemeinsamer, geheimer Schlüssel, mit dem Nachrichten verschlüsselt werden. Der Session-Key sorgt sowohl für Geheimhaltung als auch für Integrität. Ein solcher Schlüssel wird nur so lange genutzt, wie der Übertragungskanal existiert.

HTTPS

HTTP ist ein Protokoll ohne eigene Sicherheitsmechanismen. Um Verbindungen abzusichern, wird zusätzlich SSL/TLS eingesetzt. Erkennbar ist eine SSL/TLS geschützte HTTP-Verbindung durch das angehängte “S” – HTTPS. In Bezug auf das OSI-Referenzmodell liegt TLS über TCP/IP, aber unter dem HTTP-Protokoll. Daher wird SSL/TLS in der Regel der Darstellungsschicht zugeordnet. Im TCP/IP-Modell ist TLS oberhalb der Transportschicht und unterhalb der Anwendungsschicht angesiedelt. Für die Anwendungen arbeitet TLS/SSL transparent. “HTTP over TLS” ist in RFC 2818 spezifiziert [Res00].

Der Server muss über ein geeignetes Zertifikat verfügen. Dieses sollte von einer vertrauenswürdigen Zertifizierungsstelle stammen. Reine HTTP-Verbindungen kommunizieren standardmäßig über Port 80 oder 8080, während HTTPS i. d. R. Port 443 nutzt. Ein HTTP/TLS-Request basiert auf referenzieren eines URI, wodurch dem Client der Hostname des Servers bekannt ist. Dadurch ist der Client in der Lage, die Identität des Servers über die erhaltene Server-Zertifikats-Nachricht zu verifizieren. Zunächst hat der Server bei einer SSL/TLS-Verbindung keine Kenntnis von der Identität des Clients.

Unter einem Man-In-The-Middle-Angriff versteht man das Abfangen, das Einfügen, das Löschen und die Modifikation von Nachrichten, sowie das Wiederholen alter Nachrichten und das Umleiten von Nachrichten. Hiervon betroffen sind besonders anonyme Sessions. Beim Abhören von Nachrichten besteht das Problem in der Übermittlung des gemeinsamen Geheimnisses. Schutz davor kann man nur erreichen, wenn sich mindestens der Server authentifiziert und für die gemeinsame Kommunikation ein Sitzungsschlüssel erzeugt wird. Mit SSL/TLS ist eine sichere Ende-Zu-Ende-Verschlüsselung und die Authentifizierung mindestens einer Seite möglich. SSL/TLS ist robust gegen Man-in-the-Middle Angriffe und ein Abhören von Nachrichten ist ebenfalls nicht möglich, da der private Schlüssel nicht mit übertragen wird.

 

[Die99] T. Dierks and C. Allen. (1999, Jan.) RFC 2246 – The TLS Protocol Version 1.0. [Online]. http://tools.ietf.org/html/rfc2246

[Kri08] Walter Kriha and Roland Schmitz, Internet-Security aus Software-Sicht. Berlin Heidelberg: Springer-Verlag, 2008.

[Res00] E. Rescorla. (2000, May) RFC 2818 – HTTP Over TLS. [Online]. http://tools.ietf.org/html/rfc2818

[Tan07] Andrew S. Tanenbaum and Maarten Van Steen, Distributed Systems.: Pearson Education, 2007.

[Web10] Jim Webber, REST in practice – Hypermedia and Systems Architecture, O’REILLY, Ed. Beijing, Cambridge, Farnham, Köln, Sebastopol, Tokyo, 2010, TWP 9502.

Leave a Reply