Praktikumsbericht über das praktische Studiensemester

Transkript

1 Praktikumsbericht über das praktische Studiensemester Semester WS06/07 Praktikant Alexander Behringer Studiengang Diplom Informatik Abgabetermin Ausbildungsstelle Wavecon GmbH

2 Vorwort Seit dem Wintersemester 2004/2005 studiere ich Informatik an der Georg-Simon- Ohm-Fachhochschule in der fränkischen Metropole Nürnberg. Nachdem ich 4 Semester lang theoretische Grundlagen vermittelt bekam, steht laut Studienplan im 5. Semester das Praxissemester an. Das ist neben dem 10-wöchigen Grundpraktikum die einzige Praxisphase im Studium und soll die verantwortliche Durchführung von Projekten/Teilprojekten der Softwareentwicklung oder [die] verantwortliche Übernahme von Aufgaben/Teilaufgaben bei der Abwicklung von Informatikdienstleistungen [1] zum Inhalt haben. Mir war es wichtig, dass ich sowohl Erfahrungen in der Softwareentwicklung als auch beim Abwickeln von Informatikdienstleistungen sammle. Dies ermöglichte mir die Wavecon GmbH, die hauptsächlich in der Serveradministration und in der Entwicklung von Webanwendungen tätig ist. Ich sammelte schon während des zweiten Teils des Grundpraktikums Erfahrungen in diesem Unternehmen was den Vorteil hatte, dass die Orientierungsphase zu Beginn des Praktikums kürzer ausfällt und ich mich schnell auf meine Aufgaben konzentrieren konnte. Im Folgenden wird das Hauptprojekt meiner Praktikumstätigkeit vorgestellt, in dem es darum geht, Überweisungen und andere Bankgeschäfte über eine PHP- Anwendung zu realisieren. 1

3 Inhaltsverzeichnis 1 Wavecon GmbH Meine Aufgabenfelder Projekt HBCI4PHP Projektvorstellung Motivation Projektziel Begriffserklärung HBCI PHP Exkurs: HCBI im Detail Sicherheit von HBCI Benötigte Hardware Vergleich von HBCI mit PIN/TAN Realisierung Anforderungen Mögliche Herangehensweisen Entwicklungsmodell Verwendung von Bibliotheken Unterschied zwischen Programmen und Bibliotheken AqBanking Lizenz Hilfreiche Programme Debugger Dokumentation Reflektion Resultat Verbesserungsmöglichkeiten Begangene Fehler Neue Erkenntnisse Persönliches Fazit 22 2

4 Kapitel 1 Wavecon GmbH Firmenbeschreibung in der Onlineversion nicht verfügbar. 1.1 Meine Aufgabenfelder Mein Aufgabengebiet war neben dem Hauptprojekt HBCI4PHP, das im weiteren Verlauf des Dokuments näher beschrieben wird, die Unterstützung bei täglichen Administrationsarbeiten wie dem Einspielen neuer Patches oder den Änderungswünschen von Kunden. Dazu kam das Inbetriebnehmen neuer Server und die Unterstützung beim Aufbau und der Einrichtung ganzer Infrastrukturen. 3

5 Kapitel 2 Projekt HBCI4PHP 2.1 Projektvorstellung Motivation Der bisherige Arbeitsablauf bei der Abrechnung einer Dienstleistung war mit viel Aufwand verbunden und erforderte häufig redundante Dateneingaben. In welchem Ausmaß dieser Workflow unnötig Arbeitszeit kostet zeigt folgende Skizzierung: Entgegennehmen der Bestellung per Ticketsystem Bearbeiten der Aufgabe Dokumentation der Arbeitszeit im Ticketsystem und Verschieben des Tickets in Rechnungswarteschlange Erstellung der Rechnung (Empfängerdaten meist in s gespeichert) Anstossen einer Lastschrift über die Weboberfläche der Bank Deutlich zeigt sich an wie vielen Stellen mit den Kontaktdaten des Auftraggebers gearbeitet wird. Oft werden beim Erstkontakt die Adressdaten im Ticketsystem gespeichert. Bei der Erstellung der Rechnung ist es nötig diese Daten in ein OpenOffice Writer Dokument zu kopieren und schließlich wird mit den selben Informationen eine Lastschrift angestoßen. Dieser Ablauf hat einige Optimierungsmöglichkeiten, die eine erhebliche zeitliche Einsparung mit sich bringen. 4

6 2.2 Begriffserklärung Projektziel Der in der Motivation skizzierte Ablauf lässt sich massiv vereinfachen, wenn die Kontaktdaten an einer zentralen Stelle gespeichert werden. Außerdem kann die Erstellung der Rechnung automatisiert werden, wie auch das Anstossen der Lastschrift. Die Ablösung des Ticketsystems durch ein eigenes in PHP geschriebenes Kundenverwaltungssystem wird für die zentrale Datenhaltung sorgen. Damit lassen sich automatisch Rechnungen im PDF-Format erstellen. Die Integration einer Onlinebankingmöglichkeit gestaltet sich unterdessen schwieriger, da hierbei ein Datenaustausch mit einer Bank nötig ist. Bisher wurden Transaktionen per Weboberfläche erstellt, was eine Automatisierung nahezu unmöglich macht. Jedoch wird von den meisten Banken inzwischen auch eine andere Art des Onlinebanking angeboten, nämlich HBCI (Homebanking Computer Interface). Unter Benutzung dieser Schnittstelle wird die Möglichkeit geschaffen, eine Lastschrift ohne zusätzliche Eingaben mit der Generierung der Rechnung in Auftrag zu geben. 2.2 Begriffserklärung HBCI HBCI steht für HomeBanking Computer Interface und wurde im Jahre 1998 in der ersten praxistauglichen Version 2.01 vom Zentralen Kreditausschuss (ZKA) verabschiedet. Durch die Standardisierung dieser Schnittstelle wurde eine Unabhängigkeit von Banken geschaffen, da sich alle Teilnehmer an die im Standard definierten Regeln halten müssen. Im Regelwerk werden die beiden wichtigsten Bereiche des Onlinebanking, Sicherheit und Geschäftsvorfälle, definiert. Verschiedene Verfahren zur Authentifizierung und Verschlüsselung der Nachrichten sorgen dafür, dass die Geschäftsvorfälle wie Anzeige des Kontostands, Neue Überweisung oder Änderung des Dauerauftrags sicher zur Bank übertragen werden können. Alle weiteren Äußerungen in diesem Dokument beziehen sich auf den Standard HBCI 2.2, welcher im Jahr 2000 veröffentlicht wurde [3] PHP PHP steht ursprünglich für Personal Home Page Tools aber wird inzwischen meist als PHP: Hypertext Preprocessor bezeichnet. Diese serverseitige Skriptsprache ist 5

7 2.3 Exkurs: HCBI im Detail die derzeit am weitesten verbreitete Programmiersprache für dynamische Webanwendungen. Die häufige Verwendung ist auch dem Umstand zu verdanken, dass PHP von Anfang an als Open-Source-Software entwickelt wurde und sich so schon frühzeitig eine große Gemeinschaft gebildet hat. Weitere Vorteile der Sprache sind die einfache Erlernbarkeit, die unkomplizierte Erweiterung und die Plattformunabhängigkeit. Der Kern der Sprache ist die Zend Engine, welche mittlerweile von dem kommerziellen Unternehmen Zend entwickelt wird und grundlegende Funktionen anbietet. Es besteht die Möglichkeit die Funktionen des Kerns über Module, den sogenannten Extensions zu erweitern und so die Funktionalität anderer Programme in PHP zu integrieren. Wie PHP selbst so werden auch die Extensions in der Sprache C geschrieben, aber um die Stabilität des zu gewährleisten werden die Extensions strikt vom Kern getrennt. Oft gibt es Problemstellungen, die man als Extension oder als PHP-Klasse lösen kann. Mit den C-Erweiterungen ist es im Gegensatz zu den PHP- Quelltexten möglich den Quellcode zu schützen und des Weiteren ist die Ausführung schneller. 2.3 Exkurs: HCBI im Detail Sicherheit von HBCI Beim Entwurf von HBCI [3] wurden hohe Anforderungen an die Sicherheit gestellt um einen Missbrauch der sensiblen Bankfunktionen zu verhindern. Aus diesem Grund kommt beim Nachrichtentransport ausschließlich bewährte Kryptographie zum Einsatz, wie RSA und Triple-DES. Die dafür nötigen Schlüssel werden idealerweise auf einer Chipkarte gespeichert, welche diese geheimen Informationen unzugänglich verwahrt. Folglich werden hierbei die kryptographischen Berechnungen von der Chipkarte durchgeführt, die natürlich keine leistungsstarke Recheneinheit besitzt. Jedoch waren diese Medien 1998 (als HBCI verabschiedet wurde) noch sehr teuer und daher wurde auch das Abspeichern eines Schlüsselpaares auf ein Wechselmedium (z.b. eine Diskette) vorgesehen. Vom ZKA wird auf lange Sicht eine einheitliche Verwendung einer RSA-Chipkarte angestrebt. Jedes Sicherheitsverfahren impliziert neben der Verschlüsselung der Nachrichten auch die Signierung. Durch das elektronische Unterschreiben wird garantiert, dass sich die Bank sicher sein kann, dass ein bestimmter Kunde wirklich der Absender dieser Nachricht ist - sofern sie mit seiner Signatur unterschrieben ist. Diese Garantie nennt sich im kryptografischen Umfeld die Unabstreitbarkeit. 6

8 2.3 Exkurs: HCBI im Detail Um maximale Sicherheit bei der Chiffrierung zu gewährleisten wird bei jeder Nachricht ein neuer Schlüssel verwendet, welcher zufällig berechnet wird. Dieser wird verschlüsselt in die Nachricht eingefügt und die eigentlichen Nutzdaten werden mit dem Zufallsschlüssel chiffriert. Im Folgenden werden die in Frage kommenden Medien beschrieben. DES-Chipkarte (DDV) Die DES-Chipkarte setzt auf dem symmetrischen Verschlüsselungsalgorithmus DES auf, daher wird das hier eingesetzte Verfahren auch DES-DES-Verfahren (DDV) genannt. Es ist erforderlich, dass die Schlüssel von der Bank auf einer ZKA-Karte, welche durch den Zentralen Kreditausschuss autorisiert ist, gespeichert werden. Die Legitimation der Chipkarte erfolgt mit der Ausgabe durch das Kreditinstitut. Im Falle der Kompromitierung des Schlüssels ist wie auch bei einer Schlüsseländerung die Ausgabe einer neuen Karte mit neu generierten Schlüsseln nötig. Um eine Nachricht mit Hilfe eines symmetrischen Verschlüsselungsverfahren zu signieren wird für jede Nachricht ein sogenannter Message Authentication Code (MAC) berechnet. Für die Berechnung ist ein kryptografischer Hash der Nachricht von Nöten, welcher ein eindeutiges Abbild der Nachricht darstellt. Dieser Prüfcode wird mit dem Schlüssel des Kunden mit Triple-DES chiffriert. Damit ist sichergestellt, dass die übersandte Signatur tatsächlich vom Kunden erstellt wurde. Die Verschlüsselung der Nachricht erfolgt blockweise durch Triple-DES. Als Schlüssel wird die vorher erwähnte Zufallszahl verwendet. RSA-Schlüsseldiskette (RDH) Bei der RSA-Schlüsseldiskette wird vom Benutzer ein privater und öffentlicher RSA- Schlüssel erstellt. Er überträgt den öffentlichen Schlüssel und den eindeutigen Fingerprint seines privaten Schlüssels an die Bank, welche nach Verifikation des Fingerprints den Schlüssel akzeptiert und somit die Karte freischaltet. Durch das asymmetrische Verschlüsselungsverfahren ist bei Kompromitierung des Schlüssels einfach ein neues Paar zu generieren, welches nach der eben genannten Prozedur wieder akzeptiert wird. Bei der Signatur der Nachricht wird zur Erzeugung eines Hashs analog dem DD- Verfahren vorgegangen. Anschließend wird dieses Abbild durch RSA mit dem privaten Schlüssel des Kunden verschlüsselt. Die Bank entschlüsselt die Signatur mit dem öffentlichen Schlüssel des Kontoinhabers und bei Übereinstimmung mit der eigenen Hashberechnung wird die digitale Unterschrift akzeptiert. 7

9 2.3 Exkurs: HCBI im Detail Abbildung 2.1: Triple-DES Verfahren mit 2 Schlüsseln [3] Abbildung 2.2: Verschlüsselung mit DES [3] 8

10 2.3 Exkurs: HCBI im Detail Abbildung 2.3: Verschlüsselung mit RSA und DES [3] Im Gegensatz zum DES-DES-Verfahren wird bei der RSA-Schlüsseldiskette der Nachrichtenschlüssel mit RSA chiffriert - der Nachrichteninhalt nach wie vor mit Triple-DES. Daher wird dieses Vorgehen RSA-DES-Hybridverfahren (RDH) genannt. RSA-Chipkarte Bei der RSA-Schlüsseldiskette wird das Schlüsselpaar auf einem Wechseldatenträger gespeichert und es ist dringend notwendig den privaten Schlüssel kryptografisch zu schützen. Zur Erhöhung der Sicherheit und Steigerung des Komforts ist es vorgesehen eine RSA-Chipkarte zu benutzen. Diese besitzt neben einer Recheneinheit auch einen kleinen geschützen Speicher, der den privaten Schlüssel aufnimmt und sicher verwahrt. Die kryptografischen Funktionen (Ver-/Entschlüsseln, Signieren und Verifizieren) führt die spezialisierte Recheneinheit mit exklusivem Zugriff auf den geheimen Schlüssel durch. Ansonsten kommt hier das gleiche Verfahren wie bei der RSA-Schlüsseldiskette zum Einsatz (RDH). Der Vollständigkeit halber sei noch erwähnt, dass es in der praktischen Umsetzung von HBCI jeweils 2 Schlüsselpaare gibt - ein Paar für die Verschlüsselung und eines für die Signierung. Dies hat jedoch für das Verständnis keinen Einfluss auf die beschriebenen Verfahren. 9

11 2.3 Exkurs: HCBI im Detail Benötigte Hardware Damit die vom Onlinebankingprogramm generierten Nachrichten auch an die Chipkarte zur Verarbeitung geschickt werden können, ist ein Kartenlesegerät notwendig. Diese werden in verschiedenen Varianten angeboten, von denen die einfachsten nur über einen Kartenschlitz verfügen und die sichersten Geräte besitzen sogar über ein eigenes Eingabefeld für die PIN, mit welcher der geheime Schlüssel geschützt ist. Folgende Kategorien wurden vom ZKA definiert: Sicherheitsklasse 1: Diese Geräte haben keine besonderen Sicherheitsmerkmale und dienen nur als Kontaktiereinheit für die Chipkarte. Sicherheitsklasse 2: Ab dieser Sicherheitsklasse besitzt das Lesegerät ein eigenes Eingabefeld für die PIN. Damit ist das Ausspähen der Geheimnummer bei der Eingabe durch einen Keylogger nicht möglich wodurch die Sicherheit massiv erhöht wird. Ein Keylogger ist ein Programm, welches alle Tastatureingaben abfängt und, sofern es in einen Trojaner eingebaut ist, an einen bestimmten Server schickt. Sicherheitsklasse 3: Hierbei handelt es sich um einen Leser der zweiten Klasse, der mit besonderen Funktionen ausgestattet ist, die das Bezahlen mit der Geldkarte über das Internet ermöglicht Vergleich von HBCI mit PIN/TAN Worin besteht nun der eigentliche Vorteil von HBCI gegenüber PIN/TAN? Im Abschnitt wurden die Sicherheitsmaßnahmen von HCBI unter die Lupe genommen. Schauen wir uns nun an wie es beim bekannten PIN/TAN Verfahren um die Sicherheit beschert ist. Sicherheit Ein Großteil der Kontobewegungen wird heute über Onlinebanking abgewickelt. Dies sieht in der Regel so aus, dass sich der Kontoinhaber mit seinem Browser zum Webserver seiner Bank verbindet. Um die Verbindung zu sichern wird inzwischen von jedem ernstzunehmenden Anbieter Secure Sockets Layer (SSL) mit 128 Bit Schlüssellänge verwendet. Beim Verbindungsaufbau zwischen Browser und Bankserver wird ein Sitzungsschlüssel ausgehandelt (Diffie-Hellman-Verfahren), mit welchem der gesamte Verkehr der aktiven Banksitzung gesichert wird. Es wird also 10

12 2.4 Realisierung nicht jede Nachricht mit einem neuen Schlüssel verschlüsselt, wie es bei HBCI der Fall ist, sondern alle Nachrichten einer Sitzung werden mit dem selben Geheimnis verschleiert. Hinzu kommt, dass das Diffie-Hellman-Verfahren gegen eine Man-in-the-Middle- Attacke anfällig ist [5]. Schafft es ein Angreifer den Anwender dazu zu bringen eine präparierte Webseite aufzurufen, die sich als Internetseite der Bank ausgibt, ist der erste Schritt zum Betrug getan. Da die Website eine optische Originalkopie der Bankanwendung ist wird der nicht auf Sicherheit bedachte Benutzer mit seinen Bankangelegenheiten fortfahren. Jegliche Information wird an den Webserver des Täters geschickt und dieser simuliert die Durchführung der Aktionen. Im Hintergrund jedoch werden andere Geschäftsvorfälle angestossen. So wird beispielsweise die TAN für eine Überweisung nicht benutzt um eine Rechnung des Kontoinhabers zu begleichen, sondern um die Ersparnisse auf das ausländische Konto des Angreifers zu transferieren. Um den eventuellen Schaden zu begrenzen gibt es ein tägliches Überweisungslimit. Dieser Angriff ist jedoch nur erfolgreich, wenn der Benutzer den Sicherheitswarnungen seines Internetbrowsers keine Aufmerksamkeit schenkt oder fahrlässig den Links in Phising- s zum angeblichen Webauftritt der Bank folgt. Mobilität Neben der Sicherheit spielen aber auch andere Merkmale eine Rolle bei der Benutzung eines Onlinebanking-Verfahrens. Viele Anwender sind darauf angewiesen auch unterwegs Bankgeschäfte erledigen zu können. Bei HBCI ist hierzu immer das Mitführen des Schlüssels nötig, meistens kommt auch noch die Chipkarte samt Lesegerät dazu. Außerdem sind mit Benutzung des sicheren HBCI-Verfahrens meist zusätzliche Kosten verbunden, da durch die Schlüsselverifikation ein Arbeitsaufwand entsteht und die Kosten für die Chipkarte oft nicht von der Bank übernommen werden. Auch Lesegeräte müssen sich die Anwender in der Regel selbst besorgen. 2.4 Realisierung Anforderungen Wie im Projektziel beschrieben sollen Lastschriften bei der Rechnungserstellung automatisch angestossen werden. Außerdem soll es auch möglich sein Daueraufträge zu verwalten und Überweisungen zu tätigen. Unbedingt erforderlich ist die Integration dieser Funktionalität in das Kundenverwaltungssystem, welches in PHP realisiert 11

13 2.4 Realisierung wird - daher ist diese Skriptsprache um Onlinebankingfunktionen zu erweitern. Um dies zu erreichen wird die Programmlogik von AqBanking (Bibliothek für Homebanking) benutzt Mögliche Herangehensweisen Die Funktionlität von AqBanking kann auf verschiedene Art und Weise in PHP genutzt werden. Unter Benutzung des mitgelieferten Kommandozeilenprogrammes können über normale Systemaufrufe aus der Webanwendung heraus Geschäftsvorfälle in Auftrag gegeben werden. Bei dieser Methode wäre kein großer Implementierungsaufwand nötig, da keine PHP Extension benötigt wird. Jedoch müsste man die Ausgaben des Konsolenprogrammes Einlesen und Verarbeiten, was sehr fehleranfällig ist. Eine simple Änderung in der Ausgabe des aufgerufenen Programms würde eine Fehlfunktion der Webanwendung verursachen. Daher ist diese Methode für das Projekt unbrauchbar. Viel robuster ist die direkte Benutzung der AqBanking Bibliothek, da die Schnittstellen (API, Application Programming Interface) von Bibliotheken in der Regel weitaus stabiler sind als Ausgaben eines Programms. Ferner existiert keine Beschränkung durch die eingeschränkte Funktionalität des Konsolenprogramms. Der Implementierungsaufwand ist zwar bedeutend höher, jedoch ist die Robustheit der Software wichtiger Entwicklungsmodell Bei der Entwicklung des PHP-Moduls war es wichtig, schnell lauffähig Ergebnisse präsentieren zu können. Außerdem handelt es sich hierbei um mein erstes PHP- Modul und somit musste ich mich erst durch Learning-by-doing in die Materie einarbeiten. Bekannte und häufig verwendete Entwicklungsmodelle wie das V-Modell oder das Phasenmodell schieden aufgrund der Komplexität und der bisher unbekannten Materie aus. Daher entschieden wir uns für das evolutionäre Prototyping [6]. Bei dieser Methode werden die geforderten Funktionen Schritt für Schritt einbaut und dabei ist der Prototyp immer lauffähig. Die grössen Vorteile dieser Vorgehensweise sind die schnellen Ergebnisse, was die Motivation vor allem zu Beginn des Projektes sehr steigert. Auch die Anforderungen sind stets kontrollierbar und es wird verhindert, dass sich das Projekt über einen langen Zeitraum in die falsche Richtung bewegt. Schließlich ist der Projektfortschritt 12

14 2.5 Verwendung von Bibliotheken sehr gut erkennbar, welcher sich an der Anzahl der implementierten Funktionen ablesen lässt. Natürlich sollen die Nachteile nicht verschwiegen werden. Durch die möglichst schnelle Implementierung der Funktionen wird oft nicht viel Zeit für eine ausführliche Dokumentation aufgebracht. Im späteren Projektverlauf macht sich eventuell auch die Tatsache negativ bemerkbar, dass die Anforderungen zu Beginn nicht klar spezifiziert wurden und so teilweise Funktionen an die später erkannten Anforderungen angepasst bzw. neu programmiert werden müssen. 2.5 Verwendung von Bibliotheken Unterschied zwischen Programmen und Bibliotheken Im Gegensatz zu normalen ausführbaren Programmen handelt es sich bei Bibliotheken (Libraries) um Module, die nicht eigenständig lauffähig sind. Sie beinhalten Funktionen, die von verschiedenen Anwendungen benutzt werden können. Um auf diese Routinen zugreifen zu können ist die Einbindung der zugehörigen Headerdatei nötig, in der alle verfügbaren Funktionen samt ihrer Signatur (also dem Rückgabewert und den erlaubten Parametern) aufgelistet sind. Der große Vorteil dieser Art von kompliliertem Programmcode ist die Wiederverwendbarkeit und die einmalige Aufbewahrung im Arbeitsspeicher. Bibliotheken, die von mehreren Programmen gleichzeitig genutzt werden können und nur einmal im Arbeitsspeicher abgelegt werden nennt man dynamische Bibliotheken. Dies ist vor allem in Multitasking-Systemen sehr von Vorteil, wenn es sich um große Funktionsarchive handelt und diese von Prozessen oft verwendet werden. Anders verhalten sich die statischen Bibliotheken. Sie werden nicht wie die dynamischen Variante zur Laufzeit geladen, sondern bei der Kompilierung mit in die ausführbare Binärdatei eingebunden. Daraus resultiert eine grössere Ausführungsdatei die damit auch länger braucht in den Arbeitsspeicher geladen zu werden. Vorteil dieser Variante ist die Unabhängigkeit von Versionssprüngen von Bibliotheken auf dem System und somit wird Stabilität garantiert AqBanking Wie im Abschnitt erwähnt wird auf die Funktionalität der Onlinebanking- Bibliothek AqBanking aufgebaut. Die zum Zugriff auf die Chipkarte nötigen Funktionen werden von der ebenfalls vom gleichen Autor, Martin Preuss, geschriebenen Bibliothek libchipcard zur Verfügung gestellt. 13

15 2.5 Verwendung von Bibliotheken Die grundlegende Idee hinter AqBanking ist die Verbindung von Homebankingprogrammen mit den zahlreich existierenden Protokollbibliotheken. So kann mittels AqBanking nicht nur via HBCI auf das Konto zugegriffen werden, sondern es stehen folgende Wege zur Auswahl: HBCI Bei HBCI handelt es sich um die in Deutschland am weitesten verbreitete Schnittstelle (siehe Abschnitt 2.2.1). OFX Direct Connect Dieses Protokoll wird hauptsächlich in den USA verwendet. DTAUS DTAUS wurde 1976 ursprünglich dazu entworfen um Bankgeschäfte über Disketten abzuwickeln (Datenträgeraustausch-Verfahren). Die Gültigkeit der darauf gespeicherten Transaktionen bestätigte der sogenannte Datenträgerbegleitzettel, auf dem der Kontoinhaber unterschrieb. Heute werden diese DTAUS- Dateien elektronisch übertragen und die Legitimation erfolgt über das PIN/TAN- Verfahren oder HBCI. Geldkarte Da viele EC-Karten heutzutage gleichzeitig als Geldkarten benutzt werden können, ist es auch möglich den verfügbaren Betrag und die Transaktionen über AqBanking anzurufen. Mit dem richtigen Chipkartenleser (Typ 3, siehe Abschnitt 2.3.2) kann die Geldkarte auch für die Bezahlung im Internet verwendet werden. YellowNet Damit können Kontostände und -umsätze des Schweizer Kreditinstituts Postfinance abgerufen werden. Außerdem werden von AqBanking folgende Geschäftsfälle unterstützt (gilt nicht für alle Protokolle) [7]: Empfangen von Kontoinformationen Empfangen des Kontostandes Überweisungen Lastschriften Interne Überweisungen (zwischen 2 Konten einer Bank) 14

16 2.5 Verwendung von Bibliotheken EU Überweisungen Daueraufträge Zeitlich festgelegte Überweisungen Lizenz Bei der Benutzung von Bibliotheken ist stets darauf zu achten unter welcher Lizenz diese Programme veröffentlicht wurden. Oft schreiben Lizenzen vor wie Programme benutzt oder verbreitet werden dürfen. Dies ist auch bei AqBanking der Fall, welches unter der GNU General Public License (GPL) lizensiert ist. Die GPL wurde im Rahmen des GNU-Projekts im Januar 1989 veröffentlicht, welches mit dem Ziel gegründet wurde ein vollständig freies Betriebssystem zu entwickeln. Dieses Grundsystem, welches systemnahe Befehle wie beispielsweise für das Kopieren von Dateien zur Verfügung stellt, ist ohne Systemkern nicht lauffähig. Daher wird oft der Linuxkernel im Zusammenspiel mit dem GNU-System verwendet, wodurch der Name GNU/Linux entstand. Kerngedanke der GPL ist das Copyleft- Prinzip, welches die Offenlegung des Quelltextes erfordert [8]. Daher ist man bei der Veröffentlichung von Software, die auf GPL-lizensierte Programme oder Bibliotheken aufbaut, verpflichtet den Programmcode freizugeben. Dieser ist entweder kostenlos oder zum Selbstkostenpreis anzubieten. Dies ist eine sehr starke Restriktion in der ansonsten so freien Lizenz. So darf eine Software, die unter GPL veröffentlicht wurde, ohne Einschränkung benutzt werden. Sie darf auch verkauft werden, sofern der Quelltext stets mitgeliefert wird. Es dürfen auch veränderte Versionen von GPL-Programmen vertrieben werden, wenn wiederrum sichergestellt ist, dass der Programmcode für Jedermann zugänglich ist. Eine oft und gerne benutzt GPL-Software ist IPTables vom Netfilter Projekt, welche oft in Routern integriert wird. Es kam schon des Öfteren vor, dass sich einige Hersteller über die Lizenzbedingungen der GPL hinwegsetzten und sich mit diesem Vorgehen Probleme einhandelten. In der Regel läuft ein Verstoß auf einen Vergleich hinaus, bei dem der Hersteller den Forderungen der Lizenz nachkommt und als Schadensersatz eine Spende an eine Open-Source-Vereinigung einleitet. Aus diesem Grund wird bei der PHP-Erweiterung HBCI4PHP ebenfalls die GPL- Lizenz gewählt. Dies wäre zwar nicht nötig wenn das Modul nicht veröffentlich wird, was aber geplant ist. 15

17 2.6 Hilfreiche Programme Abbildung 2.4: Das Wappentier des GNU-Projekts [4] 2.6 Hilfreiche Programme Debugger Ein Debugger ermöglicht es den Programmablauf zu studieren und auf diesem Weg Fehler besser nachzuvollziehen zu können. Es ist sogar möglich in den Programmablauf einzugreifen oder sich die aktuellen Werte von Variablen anzeigen zu lassen. Dazu setzt man sogenannte Breakpoints, an denen die Ausführung stoppt und Zugriff auf die aktuellen Inhalte ermöglicht. Da es sich bei HBCI4PHP nicht um ein eigenständiges Programm handelt sondern sehr viele C-Makros (definiert durch die Zend Engine) zum Einsatz kommen, kompiliert das Programm meist ohne Fehler, selbst wenn der Aufruf der Makros fehlerhaft ist. Dies macht sich dann erst beim Aufrufen der feherlhaften Funktion bemerktbar. Statt einer aussagekräftigen Meldung tritt ein Segmentation Fault auf, also ein Speicherzugriffsfehler. Um dem Fehlerteufel auf die Spur zu kommen kann man den verdächtigten Programmcode isolieren und ein ausführbares Programm ohne die Benutzung der PHP-Makros erstellen und möglichst die Werte der Variablen ausgeben, die in der Extension den Makros übergeben werden. Bei der Kompilierung bzw. der Ausführung zeigt sich dann schnell der Grund für den Speicherzugriffsfehler. Einfacher geht dies aber mit Hilfe eines Debuggers wie dem GNU GDB, welcher einen sogenannten Backtrace erzeugen kann. Dabei handelt es sich um eine Rückverfolgung der fehlerverursachenden Funktion bis hin zu Ausgabe der fehlerhaften Codezeile. Bis dieser Schritt jedoch getan werden kann muss ein Speicherabbild des PHP-Prozesses beim Absturz erstellt werden (Core Dump). Dieser Core Dump wird über den Debugger ausgeführt und anschließend ist es möglich den Backtrace durchzuführen. 16

18 2.7 Reflektion Dokumentation Der unbeliebteste Teil der Programmentwicklung ist für die meisten Informatiker die Erstellung der Dokumentation. Oft müssen dafür extra Dokumente erstellt werden, was vom eigentlichen Programmiervorgang erheblich ablenkt. Genau diesen Kritikpunkt greift Doxygen, das verbreiteste Open-Source-Dokumentationsprogramm, auf. Doxygen liest auf bestimmte Art und Weise formatierte Kommentare im Quellcode aus und erstellt ein gut strukturiertes Dokument. Das gebräuchlichste der vielen Ausgabeformate ist HTML, da dort durch die Verwendung von Hyperlinks sehr einfach bedienbare aber mächtige Dokumentationen entstehen. Wird beispielsweise ein eigener Datentyp definiert und eben solch ein Datentyp in der Signatur einer Funktion angegeben, erstellt Doxygen einen Link vom Parameter der Signatur zur Definition des Datentyps und man hat sofort einen Einblick um was es sich genau handelt. Sehr nützlich erweist sich Doxygen auch bei einer reinen Schnittstellendokumentation für externe Programmierer, da sehr schnell für den meist geringen Funktionsumfang einer API ein hilfreiches Dokument erstellt werden kann. 2.7 Reflektion Resultat Nach Abschluss der Arbeiten am Projekt HBCI4PHP steht eine funktionierende PHP-Erweiterung zur Verfügung, die es ermöglicht, Onlinebankingfunktionalitäten in PHP-Webanwendungen zu integrieren. Es werden alle nötigen Geschäftsvorfälle eingebaut die nötig waren, um das in Abschnitt formulierte Projektziel zu erreichen: Abrufen des Kontostandes Abrufen der Kontoumsätze Neue Überweisung starten Neue Lastschrift starten Daueraufträge abrufen Dauerauftrag hinzufügen Dauerauftrag löschen 17

19 2.7 Reflektion Da die Bank keine Unterstützung für periodische Lastschriften anbietet wurde diese Funktionalität mittels PHP und der eben genannten Funktionen nachgebildet. Mit diesem Funktionumfang war es möglich das neue Kundenverwaltungssystem mit einer direkten Anbindung an die Bank zu versorgen. Der in Abschnitt beschriebe Arbeitsablauf hat sich dadurch stark vereinfacht, da die redudante Eingabe von Daten und die Benutzung verschiedener Systeme entfällt Verbesserungsmöglichkeiten Es wäre vermessen anzunehmen, dass es sich bei der vorgestellen Lösung schon um das Non Plus Ultra handelt, denn wie bei jeder Software gibt es auch hier noch zahlreiche Verbesserungsmöglichkeiten. Eines der Hauptprobleme wird durch den im Abschnitt erwähnten langsamen Prozessor auf der Chipkarte verursacht. Jede Nachricht, die zwischen Bank und Webanwendung übertragen wird, muss vorher signiert und verschlüsselt werden. Dies führt dazu, dass der simple Abruf des aktuellen Kontostands mehrere Sekunden dauern kann. Für eine moderne Webanwendung ist diese Reaktionszeit zu langsam. Benutzer erwarten sofort reagierende Programme und im Falle einer zu langen Wartezeit kann es schnell passieren, dass der Anwender den aktuellen Vorgang, der gerade zur Hälfte ausgeführt ist, abbricht. Solche Situation sind schwer zu handhaben, vor allem wenn es sich um ein derart sensibles Thema handelt. Eine pragmatische Herangehensweise ist die interaktive Anwendung von der tatsächlichen Kommunikation zwischen Chipkarte und Bankserver zu entkoppeln. Da die dauerhafte Speicherung der Kontoumsätze und die Erstellung von Statistiken sowieso eine Datenbank voraussetzt geht man einen Schritt weiter und schreibt alle geplanten Geschäftsfälle darin nieder. Die Webapplikation kommuniziert bei dieser Lösung nur noch mit der schnellen Datenbank, wodurch keine große Latenzen entstehen. Die Bank erfährt von den geplanten Aktionen über ein regelmäßig ablaufendes Programm (Cronjob), welches die vom Benutzer angelegten Überweisungen, Lastschriften oder Daueraufträge aus der Datenbank extrahiert und dem Bankserver zuschickt. Beim Ablauf dieses Programms wartet kein Benutzer auf Ausgaben und Reaktionen, womit es sich um keine zeitkritische Anwendung mehr handelt. Um aber auch eine zeitnahe Ausführung der geplanten Banktransaktionen garantieren zu können bietet es sich an den Cronjob kurz vor der Buchung der Bank auszuführen (Banken verarbeiten Überweisungen in der Regel nicht sofort sondern auch nur in bestimmten Abständen, beispielsweise alle 2 Stunden). Somit ergibt sich keine Verzögerung für die Geldgeschäfte und auch Kontostand und Umsatzanzeige 18

20 2.7 Reflektion werden alle paar Stunden auf den aktuellen Stand gebracht. Eine andere Möglichkeit wäre der Wechsel des HBCI-Sicherheitsverfahren gewesen. Bisher wurde die sicherste Variante, die RSA-Chipkarte, benutzt (der private Schlüssel kann hierbei nicht ausgelesen werden, siehe Abschnitt 2.3.1). Eine Alternative dazu wäre die RSA Schlüsseldiskette. Natürlich würde keine Diskette zum Einsatz kommen, aber das grundlegende Prinzip dieses Verfahren ist die Generierung eines RSA-Schlüsselpaars mit Abspeicherung beider Schlüssel auf einem Speichermedium (wie einer Diskette, USB-Stick oder Festplatte). Dann könnte auch der Prozessor des Rechners auf das Geheimnis zugreifen und die Berechnungen wesentlich schneller durchführen. Die weiter oben beschrieben Latenzen bei in Anspruchnahme der Chipkarte wären damit beseitigt. Jedoch ist die Sicherheit nicht mehr in einem solchen Maße wie bei der RSA-Chipkarte gegeben. Trotz des eben beschriebenen Verzichts auf die Reduktion der Sicherheit gibt es an einer Stelle ein sicherheitstechnisches Problem - bei der PIN-Eingabe. Die intelligente Karte (daher auch der Name SmartCard) erlaubt das Durchführen von kryptografischen Funktionen erst nach der Freischaltung durch eine 5-stellige persönlichen Identifikationsnummer (PIN). In der derzeitigen Realisierung ist diese Nummer hart in das PHP Modul eincodiert, damit der Cronjob ohne Interaktion ablaufen kann. Ideal wäre eine Autorisierung mit der Gültigkeit einer Onlinebankingsitzung, doch selbst bei diesem Vorgehen müsste die PIN gespeichert werden (wenn auch nur für kurze Zeit). An dieser Anwendung sieht man sehr schön, dass immer ein Kompromiss zwischen Sicherheit und Benutzerbarkeit geschlossen werden muss. Es ist fast nie möglich beide Themen zufriedenstellend abzuhandeln Begangene Fehler Nicht nur bei großen Projekten wie dem LKW-Mautsystem der TollCollect GmbH passieren große Fehler, sondern auch in etwas überschaubareren Vorhaben wie dem Schreiben einer PHP-Erweiterung für Bankfunktionen. Erwähnenswert ist hier eindeutig die Wahl des falschen Entwicklungsmodells. Gerade beim evolutionären Prototyping wird oft das VHIT -Verfahren (Vom Hirn Ins Terminal) angewandt, bei dem die Planungsphase merklich zu kurz kommt. Dies resultiert einerseits in Funktionen, die zwar einwandfrei funktionieren, aber nicht für das Projekt verwendet werden können, weil eine bestimmte Anforderung nicht bedacht wurde. Andererseits besteht die Gefahr, dass sich eine schlechte Lösung eines Problems in das Programm einschleicht und es sehr viel Arbeit macht diese Fehler zu korrigieren. Im schlimmsten Fall werden diese suboptimalen Codezeilen durch 19