Sichere Protokolle

S-HTTP

SSL

Mit SSL (das Kürzel steht für Secure Sockets Layer) kommt früher oder später jeder Surfer in Berührung auch wenn er es unter Umständen gar nicht bemerkt. Eine gesicherte Verbindung über dieses Protokoll erkennt man im Browser daran, daß die dargestellte URL mit dem Kürzel "https://" beginnt; zusätzlich erscheint in der Statusleiste des Browsers ein eingerastetes Vorhängeschloß. SSL entstand ursprünglich 1994 als proprietäre Lösung von Netscape für ein verbindungsorientiertes Sicherungsprotokoll auf der Datenschicht. Schon ein Jahr später wurde es bei der IETF (Internet Engineering Task Force) zur Normung eingereicht, heute dient es in der Version 3.0 als Arbeitsbasis der "Transport Layer Security (TLS) Working Group" der IETF. Der ursprüngliche Zweck von SSL bestand lediglich in der Sicherung der Kommunikation zwischen Web-Server und Browser; inzwischen läßt es sich in diversen Varianten allerdings auch zusammen mit NNTP, POP3, SMTP oder Telnet einsetzen.

Im ISO/OSI-Schichtenmodell der Datenkommunikation residiert SSL zwischen der Transportschicht (TCP oder UDP) und der Anwendung. Dabei stellt der SSL-Layer für die Applikation statt der normalen Socket-Funktionen wie read oder write spezielle Methoden zur Eröffnung und Nutzung einer sicheren Uansportverbindung zur Verfügung. Die Anwendung reicht die Daten, anstatt sie direkt an die Transportschicht zu übergeben, also zunächst an SSL weiter. Dieses schützt Verbindung und Daten durch die Bearbeitung mit kryptographischen Verfahren und übermittelt erst anschließend die Daten an die Transportschicht.

Insgesamt kombiniert SSL fünf verschiedene Protokolle:

• Das SSL Application Data Protocol wickelt die Datenübermittlung zwischen Anwendung und SSL ab.
• Das SSL Alert Protocol dient der Weiterleitung von Warn- und Fehlermeldungen.
• Das SSL Change Cipher Spec Protocol übernimmt die Initialisierung der festgelegten kryptographischen Verfahren.
• Über das SSL Handshake Protocol handeln Server und Client das zu verwendende kryptographische Verfahren aus.
• Das SSL Record Protocol nimmt die Ver- bzw. Entschlüsselung sowie, falls verlangt, eine Komprimierung der Nutzdaten vor.

Portnummer	Art	Protokoll
443	HTTP über SSL	HTTPS
465	SMTP über SSL	SSMTP
563	NNTP über SSL	SNNPS
992	Telnet über SSL	LNETS
995	POP3 über SSL	SPOP3

Um über SSL eine gesicherte Verbindung aufzubauen, müssen die Kommunikationspartner sich zunächst einmal über die zu verwendenden kryptographischen Verfahren und Parameter einig werden. Grundsätzlich bietet SSL dabei Schlüssel-Austauschverfahren, eine symmetrische Verschlüsselung sowie die Berechnung einer kryptographischen Prüfsumme als Möglichkeit an. Für jede dieser Möglichkeiten lassen sich verschiedene Verfahren nutzen. etwa RSA oder Diffie-Hellmann für den Schlüsselaustausch, DES oder IDEA für die Verschlüsselung sowie MD5 und SHA für die Prüfsumme. Als kleiner Haken erweist sich dabei, daß die meisten SSL-relevanten Produkte aus den USA stammen und daß aufgrund der dort geltenden Exportbeschränkungen nur bestimmte Schlüssel-Längen genutzt werden können.

Vor der Übertragung der eigentlichen Daten arbeiten Client und Server ein Handshake-Protokoll ab, in dem der Sitzungsschlüssel ausgetauscht und die Authentifikation vorgenommen wird. Der Client eröffnet den Handshake mit einem Einmalwert (challange), der Liste der unterstützten Verschlüsselungsverfahren und sofern vorhanden - einer Session-ID aus einer früheren Sitzung. Der Server antwortet mit einer neuen Connection-ID. Wenn er im Cache die angegebene Session-ID findet, können beide Seiten einen früher vereinbarten Hauptschlüssel (master key) benutzen. Anderenfalls sendet der Server sein Zertifikat und eine Liste der verwendbaren Chiffren. Der Client generiert einen neuen Master-Key und sendet ihn mit dem Public-Key des Servers verschlüsselt an diesen. Aus dem Hauptschlüssel und verbindungsbezogenen Daten werden mittels einer Hash-Funktion (MD5) die Sitzungsschlüssel abgeleitet, die für die Datenverschlüsselung Anwendung finden. Für jede Richtung (Senden/Empfangen) wird dabei ein eigener Sitzungsschlüssel benutzt - der Hauptschlüssel selbst kommt bei der Datenverschlüsselung nie zum Einsatz. Abschließend schickt der Client die mit seinem Sendeschlüssel chiffrierte Connection-ID und der Server den mit seinem Sendeschlüssel verschlüsselten Einmalwert. Der Client überprüft unter Verwendung seines Empfangsschlüssels, ob der Einmalwert mit dem von ihm gesendeten übereinstimmt und kann damit sicher gehen, daß der Server als der tatsächliche Inhaber des Zertifikats authentisch ist. Denn anderenfalls konnte der Server den Hauptschlüssel nicht korrekt entschlüsseln und folglich keine Sitzungsschlüssel generieren.
Der Server hat ebenfalls die Möglichkeit, die Authentizität des Clients zu überprüfen. Die Aufforderung dazu enthält einen Einmalwert und eine Liste anwendbarer Verfahren zur Authentifikation. Der Client antwortet mit seinem Zertifikat und Authentifikationsinformationen. Für diese wird mit MD5 ein digest Über Sende- und Empfangsschlüssel, den Einmalwert und das Zertifikat des Servers erzeugt und mit dem privaten Schlüssel des Clients (entsprechend dem Zertifikat) verschlüsselt. Zum Abschluß schickt der Server dem Client verschüsselt die neue Session-ID.

Nach erfolgreicher Beendigung des Handshake-Protokolls sind beide Seiten zur Übertragung der Anwendungsdaten bereit. Diese werden im Rahmen eines Record-Protokolls nach dem vereinbarten Verfahren verschlüsselt und mit einem Message Authentication Code zur Gewährleistung der Datenintegrität versehen. Das SSL-Protokoll bietet einen sehr einfachen und effizienten Mechanismus zur Befriedigung der Sicherheitsbelange vieler Anwendungsprotokolle.

Neben der Verschlüsselung bietet SSL optional noch eine zweite Methode an, die Verbindung zu sichern: Die Authentisierung eines oder beider beteiligter Kommunikationspartner. Diese Variante stützt sich auf den Einsatz externer Certification Authorities (wie etwa Verisign), über die sich digitale Zertifikate ausstellen lassen. Die digitalen Unterschriften der wichtigsten Zertifizierungs-Instanzen bringen Internet Explorer und Navigator dabei schon mit, so daß zur Kommunikation mit diesen nicht noch extra Zertifikate angefordert werden müssen. Die verschiedenen SSL-Protokollversionen bieten bei der Authentifizierung unterschiedliche Möglichkeiten.

SSL-2 erfordertlediglich eine Zertifizierung des Servers, so daß der Kommunikationspartner vom Client aus einwandfrei identifizierbar ist. Dadurch lassen sich gängige Täuschungsmanöver wie IP-Spoofing (also das Vorgaukeln einer fremden IP-Adresse zum Abfangen der an diese gerichteten Daten) unterbinden. Beim Verbindungsaufbau erhält der Client vom Server das digitale Zertifikat der Site. Daraufhin generiert der Client einen Session Key, mit dem er die gesamte Kommunikation mit der Site verschlüsselt. Den Key selber verschlüsselt er mit dem Public Key des authentifizierten Servers, so daß nur dieser die Verbindungsdaten lesen kann.

SSL-3 setzt die Zertifizierung der Kommunikationspartner voraus. Dazu muß der Anwender bei einem Trust Center ein Client-Zertifikat anfordern, das meist kostenpflichtig ist (ca. 15 Dollar). In der Kombination von Server- und Client-Authentifizierung bietet SSL dann komplett abgesicherte Verbindungen via Internet.

Neben den "Standard"-Varianten von SSL existieren auch spezialisierte Varianten dieses Verfahrens. Die bekannteste davon ist Fortezza, welche von den US-Behörden zum Austausch sensitiver Daten benutzt wird. Sie setzt zur schnelleren Verschlüsselung auf Hardware und verwendet als Schlüssel-Austauschmechanismus KEA anstatt RSA. Über kurz oder lang wird SSL als Standard vermutlich von dem auf ihm basierenden TLS 1.0 - das bereits als IETF-Draft vorliegt ganz abgelöst werden.

Typische Beispiele für Certification Authorities bieten Verisign (https://www.verisign.com) und Globalsign (https://www.globalsign.com).

Dort erhalten Sie sowohl Server- als auch Client-Zertifikate. Von letzteren offerieren beide Anbieter auch kostenlose, jedoch zeitbeschränkte Versionen. Eine umfassende Darstellung des neuen IETF-Standards TLS 1.0 direkt aus erster Hand bietet der RFC 2246.

S/Key

P₀ = f^N(s)

Das nächste OTP erhält man durch (N -1)-maliges Anwenden des Hash:

P₁ = f^N-1(s)

Die generelle Erzeugunsvorschrift lautet damit:

P_i = f^N-i(s)

bzw.

P_i = f(P_i+1)

Erlangt ein Unberufener Kenntnis von einem OTP P_i, kann er trotzdem nicht das nächste zu verwendende Paßwort P_i+1 ermitteln, da sich die Umkehrung f'(p_i) der sicheren Hash-Funktion nicht berechnen läßt. Der entfernte Host erhält zunächst das OTP P₀. Wenn sich ein Benutzer anmelden will, schickt der Host ihm die Sequenznummer i des letzten gespeicherten Paßworts. Der Benutzer antwortet daraufhin mit dem nächsten Paßwort p_i+1. Der Host führt folgende Berechnung durch:

P_i = f(f^N-i-1l(s)) = f(P_i+1)

Stimmt der berechnete Wert nut dem gespeicherten überein, so ist der Nutzer authentifiziert. Daraufhin überschreibt der Host das alte OTP p_i mit dem soeben erhaltenen P_i+1. Somit muß der Host das geheime Paßwort gar nicht kennen.Da mit jedem Gebrauch und somit zunehmenden i die Anzahl der Iterationen der Hash-Funktion abnimmt, muß zu einem bestimmten Zeitpunkt eine Reinitialisierung (Neuberechnung der OTPs) vorgenommen werden.
S/Key erweitert diesen Grundalgorithmus dahingehend, daß das Paßwort eine Verkettung aus dem eigentlichen Paßwort s und einem Initialwert (seed) darstellt. Der Initialwert wird vom entfernten Host gemeinsam mit der Sequenznummer gesendet. Damit läßt sich ein geheimes Paßwort, das der Nutzer sich merkt, für verschiedene Hosts und auch für die Reinitialisierung verwenden.
Zum Berechnen der OTPs stehen Clientprogramme für Unix-, Macintosh-, DOS- und Windows-Systerne zur Verfügung. Der Nutzer braucht nur die Sequenznummer, den Initialwert und sein geheimes Paßwort einzugeben. Alternativ kann er sich auch eine Liste von OTPs im voraus berechnen lassen, um sie beispielsweise auf Reisen mit sich zu führen. Auf der Hostseite werden das 'login'- und das 'su'-Programm sowie der ftp-Server modifiziert. Diese Änderungen laufen unter allen gebräuchlichen Unix-Systemen.

Secure Shell (ssh und scp)

OpenSSH verwendet beispielsweise die symmetrischen Verschlüsselungsalgorithmen Triple-DES, Blowfish und IDEA. Sie sind alle drei patentfrei. Man kann davon ausgehen, daß diese Verfahren sicher sind, da sie offen gelegt und keine gravierenden Sicherheitslücken bekannt sind. Das symmetrische Verfahren beruht darauf, daß der gesamte Datenverkehr mit nur einem geheimen Schlüssel verschlüsselt ist und dieser sowohl beim Sender als auch Empfänger zum Ver- bzw. Entschlüsseln benutzt wird. Da dieser geheime Schlüssel den beiden an der Sitzung teilnehmenden Personen zur Kommunikation bekannt sein muß, muß ein Schlüsselaustausch stattfinden. Dazu verwendet SSH den RSA-Algorithmus. Prinzipiell läuft ein Login folgendermaßen ab (Es wird vorausgesetzt, daß auf dem Zielrechner der ssh-Server und auf der Client-Workstation, von der aus man eine Verbindung zum Zielrechner herstellen will, der ssh-Client installiert ist):

• Nachdem der Client eine erfolgreiche TCP/IP-Verbindung zum Server aufgebaut hat, tauschen beide Seiten ihre installierte Protokollversion aus. Falls die Versionen inkompatibel sind, wird die Kommunikation sofort abgebrochen.
• Andernfalls schalten Server und Client auf ein paketbasiertes Binär-Protokoll um.

  

• Anschließend sendet der Server seine beiden öffentlichen RSA-Schlüssel e_H und e_S (Host- und Server-Key) sowie eine Auflistung der von ihm unterstützten symmetrischen Chiffren zum Klienten. Der Client verifiziert e_H mit Hilfe einer lokalen Datenbasis (bzw. "lernt" diesen Key, falls der Nutzer es zuläßt).
• Wurde e_H akzeptiert, generiert der Client einen zufälligen Sitzungsschlüssel, chiffriert diesen mittels der beiden RSA-Keys e_H und e_S. Dann sendet er das Resultat zusammen mit der Angabe des von ihn gewählten symmetrischen Verfahren an den Server.
• Ab diesem Zeitpunkt läuft die gesamte Kommunikation verschlüsselt ab. Der Client authentifiziert sich mit einem der unterstützen Verfahren (Username und Paßwort sind also schon verschlüsselt). Die Hostschlüssel dienen der Identifikation des Rechners und sind "langlebig", Serverschlüssel werden in regelmäßigen Abständen neu generiert (z. B. einmal pro Stunde).
• Nach erfolgreicher Authentifizierung wird für den Nutzer eine Arbeitsumgebung auf dem Server-Rechner hergestellt. Zusätzlich verschlüsselt ssh X11-Verbindungen, setzt dabei automatisch die Display-Variable und gestattet, beliebige TCP/IP-Verbindungen zu tunneln.

Eigenschaften von SSH im Überblick

• Gedacht als Ersatz für die Unix-R-Kommandos (rlogin, rsh, rcp), telnet
• Verschlüsselung der Verbindung
• Auch einsetzbar zur Sicherung von X-Window, telnet, ftp und POP durch Umleitung der Verbindung über einen gesicherten Kanal
• Automatische Umsetzung der Display-Variablen unter X
• Starke Host-Authentifizierung
• Unterstützte Plattformen:
  • nahezu alle Unix-Systeme
  • Windows 3.x, 95/98, NT
  • Macintosh

Mit der SSH besteht Schutz vor

• Abören von Passwörtern und Terminalverbindungen durch Sniffer
• DNS-Spoofing
• IP-Spoofing

In der Grundversion unterstützt die Secure Shell vier Verfahren zur Authentifizierung des Clients, wobei die Nutzung der einzelnen Verfahren durch Kommandozeilen-Argumente bzw. Einträge in den entsprechenden Konfigurationsdateien gezielt vom Server zugelassen bzw. unterdrückt werden können:

1. Host-Based-Authentifizierung
   Bei diesem Verfahren basiert die Authentifizierung auf dem Hostnamen des Client. Sie entspricht der Authentifizierung bei rlogin und rsh unter UNIX. Hierbei werden die bekannten Hosts beim Server durch einen Eintrag in der Datei etc/hosts.equiv oder /etc/shosts.equiv bzw. $HOME/.rhosts oder $HOME/.shosts. verwaltet. Dieses Verfahren ist nicht gegen Spoofing-Attacken gefeit.
2. Host-Based-RSA-Authentifizierung
   Dieses Verfahren stellt eine Kombination aus der "Host-Base-Authentifizierung" mit einer RSA-basierten Authentifizierung des Clients dar. Dabei werden die public Keys der Clients in den Dateien $HOME/.ssh/known_hosts und /etc/ssh_known_hosts des Servers abgelegt. Bei der Authentifizierung muß der Client in einem "Challenge-Response-Dialog" nachweisen, daß er den zugehörigen privaten Schlüssel kennt.
3. Paßwort-Authentifizierung
   Hierbei erfolgt die Authentifizierung durch die Angabe eines Benutzerpassworts. Dabei wird die Verschlüsselung bei Übertragung des Passworts durch den Sitzungsschlüssel gewährleistet. Das Sicherheitsrisiko hängt dabei von der Stärke des Passwortes ab.
4. Reine RSA Authentifizierung
   Diese Methode gilt als flexibel und potentiell sicherste Methode zur Client Authentifizierung. Hierbei muss der Client über einen "Challenge-Response-Dialog" nachweisen, das er den zum public-key gehörigen private-key kennt. Dieses Challenge-Response-Verfahren läßt sich dabei automatisch durch den SSH-Agenten abwickeln. Die zur Authentifizierung notwendigen öffentlichen Schlüssel stehen dabei im Serververzeichnis $HOME/.ssh/authorized_keys. Das notwendige Schlüsselpaar des Nutzers wird beim Client in deiner Datei namens $HOME/.ssh/identity gespeichert.

• ssh als Ersatz von telnet und rlogin:
  ssh [Userid@] Remote-Host
  Die Userid muß nur dann angegeben werden, wenn die Userids auf der Client-Workstation und dem Zielrechner unterschiedlich sind.
• ssh als Ersatz von rexec und rsh:
  ssh [Userid@] Remote-Host Befehl
  Wenn der Befehl Wildcards (?, * usw.) enthält, muß er in Hochkommata eingeschlossen werden, damit diese auch wirklich erst auf dem Zielrechner aufgelöst werden,
• scp als Ersatz von rcp und ftp:
  • Um eine Datei von der lokalen Workstation zu einem entfernten Zielrechner zu übertragen:
    scp Datei [Userid@] Remote-Host: [Datei | Directory]
  • Um eine Datei von einem entfernten Rechner auf die lokale Workstation zu kopieren:
    scp [Userid@] Remote-Host: Datei Datei | Directory
  Es ist möglich, durch die Angabe von Wildccards (z. B. *.txt) mit einem Befehl mehrere Dateien zu kopieren. In diesem Fall muß für das Zielsystem ein bereits existierendes Verzeichnis angegeben werden, in das die Dateien kopiert werden sollen. Die Angabe einer Zieldatei ist dann nicht möglich.
  Um ganze Verzeichnisse rekursiv zu kopieren, kann man die Option -r verwenden:
  scp -r Directory [Userid@] Remote-Host: [Directory]
  bzw. scp -r [Userid@] Remote-Host: Directory Directory
  

Gibt man die Userid nicht explizit an, wird diejenige genommen, unter der das scp-Kommando auf der lokalen Workstation abgesetzt wird. Alternativ kann in einer lokalen ssh-Konfigurationsdatei $HOME/.ssh/config für jeden Zielrechner eine Userid definiert werden, die defaultmäßig genommen wird.

Zugangsvalidierung

• Zugang mit Paßwort-Authentisierung
  Nach Absetzen eines der oben beschriebenen Befehle wird man nach dem Paßwort auf dem Zielrechner gefragt. Dieses wird verschlüsselt übertragen.
• Zugang mit RSA-Authentisierung
  ssh bietet zusätzlich die sogenannte RSA-Authentisierung. Diese Form der Validierung ist noch sicherer: Statt eines einzelnen Paßwortes kann ein ganzer Satz (Passphrase) als Zugangsvalidierung gewählt werden. Der private RSA-Schlüssel (Generierung s.u.) wird mit dieser Passphrase verschlüsselt, um ihn vor Mißbrauch zu schützen. D.h. selbst wenn der RSA-Schlüssel in unerlaubte Hände gerät, kann er nur dann genutzt werden, wenn auch die Passphrase bekannt ist. Wegen der erhöhten Sicherheit, wird empfohlen, möglichst diese Art der Validierung zu nutzen.

Andere Dienste über SSH tunneln

ssh ohne Passwort

Wo ist denn da der Vorteil, wenn man sich zwar ohne Passwort einloggen kann, aber für den Private Key doch wieder eine Passphrase braucht? Nun, zum einen kann man sich später mit diesem einen Schlüssel auf viele verschiedene Rechner einloggen und muß sich nicht deren evtl. verschiedene Paßwörter merken. Zum anderen gibt es den SSH Agent, der in der Lage ist, sich die Passphrase für die Dauer ein Sitzung zu merken, so daß man sie nur einmal eingeben muß und bei allen weiteren Logins und Datei-Transfers nicht mehr gefragt wird.

Es besteht auch die Möglichkeit, eine leere Passphrase zu verwenden - dann aber ist der Private Key ungeschützt! Jetzt muß man auf anderem Wege sicherstellen, daß niemand an den Schlüssel herankommt, d.h. z.B. die Datei-Zugriffsrechte dürfen nur dem Eigentümer den Zugriff erlauben.

Zu einer passwortlosen Authentifizierung muß zuerst ein Schlüsselpaar generiert werden und zwar auf dem Rechner von dem aus man ssh ohne Passwort verwenden möchte. Wenn man nicht weiß welchen Typ Schlüssel man braucht, generiert man einfach alle. Dabei wird man jedesmal nach einem Passwort gefragt. Das ist nicht das Login-Passwort, sondern ein beliebiges neues Passwort, das nur dazu dient, seinen Privaten Schlüssel zu erzeugen.

                                       plate@atlas:~ > cd .ssh
                                       
                                       plate@atlas:~/.ssh > ssh-keygen ; ssh-keygen -t rsa ; ssh-keygen -t dsa
                                       Generating public/private rsa1 key pair.
                                       Enter file in which to save the key (/home/plate/.ssh/identity):
                                       Enter passphrase (empty for no passphrase):
                                       Enter same passphrase again:
                                       Your identification has been saved in /home/plate/.ssh/identity.
                                       Your public key has been saved in /home/plate/.ssh/identity.pub.
                                       The key fingerprint is:
                                       ff:49:ac:41:86:40:a9:be:ea:13:59:48:ba:6b:0f:36 plate@atlas
                                       Generating public/private rsa key pair.
                                       Enter file in which to save the key (/home/plate/.ssh/id_rsa):
                                       Enter passphrase (empty for no passphrase):
                                       Enter same passphrase again:
                                       Your identification has been saved in /home/plate/.ssh/id_rsa.
                                       Your public key has been saved in /home/plate/.ssh/id_rsa.pub.
                                       The key fingerprint is:
                                       6e:8f:94:d2:bb:d6:68:37:fb:98:7c:1c:01:8c:de:0b plate@atlas
                                       Generating public/private dsa key pair.
                                       Enter file in which to save the key (/home/plate/.ssh/id_dsa):
                                       Enter passphrase (empty for no passphrase):
                                       Enter same passphrase again:
                                       Your identification has been saved in /home/plate/.ssh/id_dsa.
                                       Your public key has been saved in /home/plate/.ssh/id_dsa.pub.
                                       The key fingerprint is:
                                       c1:32:0a:68:57:e9:d4:77:b5:01:6a:05:ae:8c:b6:24 plate@atlas
                                       
                                       plate@atlas:~/.ssh > ls
                                       id_dsa        id_rsa        identity      known_hosts
                                       id_dsa.pub    id_rsa.pub    identity.pub  random_seed
                                       

Als nächstes muß der generierte Public Key (Dateiendung ".pub") in die Datei /$HOME/.ssh/authorized_keys bzw. .authorized_keys2 auf der Gegenseite (der Rechner, auf dem man sich ohne Passwort einloggen möchte) eingetragen werden. Der Public Key und auch die authorized_keys*-Datei sind Textdateien. Die Zeile aus der id_*-Datei muß an die authorized_*-Datei angehängt werden, z.B. via Cut&Paste oder durch Kopieren der Datei (mit Passwort-Login) und Anhängen. Anschließend werden diese Authentifizierungsdaten verwenden:

                                       plate@atlas:~/.ssh > scp identity.pub tralala:/home/plate/.ssh/
                                       plate@tralala's password: 
                                       identity.pub 100% |*****************************|   526  00:00    
                                       plate@atlas:~/.ssh ssh tralala
                                       plate@tralala's password: passwort
                                       Last login: Sat Jan  4 10:23:12 2003 from atlas
                                       ...
                                       

RSA1 (alt, SSH Protokoll 1)

Erzeugen: ssh-keygen
Dateien: $HOME/.ssh/identity, $HOME/.ssh/identity.pub

DSA (SSH Protokoll 2)

Erzeugen: ssh-keygen -t dsa
Dateien: $HOME/.ssh/id_dsa, $HOME/.ssh/id_dsa.pub

RSA (SSH Protokoll 2)

Erzeugen: ssh-keygen -t rsa
Dateien: $HOME/.ssh/id_rsa, $HOME/.ssh/id_rsa.pub

Auf jeden Fall sind noch die Zugriffsrechte zu setzen:

                                       chmod 600 ~/.ssh/authorized_*
                                       

Anschließend kann nochmals ein neuer Versuch gemacht werden, sich ohne Passwort anzumelden:

                                       plate@atlas:~/.ssh ssh tralala
                                       Last login: Sat Jan  4 11:18:38 2003 from atlas
                                       ...
                                       

Bei OpenSSH braucht man den Public Key einfach nur in der Datei ~/.ssh2/authorization eintragen mit der Zeile:

                                       Key MEIN-SSH-PUBLICKEY.pub
                                       

                                       IdKey MEIN-SSH-PUBLICKEY
                                       

                                       ssh-dss
                                       AAAAB3NzaC1kc3MAAACBAIygQj1gQp+XTk9oaZdkI8FJoABaWjwJjTVxiXUdau7pIddAht3rmcAgrQEN
                                       z6Cy4he7Dbdu
                                       ...
                                       rpnVxyEKaHSYRmGDbB78810kugDeF5+lZs881MN7UnA3crygPs2PEXmpJIK+GfiztqJvf0UjzhaPofLI
                                       sQ1O9Q== USER@HOST
                                       

                                       ---- BEGIN SSH2 PUBLIC KEY ----
                                       Subject: root
                                       Comment: "1024-bit dsa, root@atlas, Wed Jan 23 2002 12:04:22"
                                       AAAAB3NzaC1kc3MAAACBAIygQj1gQp+XTk9oaZdkI8FJoABaWjwJjTVxiXUdau7pIddAht
                                       ...
                                       f0UjzhaPofLIsQ1O9Q==
                                       ---- END SSH2 PUBLIC KEY ----
                                       

Fragen und Antworten:

Wieso fragt ssh nach dem Paßwort auf dem Zielrechner statt nach der RSA-Passphrase?
Es gibt drei Gründe:

• Der öffentliche Schlüssel wurde nicht auf dem Zielrechner abgelegt.
• Das Heimatverzeichnis des Benutzers auf dem Zielrechner hat zu viele Rechte. In der Standardkonfiguration erwartet ssh, daß Schreibrechte nur für den Owner gesetzt sind. Sobald sie auch für andere gesetzt sind, schaltet ssh auf Validierung über Paßwort zurück.
• Die Verwaltung der Benutzerdaten auf dem Zielrechner läuft über DCE. In diesem Fall hat man keine Möglichkeit, die RSA-Authentisierung zu nutzen.

Man erhält die Warnung "Host key not found from the list of known hosts."
Man sollte sicherstellen, daß die Datei /etc/ssh_known_hosts existiert und auf dem aktuellen Stand ist. Beim ssh-Zugang zu einem anderen Rechner muß man beim ersten Login über ssh darauf vertrauen, daß der HostKey, den der Zielrechner anbietet, korrekt ist. In jedem Fall kann der Login-Prozeß mit yes fortgesetzt werden. Der HostKey wird dann automatisch in die Datei $HOME/.ssh/known_hosts eingetragen, und die Meldung sollte beim nächsten Login über ssh nicht mehr erscheinen. Außerdem sollte man darauf achten, daß man den Zielrechner immer in derselben Form anspricht, da der Name zusammen mit dem HostKey in $HOME/.ssh/known_hosts eingetragen wird und der HostKey anschließend nur für diesen Namen bekannt ist.

Man erhält die Warnung "HOST IDENTIFICATION HAS CHANGED! ..."
Man sollte die Verbindung durch die Eingabe von no zunächst einmal abbrechen. Erkundigen Sie sich bitte beim jeweiligen Administrator, ob der HostKey wirklich geändert wurde. Ist dies der Fall, sollten Sie den bestehenden Eintrag für die Maschine aus der Datei $HOME/.ssh/known_hosts löschen, damit der aktuelle HostKey beim nächsten Login an die Datei angefügt werden kann.

IP Security (IPSec)

• den Einsatz verschiedener Verschlüsselungsalgorithmen
• verschiedene Sicherheitsdienste (Zugangskontrolle, Beglaubigung, Integrität, Vertraulichkeit)
• Kontrolle, wie detailliert die Sicherheitsdienste angewandt werden.

IPSEC ermöglicht den Aufbau von verschlüsselten Kanälen zwischen Routern oder von Clients zu Routern und ist damit eine Schlüsseltechnologie für den Aufbau von VPNs (Virtual Private Networks). IPSEC besteht im wesentlichen aus zwei Teilen:

1. Protokolle zur Implemenation der Sicherheitsdienste: AH (Authentication Header) und ESP (Encapsulating Security Payload)
2. Schlüsselmanagement: ISAKMP Protokoll (Internet Security Association and Key Management Protocol)

Beim Verschlüsseln kann zwischen zwei Modi unterschieden werden:

• Im Transport-Mode wird der Inhalt des Paketes (also das UDP- oder TCP-Paket) in den kryptografischen Rucksack gepackt und mit dem identischen IP-Header auf die Reise geschickt.
• Im Tunnel-Mode wird das ganze Paket mit originalem IP-Header verschlüsselt und mit einem Klartext-IP-Header versehen. Der Tunnel-Mode erhöht zwar den Overhead, sorgt aber dafür, daß IP-Adressen nicht gefälscht werden können, da diese auch verschlüsselt übertragen und so am Zielsystem geprüft werden können.

IPSEC läßt beliebige Schlüsselmanagement-Verfahren zu und erlaubt auch, starke Algorithmen und SmartCards zu verwenden. Das SKIP-Verfahren (Simple Key Management for Internet Protocol) beispielsweise ist auf DES (für ESP) und MD5 (für AH) definiert und beruht auf dem Diffie-Hellman-Keymanagement.

SET

1. Zahlungs- und Orderinformationen sollen vertraulich behandelt werden.
2. Die Integrität der im Rahmen des Zahlungsvorgangs übermittelten Daten soll gewährleistet sein.
3. Der Kartenbenutzer muß sich als Karteninhaber authentisieren.
4. Der Händler muß sich gegenüber dem Karteninhaber authentisieren.
5. Es sollen die besten kryptografischen Verfahren verwendet werden.
6. Das Protokoll soll nicht von sicheren Transportmechanismen auf unteren Schichten abhängen, dessen Benutzung aber nicht verbieten.
7. Das Protokoll soll auf verschiedenen Hard- und Software-Plattformen lauffähig sein (Interoperabilität).

1. Der Karteninhaber wählt Waren und Dienstleistungen per Internet aus.
2. Der Karteninhaber trägt seine Auswahl in ein elektronisches Bestellformular ein.
3. Der Karteninhaber wählt die Art der Bezahlung aus (derzeit nur die Bezahlung per Kreditkarte).
4. Der Karteninhaber versendet die Daten (Bestellung/Zahlungsinstruktionen) an den Händler (Kartenmarke, Kartennummer usw.).
5. Der Händler läßt sich die Zahlung durch die Finanzinstitution des Karteninhabers bestätigen (Zahlungs-Authorisierungsanfrage).
6. Der Händler sendet nach einer positiven Antwort eine Auftragsbestätigung an den Kunden.
7. Der Händler liefert die Ware aus.
8. Der Händler fordert von der Finanzinstitution des Karteninhabers die Bezahlung.

1. Der Kunde errechnet je einen Hashwert für die Bestellung und die Kreditkarteninformationen. Beide Hashwerte werden miteinander verbunden und darüber ein weiterer Hashwert errechnet.
2. Dieser Hashwert wird vom Kunden mit seinem privaten Schlüssel signiert (duale Signatur).
3. Der Benutzer sendet die duale Signatur, den Hashwert der Kreditkarteninformationen und die verschlüsselten Bestellinformationen (HybridVerfahren) an den Händler.
4. Der Händler entschlüsselt die Bestellinformation, errechnet darüber einen Hashwert, verbindet diesen Wert mit dem Hashwert der Kreditkarteninformationen und errechnet über das Ergebnis einen Hash. Diesen Wert vergleicht er mit dem vom Kunden zugeschickten signierten Wert. Stimmen beide Werte überein, ist der Kunde authentisiert und die Integrität der Informationen sichergestellt.

HBCI

• Multibankfähigkeit: Jede Zahlungsverkehrsoftware mit HBCI-Kernel soll in der Lage sein, mit jedem Kreditinstitut bzw. HBCI-Server zu kommunizieren. Erreicht werden soll dies über ein einheitliches Protokoll, fest definierte Kommunikationsdialoge und -Ports.
• Transportdienstunabhängigkeit: Das HBCI-Protokoll kann und soll mit jedem Transportdienst zurechtkommen und somit dem Kunden eine freie Wahl des Zugangs (Providerwahl) ermöglichen.
• Endgeräteunabhängigkeit: Neben dem PC und Notebook sollen auch mobile Geräte wie Handy und PDA als mögliche HBCI-Kommunikationsplattformen berücksichtigt werden.
• Offenheit: Durch frei zugängliche Spezifikationen und Entwicklungstools (APIs) soll nicht nur Vertrauen geschaffen, sondern auch die einfache Entwicklung von HBCI-Anwendungen vorangetrieben werden.
• Sicherheit: Die Sicherheitsmechanismen zum Schutz der übertragenen Daten, sowie die Authentifizierung soll auf den derzeit anerkannten und als sicher geltenden Standards beruhen und gegebenenfalls erweiterbar sein.
• Flexibilität: Die HBCI-Spezifikation soll möglichst modular (objektorientiert) aufgebaut ein um eigene Geschäftsvorfälle hinzufügen und parametrisieren zu können und um die Eigenentwicklung von HBCI-Anwendungen zu vereinfachen.
• Präsentationsdienstunabhängigkeit: Der HBCI-Kernel soll nur Rohdatenströme zur Verfügung stellen und die Kunde-zu-Bank-Kommunikation abwickeln. Die Visualisierung und Interaktion mit dem Kunden soll alleine Aufgabe der Homebanking-Anwendung sein.
• Anwendungssystem-Unabhängigkeit: Es soll möglich sein, HBCI-Anwendungen sowohl über fest installierte Software, als auch über dynamisch geladene Software-Module (JavaApplets, ActiveX, etc.) zu realisieren.
• Plattformunabhängigkeit: Die HBCI-Spezifikation soll keine Einschränkungen bezüglich des verwendeten Betriebsystems machen und als Entwicklungsumgebung (HBCI-Kernel) möglichst auch für alle Plattformen verfügbar sein.
• Online & Offline-Arbeiten soll möglich sein, um Übertragungskapazitäten effektiver zu nutzen und um dem Kunden mehr Komfort zu bieten.

Die genannten Anforderungen wurden inzwischen alle in die HBCI-Spezifikation aufgenommen und führten zu einer breiten Akzeptanz des neuen Standards bei den deutschen und europäischen Kreditinstituten. Trotz der nach wie vor weiten Verbreitung von proprietären Homebanking-Systemen, vor allem in Form von "Java-Banking-Applets" im Internet, scheinen immer mehr Banken zumindest prinzipiell auf den neuen HBCI-Standard zu setzen. Homebanking auf Basis des HBCI-Standards gilt als sehr sicher, da eine Vielzahl von Sicherungsverfahren eingesetzt werden:

• Starke Verschlüsselung der übertragenen Daten auf Basis eines Triple-DES Algorithmus. Es handelt sich hierbei um ein symmetrisches Blockchiffre-Verfahren, dass einen geheimen 168-Bit-Schlüssel nutzt.
• Sichere Authentifizierung des Kunden und der Bank sowie der übertragenen Dokumente durch digitale Signaturen. Hierbei sind derzeit zwei Verfahren standardisiert:
  • RSA-Signaturen (asymmetrisches Verfahren)
  • MAC-Signaturen (symmetrisches Verfahren, basiert auf DES)
• Passwortschutz zur Authentifizierung auf Kundenseite
• Signaturzähler zur Erkennung und Vermeidung von Doppeleinreichungen

Zurück

Inhaltsverzeichnis

Nächste

Diplomarbeiten zum Runterladen: