20070708e Leiros Giesecke und Devrient Chipkartensoftware

 Home | News | Hefte | Mediadaten | Online-Artikel | Kommentare | Trends | Wir-ueber-uns | Tipps | Impressum | CeBIT 2012

»manage it« als

E-Paper  5-6 2011
E-Paper  3-4 2011
E-Paper  1-2 2011
E-Paper  11-12 2010
E-Paper  9-10 2010
E-Paper  7-8 2010
E-Paper  5-6 2010
 

Giesecke & Devrient testet Chipkarten-Software

Sichere Karten-Software

Auch bei Chipkarten-Software nimmt die Komplexität zu. Um die Karten dennoch möglichst fehlerfrei zu halten, setzt Marktführer Giesecke & Devrient Modell-basierte Testverfahren ein. Dabei erzeugt der Test Designer automatisch Zehntausende von Test-Cases, so dass auch komplexe Software umfassend geprüft werden kann.

or der Öffentlichkeit eher weniger beachtet, haben auch Chipkarten in den letzten Jahren eine beachtliche Entwicklung vollzogen. Verfügten die ersten Karten nur über einen sehr kleinen Datenspeicher in Form eines Magnetstreifens, so sind ihre modernen Nachfolger mit Prozessor, Arbeitsspeicher, eigenem Betriebssystem und integrierter Kryptografie ausgestattete, vollständige Computer im Kleinstformat. Sie erreichen heute eine Rechenleistung, die etwa der eines Desktop-Computers vor 15 Jahre entspricht. Die Anwendungsmöglichkeiten dieser Technologie sind denn auch in den letzten Jahren geradezu explodiert: Neben den klassischen Karten für den bargeldlosen Zahlungsverkehr werden Chipkarten heute für ganz unterschiedliche Aufgaben eingesetzt, zum Beispiel als Ausweiskarten für die Personenidentifizierung, als SIM-Karten für Mobiltelefone, als Gesundheitskarte oder als Zugangsschlüssel fürs Pay-TV. Zusätzliche Einsatzgebiete erschließt die neue Technologie der Java-Karten; hier können nicht nur die Hersteller, sondern auch die Kartenemittenten Applikationen auf die Karten laden, was deren Flexibilität enorm erhöht.

Alle diese unterschiedlichen Aufgaben werden natürlich durch Software bereitgestellt. Sie ist im Speicher der Karten implementiert und wird in Verbindung mit den jeweiligen Host-Systemen, also beispielsweise einem Handy oder einem Kassenterminal, aktiviert. Es versteht sich von selbst, dass die Applikationen für Chipkarten in höchstem Maße sicherheitskritisch sind: Sowohl beim Bezahlen als auch bei der Zugangskontrolle könnte der Einsatz falsch programmierter Karten fatale Folgen haben.

Giesecke & Devrient (G&D), einer der weltweit führenden Hersteller, steuert die Entwicklung von Software für seine Chipkarten von den Treibern bis zu den Applikationen komplett in eigener Regie. Mehrere hundert Softwareentwickler sind beim Münchner Konzern damit befasst. Dabei unterscheidet sich die Entwicklung dieser Art von Software in einigen Punkten deutlich von »normaler« Softwareentwicklung. Das liegt zum einen an den technischen Voraussetzungen von Systemen, die »embedded« sind: »Wir müssen immer mit dem Speicher auskommen, den uns der Chip-Hersteller zur Verfügung stellt«, erläutert Markus Liegl, Leiter Software-Testing im Bereich Cards and Services, Basic Development bei G&D. »Wir können für aufwendige Applikationen nicht einfach mehr RAM oder größere Festplatten vorschreiben.«

Eine weitere Herausforderung für die Softwareentwicklung stellen die besonderen Sicherheitsanforderungen dar. Chipkarten müssen allen Arten von Angriffen standhalten, vom einfachen Abhören der Kommunikation zwischen Karte und Terminal, bis zum Manipulieren von Inhalten. Schließlich können für Chipkarten-Applikationen auch nicht die üblichen Verfahren der Softwarepflege angewandt werden. »Sind die Karten einmal ausgegeben, haben wir keinen Zugriff mehr«, führt Liegl dazu aus. »Wir können unsere Karten nicht nach einem halben Jahr zurückrufen, um beispielsweise Patches oder Bugfixes einzuspielen.« Außerdem befinden sich die Programme im ROM, lassen sich also nicht überschreiben. Nachbesserungen oder auch die üblichen Wartungszyklen sind hier ausgeschlossen. Auch nachträgliche Erweiterungen der Applikationen in Form von Updates sind für den Kartenhersteller kaum möglich, so dass auch die Spezifikation der Anforderungen sehr gründlich, genau und weit vorausschauend erfolgen muss.

Hoher Testaufwand

Die Besonderheiten der Kartensoftware stellen natürlich enorme Anforderungen an die Softwarequalität. »Software, die unser Haus verlässt, muss fehlerfrei sein«, erklärt Liegl. »Der Entwicklungsaufwand ist hier deutlich höher als es sonst üblich ist, und die Entwicklungsdauer ist dementsprechend länger.« G&D hat schon vor Jahren ein ausgefeiltes Qualitätssicherungssystem für seine Softwareentwicklung aufgebaut, in dessen Kern ein umfassendes Test-Management mit Systemtests, Komponenten-Tests, Reviews, Checklisten usw. steht. Dabei wird nicht nur nach Fehler oder Ungenauigkeiten in der Programmierung gesucht, sondern auch geprüft, ob die Chips die Spezifikation tatsächlich einhalten oder ob es Fehler in den Tools gibt, beispielsweise im Compiler.

Organisatorisch hat G&D die Softwareentwicklung und das Testen streng getrennt, dafür sind zwei verschiedene Abteilungen zuständig. Im Entwicklungsprozess beginnt das Testen frühzeitig, Test-Cases werden schon während des Entwicklungs-Zyklus aufgebaut, nicht erst bei Code-Freeze. Die Test-Ingenieure leiten aus den Requirements geeignete Testfälle ab, die am Ende des Zyklus auf die Software angewandt werden. Solche Test-Läufe sind äußerst umfangreich, erstrecken sich über mehrere Tage und umfassen mehrere 10.000 Test-Cases.

Mit der Komplexität der Systeme ist auch die Komplexität der Tests in den letzten Jahren deutlich gestiegen. Wo es bis vor wenigen Jahren geschlossene Produkte mit Betriebssystem und Anwendung gab, die nach außen nur über eine Kommandoschnittstelle kommunizierten, gibt es heute Karten, die über eine Programmierschnittstelle verfügen, auf die der Kunde aufsetzen und ausführbaren Code laden kann. Diese Technologie stellt besonders hohe Anforderungen an die Test-Verfahren: »Wir wissen ja nicht, was der Kunde programmiert, und müssen davon ausgehen, dass er alles ausprobiert, was technisch möglich ist«, erläutert Liegl. »Wir müssen alle Möglichkeiten vorhersehen und prüfen, wie sich das Produkt verhält. Und egal welche Programme auf die Karte geladen werden – die Sicherheit der Karte darf unter keinen Umständen davon tangiert werden.«

Steigende Komplexität der Chipkarten-Software

Mit steigender Komplexität der Software steigt der Testaufwand überproportional, so dass für bestimmte Funktionalitäten manuelle Tests zu aufwendig werden. Begrenzt man aber den Aufwand, so reduziert sich die Requirements-Coverage, und die Softwarequalität sinkt. Bei steigender Komplexität und gleichem Aufwand lässt sich eine gleichbleibende Test-Coverage nur durch Automatisierung des Testens erreichen. Das Modell-basierte Testen (MBT), wie es von Leirios unterstützt wird, zählt hier zu den viel versprechenden Ansätzen. Der Leirios Test Designer generiert Test-Scripte und Test-Cases direkt aus standardisierten Modellen. »Für uns stellt das Modell-basierte Testen einen guten Ansatz dar«, sagt Liegl. »Damit können wir die erforderliche Coverage trotz immer aufwendigerer Produkte halten. Wir versuchen daher heute bei Aufgabenstellungen, die sich dafür eignen, modellbasiert vorzugehen. Vor allem bei Problemstellungen, die sich logisch auf eine State-Machine abbilden lassen, haben wir gute Ergebnisse erzielt.«

Seit dem ersten Pilotprojekt, das 2004 gestartet wurde, setzte G&D das MBT mit dem Leirios Test Designer Zug um Zug in unterschiedlichen Projekten ein. Die Modellierung der Testszenarien erfolgt in diesem Fall mit der Modellierungssprache B; die Testumgebung wurde von G&D selbst entwickelt, weil sich die gängigen Marktprodukte kaum für Embedded Software eigneten. Modellierung, Case-Generierung und Testdurchführung sind eng ineinander verzahnt, so dass der gesamte Prozess in hohem Grad automatisiert abläuft. »Wir können damit sehr viele Fälle und Fallkombinationen ausprobieren«, sagt Liegl. »Auch Erstellung von mehreren 10.000 Fällen sind mit dem Leirios Test Designer kein Problem mehr. Manuell wäre das bei den heutigen Entwicklungszeiten nicht machbar.«

Auch bei der Weiterentwicklung von Lösungen kann das MBT seine Vorzüge ausspielen: Sind Modelle bereits vorhanden, so lassen sich neue oder geänderte Anforderungen sehr leicht einarbeiten. Die Tester müssen nicht Hunderte von Tests durcharbeiten und prüfen, wo sich die Änderungen auswirken, sondern ändern das Modell und überlassen es dem Test Generator, die entsprechend veränderten Test-Cases auszuarbeiten.

Technisch wäre es möglich, mit MBT noch einen Schritt weiter zu gehen und die Test-Modelle direkt aus den in UML formulierten Entwicklungsmodellen abzuleiten. Der Leirios Test Designer würde diese Möglichkeit zwar unterstützen, aber Liegl sieht hier methodische Probleme: »Dieses Vorgehen würde nach unserer Auffassung gegen das Vier-Augen-Prinzip verstoßen. Damit könnte man zwar Arbeit sparen, könnte aber dann nur noch solche Fehler finden, die in den Schichten unterhalb des Modells angesiedelt sind. Fehler, die beispielsweise schon in der Spezifikation enthalten sind, ließen sich so kaum noch entdecken.«

Aber auch ohne dieses Feature stellt das MBT für die Tester von G&D eine Möglichkeit dar, die Testqualität trotz steigender Komplexität der Software auf hohem Niveau zu halten. Noch vor wenigen Jahren waren automatisierte Tests für Chipkarten nicht notwendig. Heute geht es vor allem darum, den erreichten hohen Standard zu halten. »Wir kommen mit unseren Karten in einen Bereich, in dem es immer schwieriger wird, sehr nahe an der 100-prozentigen Fehlerfreiheit zu bleiben«, resümiert Liegl. »Die Qualität der Produkte darf nicht sinken, aber die Kosten der Qualitätssicherung müssen natürlich auch begrenzt bleiben. MBT stellt uns eine Methode zur Verfügung, mit der wir dieses Dilemma überwinden können.«

Rainer Doh

Folgen Sie »manage it«

auf Google+

Copyright © 2003-2012  ap Verlag GmbH