|
|
| Client-Server Authentisierung |
|
Bei der Client-Server-Architektur handelt es sich um eine Rechnerarchitektur, bei der bestimmte Rechner (Server) für andere Rechner (Clients) Dienstleistungen bereitstellen und abwickeln. Dazu bedarf es einer Methode der Zugriffskontrolle (Benutzerauthentifizierung). |
| Benutzer-ID und Passwort |
| Die am weitesten verbreitete Methode der Benutzerauthentifizierung basiert auf dem Gebrauch von Passwörtern, die während des Anmeldevorgangs eingegeben werden. Diese Passwörter müssen dem IT-System bekannt sein. |
|
Zur Anmeldung überträgt ein Benutzer seinen Benutzernamen und sein Passwort über das Intranet / Internet zu einem Server. Die Übertragung des Passworts während des Anmeldevorgangs muss grundsätzlich verschlüsselt erfolgen. Die Speicherung eines Passworts in einer Passwortdatei muss ebenfalls verschlüsselt erfolgen. Dabei können z.B. die Algorithmen DES (Verwendung z.B. unter Unix und LAN-Manager) oder MD5 (Verwendung z.B. unter Windows NT) Anwendung finden. Es ist dafür zu sorgen, dass die Passwortdatei vor unberechtigten Zugriffen über das Netzwerk geschützt wird. Hierzu sind unter Windows NT entsprechende Berechtigungen zu verweigern und unter UNIX ist mit Shadow-Dateien zu arbeiten. Sofern ein Remotezugriff per Router, ISDN oder Modem auf Netzwerke eingesetzt wird, ist neben anderen Sicherheitsmaßnahmen (z.B. Call-Back) ein Authentifizierungsmechanismus zu wählen, der ausschließlich verschlüsselte Passwörter übermittelt. |
|
Einseitige Authentisierung Soll ein gesicherter Datenaustausch in einer heterogenen, offenen Netzlandschaft zwischen Kommunikationspartnern stattfinden, bietet sich eine verschlüsselte WWW-Client-Server-Verbindung an. Dabei findet eine einseitige Authentisierung des Behörden-Servers gegenüber dem Client des Kommunikationspartners statt, damit sich dieser davon überzeugen kann, dass er z.B. tatsächlich mit dem Behörden-Server verbunden ist. Dadurch sollen die Vertraulichkeit und die Authentizität des Datenursprungs (Server) gewahrt werden. Kommunikationspartner sind z.B. Behörde und Bürger, Wirtschaft bzw. Behörde. Die Anzahl der Teilnehmer ist so groß, dass nicht mehr von einer geschlossenen Benutzergruppe ausgegangen werden kann. Als Rechnerplattform wird ein PC mit dem Betriebssystem Windows oder Linux benötigt. Als Browser wird der Internet-Explorer oder ein Netscape-Browser (wegen TSL/SSL - Funktionalität) benötigt. Als Webserver werden Apache, IIS und Lotus Notes Domino betrachtet. |
|
Eine SSL/TLS Sitzung wird stets durch den Client eingeleitet, der mit dem "Client Hello" dem Server den Wunsch zur Aufnahme einer SSL/TLS- Kommunikation signalisiert. Das dadurch eingeleitete, zunächst erfolgende Handshake Protokoll dient zur Synkronisation der kryptographischen Zustände auf beiden Seiten, insbesondere finden beim Handshake die Authentisierung der Kommunikationsparteien, sowie die Einigung auf das Verfahren und das Aushandeln eines Schlüssels für die nachfolgende (symmetrische) Verschlüsselung der Anwendungsdaten statt. Dabei zeigt der Client dem Server die Kollektionen von kryptographischen Algorithmen ("Cipher Suites") an, die er unterstützt, und der Server wählt die Cipher Suite aus, die im weiteren verwendet wird. Standardmäßig wählt dabei der Server die stärkste von den beiden Parteien unterstützten Cipher Suites aus. Der Server authentisiert sich dabei indirekt gegenüber dem Client durch Übersenden seines Zertifikats, das der Client mit dem öffentlichen Schlüssel der ausstellenden CA prüft. |
|
Beidseitige Authentisierung Im Gegensatz zu dem vorangegangenen Beispiel findet hier eine beidseitige Authentisierung z.B. des Behörden-Servers gegenüber dem Client des Kommunikationspartners sowie des Clients des Kommunikationspartners gegenüber dem Behörden-Server statt. Damit kann sich der Kommunikationspartner davon überzeugen, dass er z.B. tatsächlich mit dem Behörden-Server verbunden ist und die Behörde kann sich davon überzeugen, dass sie tatsächlich mit dem Client des gewünschten Kommunikationspartners verbunden ist. Dadurch sollen die Vertraulichkeit und die Authentizität des Datenursprungs (Server bzw. Client) gewahrt werden. Kommunikationspartner sind z.B. Behörde und Bürger, Wirtschaft bzw. Behörde. Die Anzahl der Teilnehmer ist so groß, dass nicht mehr von einer geschlossenen Benutzergruppe ausgegangen werden kann. Als Rechnerplattform wird ein PC mit dem Betriebssystem Windows oder Linux benötigt. Als Browser wird der Internet-Explorer oder ein Netscape-Browser (wegen TSL/SSL - Funktionalität) benötigt. Als Webserver werden Apache, IIS und Lotus Notes Domino betrachtet. |
|
Eine SSL/TLS Sitzung wird stets durch den Client eingeleitet, der mit dem "Client Hello" dem Server den Wunsch zur Aufnahme einer SSL/TLS- Kommunikation signalisiert. Das dadurch eingeleitete zunächst erfolgende Handshake Protokoll dient zur Synchronisation der kryptographischen Zustände auf beiden Seiten, insbesondere finden beim Handshake die Authentisierung der Kommunikationsparteien sowie die Einigung auf das Verfahren und das Aushandeln eines Schlüssels für die nachfolgende (symmetrische) Verschlüsselung der Anwendungsdaten statt. Dabei zeigt der Client dem Server die Kollektionen von kryptographischen Algorithmen ("Cipher Suites") an, die er unterstützt, und der Server wählt die Cipher Suite aus, die im Weiteren verwendet wird. Standardmäßig wählt dabei der Server die stärkste von den beiden Parteien unterstützten Cipher Suites aus. Der Server authentisiert sich dabei indirekt gegenüber dem Client durch Übersenden seines Zertifikats, das der Client mit dem öffentlichen Schlüssel der ausstellenden CA prüft. Die optionale Authentisierung der Clients erfolgt mit vertauschten Rollen auf die gleiche Weise, wobei zusätzlich (optional) der Client dem Server durch eine elektronische Unterschrift nachweist, dass er im Besitz des zu seinem Zertifikat gehörigen privaten Schlüssels ist. Im anschließenden record layer werden dann die Anwendungsdaten zwischen beiden Parteien verschlüsselt und (symmetrisch) authentisiert übertragen. Dabei wird der Datenstrom in Segmente ("records") unterteilt, die durchnumeriert und einzeln verschlüsselt und authentisiert werden. (Quelle:Krypto-Leitfaden des KoopA ADV) |
| SmartCard basierte Authentisierung |
| Für alle Umgebungen kann die Anmeldung auch mit auf Smartcards gespeicherten X.509-Zertifikaten erfolgen. Die gegenseitige Authentisierung zwischen Client und Server sichert die Integrität und erlaubt eine volle Einbindung des Prozesses in eine Public Key Infrastruktur (PKI). |