Moin, ich bin in den vergangenen Tagen auf ein moegliches Angriffs-Szenario hingewiesen worden, welches sogar HBCI mit Chipkarte betreffen kann. Daraufhin habe ich es noch ein wenig ausgearbeitet.
Eine gute Nachricht vorweg: Libchipcard verhindert nach bestem Wissen, dass dieser Angriff erfolgreich ist - zumindest mit USB-Lesern unter Linux. Das Szenario ist in etwa so: Die Anwendung erstellt eine HBCI-Nachricht und will diese nun von einer Chipkarte signieren lassen. Dazu gibt der Benutzer - z.B. ueber die eingebaute Tastatur des Klasse-2-Lesers - seine Pin ein. Ab da sind die Crypto-Funktionen der Karte freigeschaltet, bis die Karte abgeschaltet oder resettet wird. Nachdem die Nachrichten mit dem Server ausgetauscht sind - zum Dekodieren wird ja wiederum die Karte benoetigt - kann die Karte erst wieder abgeschaltet bzw. resettet werden. Nun koennte aber eine Anwendung noch kurz vor dem resetten der Karte dazwischenfunken und einfach die Karte uebernehmen. Im schlimmsten Fall wuerde ein Schad-Programm einfach das Programm abschiessen (damit blockiert der Prozess nicht mehr den USB-Leser) und den Leser samt offener Karte uebernehmen. Damit koennte der Angreifer dann einfach eigene Nachrichten an den Server senden. Das muss der Benutzer im Zweifel nicht einmal mitbekommen. Wie verhindert Libchipcard das nun? Ich denke, bei USB-Lesern sind wir da auf der sicheren Seite: Libchipcard - bzw. der Treiberprozess - ist der einzige Prozess, der zu einem gegebenen Zeitpunkt den Leser offen halten kann (zumindest unter Linux ist es offensichtlich so, dass usb_claim_interface() das USB-Device exklusiv an den aufrufenden Prozess bindet). Das bedeutet, sobald Libchipcard anfaengt auf den Leser zuzugreifen, sind andere Prozesse aussen vor (also auch Schadprogramme). Wenn aber ein Schadprogramm den Leser schon vorher uebernommen hat, kann Libchipcard nicht darauf zugreifen und der Benutzer kommt gar nicht erst soweit, die Pin einzugeben, damit wird die Karte gar nicht erst freigeschaltet. Libchipcard ist nun im Umgang mit der Karte recht restriktiv: Es erlaubt nur einer Anwendung zu einem Zeitpunkt den Zugriff auf eine Karte. Sobald die Anwendung die Karte verliert - sei es, weil sie sie selber wieder freigibt oder weil das Programm abgestuerzt ist - wird von Libchipcard die Karte resetted, bevor sie wieder einem anderen Programm zugeteilt oder ganz abgegeben wird. Das bedeutet, selbst wenn ein Schadprogramm die Banking-Anwendung abschiesst, kann es die eventuell offene Karte nicht uebernehmen, bevor die Karte nicht resettet wurde (wodurch dann wieder eine Neu-Eingabe der Pin noetig waere, um Crypto-Funktionen auszufuehren). Das Ergebnis ist, dass der Zugriff via Libchipcard deutlich sicherer sein duerfte, als wenn die Anwendung direkt via CTAPI auf den Treiber zugreifen wuerde. AqBanking/OpenHBCI und die bekannten Projekte, die es verwenden - Gnucash, KMyMoney, QBankManager, LxBank, AqMoney etc - verwenden Libchipcard zum Zugriff auf die Karten, und sollten somit hinreichend sicher sein. Aber auch Anwendungen, die direkt auf den CTAPI-Treiber zugreifen - wie Moneyplex - koennen ueber den von Libchipcard mitgelieferten CTAPI-nach-Libchipcard-Wrapper von dieser zusaetzlichen Sicherheit profitieren, weil sie damit ebenfalls zu einem Libchipcard-Client werden, fuer den wieder die gleichen Regeln gelten. Fazit: Es ist gut, unsere Projekte zu verwenden :-) Gruss Martin -- "Things are only impossible until they're not" Martin Preuss - http://www.aquamaniac.de/ AqBanking - http://www.aqbanking.de/ LibChipcard - http://www.libchipcard.de/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Aqbanking-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
