aus Wikipedia, der freien Enzyklopädie

[Bearbeiten] 2-Key-3DES

Hallo liebe IP 62.214.227.189, die Schlüssellänge von 2-Key-3DES soll durchaus im Artikel erwähnt werden, da bei diesem Thema jeder immer nach den Bits fragt. Natürlich ist 128 insofern falsch, als dass da die CRC mit reingerechnet wurde; richtig ist also 112 Bits (eben zweimal 56).

Und die Erklärung von 2-Key-3DES, naja, die steht so mitten im Artikel vielleicht nicht an idealer Position, aber anderswo ist sie auch nicht zu finden. Auf 3DES zumindest ist das dermaßen versteckt, daß es eigentlich gar nicht lohnt, dort hin zu verlinken. Aber wenn es einen extra Eintrag oder einen direkt erreichbaren, verständlichen Abschnitt auf 3DES gibt, dann kann die Erklärung hier auch gerne raus. --Cstim 14:03, 17. Aug 2005 (CEST)

Bin sonst eher Benutzer:134.60.1.151 *g*, vielleicht sollte man eher 3DES von DES abkoppeln? Ich seh dein Problem. Meines war, dass ich mich von den teils auch noch falschen Erklaerungen hab ablenken lassen und erst beim dritten lesen HBCI verstanden hab. --Benutzer:134.60.1.151 14:00, 2. Sep 2005 (CEST)

Na klar, mach doch gerne einen extra Artikel für 3DES auf. Sobald da eine vernünftig erreichbare Erklärung von 3DES ist, sollte die Erklärung hier auch wieder raus. Ich hab nur von den tatsächlich Crypto-Sachen nicht genug Ahnung, als dass ich mich da auch noch einmischen würde. --Cstim 14:13, 2. Sep 2005 (CEST)

[Bearbeiten] Kein Belauschen

"Bei diesem Verfahren kann weder der kryptographische Schlüssel der Karte ausgelesen werden, noch ist das Belauschen der PIN-Eingabe mit einem Keylogger oder Trojaner möglich." Kann jemand erklären warum das so ist? Oder auf eine erklärende Seite verweisen? --Pinetik 12:36, 2. Sep 2005 (CEST)

Das ist so, weil die Verschlüsselung der Daten (bzw. des Session-keys) in dem Prozessor der Chipkarte stattfindet. Der Schlüssel kommt wie erwähnt nie aus der Chipkarte raus, sondern der Computer schickt den cleartext zum Prozessor der Chipkarte und bekommt den ciphertext zurück. Der Chipkarten-Prozessor braucht aber halt die PIN dazu, und wenn diese direkt am Kartenleser eingegeben wird, dann kommt die PIN auch nie in den Computer rein, sondern wird nur vom Kartenleser an die Chipkarte gegeben. Ist das verständlich? --Cstim 13:02, 2. Sep 2005 (CEST)

Ack. Der Computer muss als generell unsicher angesehen werden. Die Karte "hoffentlich" nicht. Insofern ist HBCI ein Fortschritt, am besten wenn man alles an Display und Tastatur des Kartenlesers macht. --Benutzer:134.60.1.151 14:00, 2. Sep 2005 (CEST)

Naja, HBCI ist dann und nur dann ein Fortschritt, wenn man tatsächlich die Chipkarte als Sicherheitsmedium benutzt. Bei RDH (Schlüsseldiskette/-datei) fällt das weg (aber man hat wenigstens noch die Signatur der Aufträge), und bei PIN/TAN hat man gar nix. Die unterschiedlichen Sicherheitsmedien machen es schwer, eine einheitliche Aussage "über HBCI" (oder genauso FinTS) zu machen. --Cstim 14:13, 2. Sep 2005 (CEST)

[Bearbeiten] Restrisiko Chipkarte

Hallo, folgenden Absatz im Abschnitt "Technische Merkmale - Sicherheit" habe ich gelöscht:

Eine potentielle Gefahr herrscht jedoch weiterhin: Wenn es einem Schadprogramm gelingt, die Kommunikation zwischen Clientsoftware und Kartenleser zu manipulieren, dann besteht damit die Möglichkeit, veränderte Datensätze an die Chipkarte zu übermitteln. Die Karte fordert weiterhin die PIN des Benutzers an, welche auch nicht durch das Schadprogramm ausgespäht werden kann, und autorisiert anschließend den erhaltenen Transaktionsauftrag. Dieser entspricht jedoch nicht dem vom Benutzer erstellten. Mit entsprechenden Bemühungen kann es einer kriminellen Person also gelingen, auf sehr elegante Weise, vom Benutzer völlig unbemerkt, dessen Konto zu plündern.

Das stimmt nämlich nicht. Der Kartenleser verschlüsselt mitnichten den eigentlichen Auftrag, sondern nur den session key. Der session key wird in der Applikation erzeugt, ebenso wie der eigentliche Auftrag. Ein Angreifer will ja den Auftrag manipulieren (um das Empfängerkonto zu ändern). Da kommt er in diesem Fall nur noch ran, wenn er die Applikation verändert. Das wiederum ist bei kompromittiertem Computer durchaus theoretisch möglich, weshalb ich einen entsprechenden Text reingesetzt habe. Aber die Kommunikation zum Kartenleser bringt in diesem Fall gar nichts, denn der session key hat ja nix mit den Auftragsdaten zu tun. --Cstim 17:11, 10. Jan 2006 (CET)

Nachtrag: Na ja, vielleicht stimmt es doch so ein bisschen. Das Schadprogramm könnte sich auf diese Weise einen gültig signierten session key besorgen und der Applikation einen falschen unterjubeln. Die angegriffene Bankingsoftware kriegt beim Abschicken vom Bankserver die Rückmeldung "Signatur falsch", und das Schadprogramm könnte dann schnell mit dem signierten session key einen eigenen HBCI-Auftrag losschicken. Dazu müsste das Schadprogramm einerseits alle Zugangsdaten (HBCI-Benutzerkennung etc) aus dem angegriffenen Programm auftreiben und andererseits einen gültigen HBCI-Auftrag zusammenbasteln. Wäre also nur mit einem für ein bestimmtes Homebankingprogramm maßgeschneidertes Schadprogramm möglich, und das ist eigentlich die gleiche Kategorie als wenn ein Angreifer gleich das Homebankingprogramm direkt manipuliert. Es genügt eben nicht, nur in der Kommunikation zum Kartenleser ein paar Werte zu ändern. Also liebe IP 134.147.40.98 (ruhr-uni-bochum.de), wenn du das genauer formulieren willst, dann gerne, nur bitte beachten, dass in der Kommunikation zum Kartenleser noch nicht der Auftrag selber drin ist, sondern eben nur ein session key. --Cstim 17:26, 10. Jan 2006 (CET)