Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03168.jsonl.gz/1679

Sichere Protokolle
S-HTTPDas Secure Hypertext Transfer Protocol nimmt nicht nur am TransferprotokollErweiterungen vor, sondern definiert auch neue Elemente für die HTML-Sprache.S-HTTP stellt einen Rahmen für die Anwendung verschiedener kryptografischer Standardmethoden dar. Jede Nachricht kann durch eine beliebige Kombination aus drei Mechanismen geschützt werden: digitale Unterschrift, Datenverschlüsselung und Authentifizierung. Eine S-HTTP-Nachricht besteht aus einer gekapseltenHTTP-Nachricht und einigen vorangestellten Kopfzeilen, die das Format der gekapselten Daten beschreiben.
Beide Seiten können im Rahmen einer Verhandlung Angaben über die verwendbaren beziehungsweise geforderten Erweiterungen gegenüber HTTP machen. Dazu gehören: Nachrichtenformate, Typen der Zertifikate, Schlüsselaustauschmechanismus, Verfahren für digitale Unterschriften, Hash-Algorithmus für den digest sowie Verschlüsselungsverfahren für Kopf und Inhalt. Das könnte folgendermaßen aussehen: 'Dieser Client verschlüsselt alle Nachrichten mittels DES und vermag mit DES oder RC5 verschlüsselte Nachrichten zu empfangen.'Sowohl asymmetrische (öffentliche Schlüssel mit entsprechenden Zertifikaten) als auch symmetrischen Verfahren (Sender und Empfänger benutzen denselben Geheimschlüssel) sind aufgeführt. Im ersten Fall stehen auch digitale Unterschriften zur Verfügung, im zweiten kann der Austausch des Geheimschlüssels auf drei Wegen erfolgen: in-band (Schlüssel wird mit dem öffentlichen Schlüssel des Servers geschützt), out-band (ein vorher festgelegter Schlüssel) und Kerberos (Nutzung von Kerberos-Tickets). Mit dem Sitzungsschlüssel läßt sich ein Transaktionsschlüssel chiffrieren, der bei der Datenverschlüsselung Anwendung findet.
S-HTTP definiert einen neuen URL-Protokolltyp 'shttp', der auf die Fähigkeiten des Servers bezüglich S-HTTP hinweist. Der Client wird damit aufgefordert, bereits
die Anforderung gekapselt zu senden. Die dazu notwendigen Informationen sind in
neuen Attributen (DN, NONCE, CRYPTOPTS) des Ankers für diesen Link beziehungsweise
dem neuen Sprachelement (tag) CERTS enthalten. Damit lassen sich beispielsweise
die Informationen eines Formulars verschlüsseln.
SSL
Das zweite Protokoll mit kommerziellem Hintergrund erlangt seine Bedeutung durch die
große Verbreitung des Web-Browsers Netscape Navigator. Dieser Client beherrscht ein
Protokoll namens Secure Socket Laver (SSL). Wie der Name andeutet, ist es nicht nur
für HTTP vorgesehen, sondern soll jedes zuverlässige Transportprotokoll (im Falle
Netscape/SSLRef: TCP) um ein Konzept für einen sicheren Kanal (Vertraulichkeit,
Authentifikation, Datenintegrität) erweitern.
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:
Die Organisation von SSL als Layer zwischen Applikations- und TransportSchicht erlaubt
dabei, zusätzlich auf Anwendungsebene Sicherheitsprotokolle wie S-HTTP (Secure HTTP)
oder SET (Secure Electronic Transactions) zu implementieren. Dadurch läßt sich die
Gesamtsicherheit des Systems noch einmal steigern, wenn auch zu Lasten der Performance.
- 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
(http://www.verisign.com) und
Globalsign
(http://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
Die Idee zum wahrscheinlich am weitesten verbreiteten Programm zur Nutzung von
Einmalpaßwörtem (OTP: orte time password) stammt bereits aus dem Jahre 1981. Aber
erst ein knappes Jahrzehnt später wurde sie in den Bellcore Labs aufgegriffen und
nahm als S/Key Gestalt an. Der zugrundeliegende Mechanismus ist verblüffend einfach:
Aus einem geheimen Paßwort s wird durch N-fache Anwendung einer sicheren Hash-Funktion
(MD4) ein OTP erzeugt:
P0 = fN(s)
Das nächste OTP erhält man durch (N -1)-maliges Anwenden des Hash:
P1 = fN-1(s)
Die generelle Erzeugunsvorschrift lautet damit:
Pi = fN-i(s)
bzw.
Pi = f(Pi+1)
Erlangt ein Unberufener Kenntnis von einem OTP Pi, kann er trotzdem nicht
das nächste zu verwendende Paßwort Pi+1 ermitteln, da sich die Umkehrung
f'(pi) der sicheren Hash-Funktion nicht berechnen läßt. Der entfernte
Host erhält zunächst das OTP P0. 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 pi+1. Der Host führt
folgende Berechnung durch:
Pi = f(fN-i-1l(s)) = f(Pi+1)
Stimmt der berechnete Wert nut dem gespeicherten überein, so ist der Nutzer
authentifiziert. Daraufhin überschreibt der Host das alte OTP pi mit dem
soeben erhaltenen Pi+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)
Unter "SSH" versteht man einerseits ein Programm, die Secure Shell, andererseits aber
eine Protokoll-Schnittstelle, über die auch Dateien kopiert oder andere Protokolle
getunnelt werden können. Das SHH-Protokoll wurde von Tatu Ylönen an der TU Helsinki
in Finnland entwickelt. Dieses Protokoll wurde erstmalige im Juni 1995 als lizenzfreie
Version 1.0 freigegeben. Von da an wurden stets Weiterentwicklungen unternommen, an
denen hauptsächlich die von Ylönen gegründete Firma SSH Communications Security Ltd.
beteiligt war und ist. Derzeit befindet sich eine Version 2.0 auf dem Markt, die
jedoch nicht mehr kommerziell vertrieben wird, sondern lizenzpflichtig ist.
Des weiteren gibt es eine Reihe freier Implementierungen, wie z.b. OpenSSH, die
auf das Protokoll 1.X aufsetzen und daher frei verfügbar sind
(http://www.openssh.org).
Die Secure Shell ermöglicht das Einloggen auf einem anderen Rechner über das Netz, um
Programme auf dem Remote- Rechner auszuführen oder Dateien über das Netz zu kopieren.
Einerseits unterstützt sie dabei die zuverlässige gegenseitige Authentifizierung der
Partner. Andererseits bietet sie sicheren Schutz vor dem Abhören der Kommunikation
(Unterbindung von "Man in the middle attack", "IP-Spoofing", "Hijacking", etc.) und
zuverlässige Integritätsüberwachung. Dabei kommt es vor allem an auf starke Verschlüsselung
des Datenverkehrs, X11 Forwarding, Port Forwarding, sichere Authentifzierung, Agent
Forwarding und Datenkompression. Von SSH werden ausschließlich symmetrische
Verschlüsselungsalgorithmen zum Austausch der übermittelten Daten unterstützt: IDEA,
DES, 3DES, Blowfish, TwofishArcfour.
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 eH
und eS (Host- und Server-Key) sowie eine Auflistung der von ihm
unterstützten symmetrischen Chiffren zum Klienten. Der Client verifiziert eH
mit Hilfe einer lokalen Datenbasis (bzw. "lernt" diesen Key, falls der Nutzer es zuläßt).
- Wurde eH akzeptiert, generiert der Client einen zufälligen
Sitzungsschlüssel, chiffriert diesen mittels der beiden RSA-Keys eH und
eS. 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:
- 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.
- 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.
- 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.
- 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:
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 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
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
Bei der Zugangsvalidierung über ssh gibt es im wesentlichen zwei
Möglichkeiten:
- 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
Es ist möglich, E-Mail, ftp, etc. über eine ssh-Verbindung zu tunneln.
Unverschlüsselte Verbindung
Verschlüsselte Verbindung
TSAP=Transport Service Access Point
ssh ohne Passwort
Public Key Authentication dient dazu, sich per SSH auf einem anderen
Rechner einzuloggen oder Dateien zu übertragen, ohne sich jedes Mal mit einem
Paßwort authentifizieren zu müssen. Technisch geschieht dies so, daß zwei zueinander
passende Schlüssel-Dateien erzeugt werden - in der einen steht der Private
Key, in der anderen der Public Key.
Der Private Key bleibt beim Benutzer und muß vor fremdem Zugriff
geschützt werden; der Public Key hingegen wird auf dem Server
hinterlegt.
Wenn der Benutzer sich nun anmelden möchte, überprüft der Server, ob er im
Besitz eines zum hinterlegten Public Key passenden Private Keys ist, und
gewährt nur dann den Zugang auch ohne Paßwort.
Wenn man Public Key Authentication benutzt, dann ist ab sofort der
Private Key dem normalen Paßwort gleichgestellt.
So wie man sein Paßwort vor fremdem Zugriff schützen muß (z.B. in dem man es
nicht aufschreibt und dann den Zettel rumliegen läßt - in einen Tresor gepackt,
wäre ein solcher Zettel aber o.k.), so muß man jetzt den Private Key
vor fremdem Zugriff schützen.
Deswegen besteht die Möglichkeit, den Private Key wiederum mit einer
Passphrase zu schützen - im Prinzip wie ein Paßwort für den Private
Key, nur ohne Längenbeschränkung.
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
Es wird jeweils ein privater Schlül und ein öffentlicher Schlüssel
generiert.
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
...
Je nach ssh-Version muß auch einer der anderen Keys verwendet werden,
z.B. id_dsa.pub nach authorized_keys2.
Es existieren drei Arten von Keys, die auch in unterschiedlichen
Dateien abgespeichert werde. Zu beachten ist, dass hier die
diversen Implementierungen (F-Secure ssh, OpenSSH) divergieren.
Falls die Dateien authorized_* schon existieren, müssen die
Keys an die Dateien angehängt werden.
- 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
...
Troubleshooting mit ssh -v, Zugriffsrechte aller Dateien auf go-rwx
setzen, gegebenenfalls einen eigenen sshd mit Debugging auf einem
nicht-privilegiertem Port starten.
Bei OpenSSH braucht man den Public Key einfach nur in der Datei
~/.ssh2/authorization eintragen mit der Zeile:
Key MEIN-SSH-PUBLICKEY.pub
In Verzeichnis ~/.ssh2/ sollte sich natürlich die Datei MEIN-SSH-PUBLICKEY.pub
befinden. Jetzt loggt man sich wieder aus und richtet den auf dem lokalen Rechner
verbliebenen Private Key zur Authentifizierung ein, indem die Zeile
IdKey MEIN-SSH-PUBLICKEY
in ~/.ssh2/identification einträgt.
Wenn nicht vorhanden, dann muss man den OpenSSH Public-Key in das SSH2-Format
bringen. authorized_keys2 enthält eine Zeile ohne Zeilenumbruch:
ssh-dss
AAAAB3NzaC1kc3MAAACBAIygQj1gQp+XTk9oaZdkI8FJoABaWjwJjTVxiXUdau7pIddAht3rmcAgrQEN
z6Cy4he7Dbdu
...
rpnVxyEKaHSYRmGDbB78810kugDeF5+lZs881MN7UnA3crygPs2PEXmpJIK+GfiztqJvf0UjzhaPofLI
sQ1O9Q== USER@HOST
Wird umgewandelt in die Datei ident-ssh2.pub geschrieben:
---- 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:
Informationen über den ssh-Verbindungsaufbau
Mit der Option -v wird ssh/scp im 'Verbose Mode'
aufgerufen. Hierdurch werden Informationen ausgegeben, die zur Problemanalyse
hilfreich sein können.
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)
IPSec (Internet Protocol Security) stellt nicht ein einziges Protokoll dar, sondern eine
Architektur zum Aufbau verschlüsselter Kommunikationsbeziehungen.Es wurde in den RFCs
1825 bis 1829 festgeschrieben. Es erfolgt eine Authentisierung und/oder Verschlüsselung
von Datenpaketen auf der IP-Paket-Ebene, also noch bevor UDP- oder TCP-Pakete in IP-Pakete
eingepackt und über die Leitung verschickt werden. Dieser Vorgang ist auf Ebene drei
(Net-work-Layer) des ISO-7-Schichtmodells angesiedelt. je nach Zweck wird zu dem IP-Header
(der ja die Quell- und die Zieladresse des Datenpakets trägt) ein Authentication Header
(kurz AH) eingefügt, oder die verschlüsselten Daten werden verpackt (ESP = Encapsulating
Security Payload). Mit dieser Sicherheitserweiterung kann demnach jedes einzelne Datenpaket vor Verfälschung geschützt und verschlüsselt werden. Damit würden einige Protokolle auf übergeordneten Schichten, wie z. B. SSL, bei bestimmten An wendungen überflüssig werden, denn je nach verwendetem Schlüssel lassen sich Pakete auch verbindungsorientiert sichern. Anwendungsbezogene Sicherheitsfunktionen, wie beispielsweise digitale Signaturen, werden weiterhin erforderlich sein, da IPSEC die Pakete nur auf dem Weg zwischen zwei Instanzen schützt. IPSEC ermöglicht
- 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:
- Protokolle zur Implemenation der Sicherheitsdienste: AH (Authentication Header) und ESP
(Encapsulating Security Payload)
- 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
Bei SET (Secure Electronic Transactions) handelt es sich um eine reine Anwendung, die
ausschließlich zur sicheren Abwicklung von Zahlungsvorgängen dient. Ziel der maßgeblich
von Mastercard und Visa getragenen Initiative ist es, einen Standard für das sichere
Bezahlen mit Kreditkarten in unsicheren Netze, wie z. B. das Internet, zu schaffen.
Für den nur zögernd anlaufenden Electronic Commerce wird von diesem Standard erwartet,
daß er die notwendige Sicherheit und damit auch Akzeptanz auf Seiten der Nutzer
realisiert. Darüber hinaus gewährleistet SET, daß es zu keinem Medienbruch bei der
Abwicklung von Bestell- und Zahlungsvorgängen kommt. SET wurde auf der Basis von
sieben sogenannten Business-Requirements entwickelt, die die Anforderungen an diesen
Standard wie folgt spezifizieren:
Weiterhin unterscheidet SET sieben an der Transaktion beteiligte Parteien:
Karteninhaber, Händler, Kartenherausgeber (für Karteninhaber), Akquisiteur
(für Händler), Zahlungs-Gateway, Kreditkarten-Institut diverse Zertifizierungsstellen
(Karteninhaber-Zertifizierungsstelle, Zahlungs-GatewayZertifizierungsstelle). Die
Transaktion zwischen Kunde und Händler hat folgenden formalen Ablauf:
- Zahlungs- und Orderinformationen sollen vertraulich behandelt werden.
- Die Integrität der im Rahmen des Zahlungsvorgangs übermittelten Daten soll gewährleistet sein.
- Der Kartenbenutzer muß sich als Karteninhaber authentisieren.
- Der Händler muß sich gegenüber dem Karteninhaber authentisieren.
- Es sollen die besten kryptografischen Verfahren verwendet werden.
- Das Protokoll soll nicht von sicheren Transportmechanismen auf unteren
Schichten abhängen, dessen Benutzung aber nicht verbieten.
- Das Protokoll soll auf verschiedenen Hard- und Software-Plattformen
lauffähig sein (Interoperabilität).
SET beschäftigt sich vor allem mit den unter Punkt 4, 5, 6 und 8 genannten Transaktionen.
Als kryptografische Methoden werden symmetrische Verfahren (DES zur Verschlüsselung der
Daten) sowie asymmetrische Ver-fah-ren (RSA) und Hashfunktionen (SHA1 für digitale
Signaturen zur Authentisierung und Integritätsprüfung) genutzt. Mit der Einführung
sogenannter dualer Signaturen hat das SET-Verfahren eine sehr interessante Lösung für
die selektive Geheimhaltung von Transaktionen zwischen Kunde, Händler und Bank entwickelt.
Diese Lösung stellt sicher, daß der Händler nicht in den Besitz der
Kreditkarteninformationen gelangt und das Finanzinstitut des Kunden nicht in den Besitz
der Bestellinformationen. Beide können aber prüfen, ob diese Informationen korrekt sind
(Integrität) und von wem sie gesendet wurden (Authentisierung). Der Ablauf ist wie folgt:
- Der Karteninhaber wählt Waren und Dienstleistungen per Internet aus.
- Der Karteninhaber trägt seine Auswahl in ein elektronisches Bestellformular ein.
- Der Karteninhaber wählt die Art der Bezahlung aus (derzeit nur die Bezahlung
per Kreditkarte).
- Der Karteninhaber versendet die Daten (Bestellung/Zahlungsinstruktionen) an den
Händler (Kartenmarke, Kartennummer usw.).
- Der Händler läßt sich die Zahlung durch die Finanzinstitution des Karteninhabers
bestätigen (Zahlungs-Authorisierungsanfrage).
- Der Händler sendet nach einer positiven Antwort eine Auftragsbestätigung an den Kunden.
- Der Händler liefert die Ware aus.
- Der Händler fordert von der Finanzinstitution des Karteninhabers die Bezahlung.
Analog dazu erfolgt die Transaktion des Kunden mit seiner Finanzinstitution,
wobei die Bank die ver-schlüs-selten Kreditkarteninformationen erhält die duale
Signatur und den Hashwert der Bestellung. Der wesentliche Vorteil ist, daß dieses
Verfahren auch vor nicht vertrauenswürdigen Händlern schützt denn
Kreditkarteninformationen gelangen niemals in die Hände eines Händlers.
Ein Nachteil des SET-Verfahrens ist der relativ große Aufwand. Der Kunde muß sich
zunächst eine mehrere MB umfassende Software aus dem Netz laden (Wallet-Software),
bevor er seine Buchungen absichern kann. Auch auf Banken und Händler kommt ein hoher
Aufwand an Supportleistungen zu. Mit dem SET-Verfahren zur Sicherung von
Kreditkartenzahlungen im Internet konkurrieren deshalb derzeit auch andere
Verschlüsselungssysteme, insbesondere auf der Basis von SSL.
- 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.
- Dieser Hashwert wird vom Kunden mit seinem privaten Schlüssel signiert (duale
Signatur).
- Der Benutzer sendet die duale Signatur, den Hashwert der Kreditkarteninformationen
und die verschlüsselten Bestellinformationen (HybridVerfahren) an den Händler.
- 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
Im August 1995 veröffentlichte der Zentrale Kreditausschuss (ZKA) das "Homebanking
Computer Interface" (HBCI), das als standardisierte Schnittstelle zwischen Kunde und
Bank, die bis dato gewachsenen, inkompatiblen Homebankingsysteme ablösen und
vereinheitlichen sollte. Bis heute wurde die HBCI-Spezifikation mehrfach überarbeitet
(aktuell: Version 2.2) und scheint sich zunehmend als europäischer Standard für
"Homebanking" durchzusetzen. Im Hinblick auf zukünftige Erweiterungen stellte man
zahlreiche Anforderungen an den neuen HBCI-Standard.
- 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:
In der Praxis unterstützen Programme wie Quicken oder StarMoney den neuen HBCI-Standard
und ermöglichen so den sicheren und einfachen Zugang. Voraussetzung neben einer geeigneten
Homebanking-Software ist natürlich, dass die Hausbank HBCI-Banking anbietet und ein
geeigneter Chipkartenleser für die HBCI-Chipkarten vorhanden ist. Derzeit existiert zwar
noch ein zweites Verfahren auf Basis von RSA-Disketten, dieses wird aber sicherlich in
naher Zukunft durch das weitaus sichere Chipkarten-System abgelöst werden. Die
HBCI-Chipkarten enthalten die, für die HBCI-Kommunikation notwendigen, geheimen Schlüssel
zur Signierung und Chiff-rierung der ausgetauschten Daten und wickeln alle
sicherheitsrelevanten Prozesse (Hashwert-bildung, Signierung, Verschlüsselung, etc.) ab.
Vorteil der Chipkarten: die geheimen Schlüssel verlassen nie die Karte, sie sind einfach
zu handhaben und machen unter anderem die umständ-lichen TAN-Listen überflüssig.
Damit das hohe Sicherheitsniveau bei der Nutzung von HBCI-Chipkarten auch gewahrt bleibt,
sollte man vor allem bei dem benötigten Chipkartenleser nicht sparen. Derzeit gibt es drei
Klassen von Chipkartenterminals, die sich hauptsächlich in ihren Sicherheitsmerkmalen
unterscheiden. Die einfachen Chipkartenleser werden der "Klasse 1" zugeordnet und eignen
sich nur eingeschränkt für sicherheitsrelevante Anwendungen, da sie von eingeschleuster
Software (Trojaner) durchaus manipuliert werden können. Besser geeignet sind daher
Chipkartenterminals der "Klasse 2", die nicht nur die sichere PIN-Eingabe mittels einer
eigenen Tastatur ermöglichen, sondern auf einem kleinen LC-Display auch alle
Transaktionen/Vorgänge zur Kontrolle und Bestä tigung anzeigen. Das höchste
Sicherheitsniveau bieten jedoch Chipkartenterminals der "Klasse 3", wobei derzeit nur
KOBIL solche Geräte liefern kann. Diese Chipkartenterminals verfügen über eine
Zulassung des ZKA und ermöglichen zusätzlich die Verwaltung von Signa-turen, das
sichere Bezahlen mit der Geldkarte im Internet, sowie das Aufladen der Geldkarte
(geplant für HBCI v3.0). Die HBCI - Spezifikation und FAQ des ZKA findet man unter
http://www.hbci.de.
- 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