SUCHE MIT Google
Web virtualuniversity.ch
HOME DIDAKTIK ECDL ELEKTRONIK GUIDES HR MANAGEMENT MATHEMATIK SOFTWARE TELEKOM
DIENSTE
Anmeldung
Newsletter abonnieren
Sag's einem Freund!
VirtualUniversity als Startseite
Zu den Favoriten hinzufügen
Feedback Formular
e-Learning für Lehrer
Spenden
Autoren login
KURSE SUCHEN
Kurse veröffentlichen

Suche nach Datum:

Suche mit Schlüsselwort:

Suche nach Land:

Suche nach Kategorie:
PARTNER
ausbildung24.ch - Ausbildungsportal, Seminare, Kursen... 

 
HTMLopen.de - Alles was ein Webmaster braucht

 
PCopen.de - PC LAN Netze und Netzwerke - alles was ein IT Profi und Systemtechnicker braucht

TELEKOM

Sichere Protokolle

S-HTTP

Das 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:

  • 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.
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.

PortnummerArtProtokoll
443HTTP über SSLHTTPS
465SMTP über SSLSSMTP
563NNTP über SSLSNNPS
992Telnet über SSLLNETS
995POP3 über SSLSPOP3

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:

  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

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.
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
Falls die Dateien authorized_* schon existieren, müssen die Keys an die Dateien angehängt werden.

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:

  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

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:
  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).
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:
  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.
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:
  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.
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.

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:

  • 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
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.

DIPLOMARBEITEN UND BÜCHER

Diplomarbeiten zum Runterladen:

Suche im Katalog:
Architektur / Raumplanung
Betriebswirtschaft - Funktional
Erziehungswissenschaften
Geowissenschaften
Geschichtswissenschaften
Informatik
Kulturwissenschaften
Medien- und Kommunikationswissenschaften
Medizin
Psychologie
Physik
Rechtswissenschaft
Soziale Arbeit
Sozialwissenschaften


JOBS
HOME | E-LEARNING | SITEMAP | LOGIN AUTOREN | SUPPORT | FAQ | KONTAKT | IMPRESSUM
Virtual University in: Italiano - Français - English - Español
VirtualUniversity, WEB-SET Interactive GmbH, www.web-set.com, 6301 Zug

Partner:   Seminare7.de - PCopen.de - HTMLopen.de - WEB-SET.com - YesMMS.com - Ausbildung24.ch - Manager24.ch - Job und Karriere