Trust, Dependability and Security in Electronic Payment Systems Klaus P. Jantke, Principal Researcher & Project Coordinator FairPay, DFKI

Transkript

1 pp of the Conference Documentation [ see bibliographic data at the end of this file ] Trust, Dependability and Security in Electronic Payment Systems Klaus P. Jantke, Principal Researcher & Project Coordinator FairPay, DFKI Abstract--Users of distributed systems depending on open networks like the Internet would like to keep their private data private, would like to be sure that their money sent through the network is reaching its destination, and so on but the growth of e-commerce does not meet the high expectations and promises. A majority of potential users does not trust in the services offered. We do need trust, but we do need trust that depends on truly secure systems. Dependability is the crux in e-business, e-commerce, and e-governement. There has been set up a concerted activity named FairPay towards dependability of electronic payment systems. Methodologies are developed to make currently invented and, especially, future and therefore unforeseeable e-payment solutions dependable. But the reach goes far beyond electronic payment. The methodology does apply to communication in open networks, in general. There are successful applications proving the strength of the approach and its usefulness in a large variety of application areas. The key idea is to invoke formal methods whenever possible, to speak about security logically, to characterize vulnerabilities in formal terms, to state security requirements as clearly as possible and whenever there is any hope to succeed to prove a system s security logically. This presentation is aims at an illustration of the logical approach. Index Terms--Security, Dependability, Trust, Electronic Payment, Payment Protocols, e- Business, e-commerce, e-government, m-commerce, Formal Specification, Evaluation, Verification, Automated Deduction. I I. PREFACE TO THE ENGLISH-SPEAKING AUDIENCE have been asked to give a presentation at this World Congress I have been asked in German and have given my answer including an intended title of my talk in German, as I m used to in those cases. Thus, the presentation title Sicherheit im elektronischen Zahlungsverkehr, which means Security in Electronic Payment Systems, entered the conference program. Even now, when writing this text, I do not properly know whether I should give this presentation in English (more precisely: what I consider to be English) or in German. Let s see or, more precisely again, let s hear at the conference. Under these circumstances, it is not easy to decide about a written version of the presentation. Having no better criterion available, I ve chosen efficiency of type-writing and selected German, accordingly. However, the title had to be generalized in any case. The focus of the presentation will be on a wider spectrum ranging from less formal issues like trust through intermediate concepts like dependability to more formally based issues like security. The ultimate goal of the presentation is to propagate the importance of formal method and automated reasoning, wherever possible and affordable. In fact, electronic payment systems form the focus of the underlying project FAIRPAY reported here, but reach of the methodology discussed is much larger. In fact, the present paper is intended to illustrate the generality of the overall approach mostly by means of an intuitive example.

2 II. DAS FORSCHUNGS- UND ENTWICKLUNGSPROJEKT FAIRPAY FAIRPAY ist ein Forschungs- und Entwicklungsprojekt mit einer Laufzeit von 2 Jahren und einem Volumen von etwa 20 Mio. DM. Mit etwa der Hälfte dieser Mittel wird FAIRPAY durch das Bundesministerium für Wirtschaft und Technologie (kurz: BMWi) gefördert. An FAIRPAY arbeiten unter der Konsortialführerschaft des DFKI zwei Banken, vier Software-Häuser und 4 universitäre Forschungsgruppen zusammen. Es kann davon ausgegangen werden, daß der im Konferenzablauf diesem vorangehende Beitrag von Jörg Siekmann weitere Information über FAIRPAY vermittelt, so daß hier ein paar Bemerkungen genügen sollen. Was FAIRPAY eigentlich ist, erfährt man von Siekmann, und es ist mit wenigen Worten schon zu Beginn dieses Abschnitts gesagt worden. Außerdem kann der Leser auf [4] und [5] verwiesen werden. Aber was soll FAIRPAY, was macht FAIRPAY? An dieser Stelle werden ein paar bereits in [4] gegebene Antworten wiederholt. A. Was soll FAIRPAY? Die wirtschaftlichen Chancen für den e-commerce sind enorm, da sich nahezu grenzenlose Märkte erschließen, keine beschränkten Geschäftszeiten mehr existieren und die Möglichkeiten der modernen Informationstechnologien für flexible, kundengerechte Angebote ständig weiter ausgebaut werden. Dies hängt natürlich essentiell daran, sich in offenen Netzwerken zu bewegen, in denen man dem Wesen der Sache nach seine Partner nicht kennen kann und von vornherein niemanden ausschließen will. Der elektronische Geschäftsverkehr setzt sich durch, wobei jedoch die Geschwindigkeit dieses Prozesses von der Akzeptanz durch die Kunden abhängt. Ein entscheidendes Akzeptanzkriterium ist dabei das Vertrauen, vor allem in finanzielle Transaktionen. Da offene Netzwerke auf die man aber in keinem Fall verzichten möchte (s.o.) ihrem Wesen nach angreifbar sind, bedarf es erheblicher Anstrengungen, den sogenannten elektronischen Geschäftsverkehr im allgemeinen und den elektronischen Zahlungsverkehr im besonderen abzusichern, wenn schließlich der Schritt aus den bisherigen proprietären Netzen in das Internet vollzogen werden soll. Dies zu erreichen, ist nicht nur von wissenschaftlich-technischem oder von geschäftlichem Interesse, sondern eine Aufgabe der wissenschaftlich-technischen Kriminalprävention mit grenzüberschreitender Bedeutung. B. Was macht FAIRPAY? In FAIRPAY geht es um die Zuverlässigkeit von Systemen, die in offenen Netzwerken funktionieren müssen. Um die Untersuchungen und Entwicklungen konzentrieren zu können, wurden die Arbeiten in FairPay auf den Zahlungsverkehr fokussiert. Wenn von Zuverlässigkeit die Rede ist, dann (i) von faktischer Zuverlässigkeit und (ii) von nachweislicher Zuverlässigkeit. Durch diese feine Differenzierung soll darauf hingewiesen werden, daß Vertrauen als Basis eines aufblühenden Geschäftsverkehrs nicht allein durch faktische Zuverlässigkeit gewonnen werden kann, wenn diese auch im Zentrum aller hier dargestellten Bemühungen steht, sondern daß es ganz ausdrücklich darauf ankommt, die Zuverlässigkeit von Systemen überprüfen und kommunizieren zu können.

3 Ausgangspunkt des DFKI als Konsortialführer in FairPay sind daher die Ansprüche, denen man gerecht werden muß, will man die Zuverlässigkeit eines IT-Systems nach international anerkannten Kriterien (wie ITSEC, vgl. [9], und Common Criteria, vgl. [8]) evaluieren und ggf. sogar zertifiziert bekommen. In [1] wird diese Herangehensweise im Detail diskutiert. Nehmen wir die Common Criteria for IT Security Evaluation [8] zum Maßstab. Eine Evaluierung nach den hohen Vertrauenswürdigkeitsstufen (das sind die Stufen EAL 5 bis EAL 7, die etwa den Stufen E 4 bis E 6 der Information Technology Security Evaluation Criteria, siehe [9], entsprechen) erfordert in recht klar spezifiziertem Umfang den Einsatz von semiformalen bzw. formalen Methoden und Analysen. In [6] und [7] wird prototypisch demonstriert, wie man das beispielsweise für Signaturkarten zum Einsatz bringen kann. Das DFKI bringt in FAIRPAY u.a. das Verification Support Environment VSE-II einschließlich der VSE zugrunde liegenden Methoden ein (vgl. [2]). Auf der Basis dieser Methoden und unterstützt durch das Werkzeug VSE-II können formale Methoden bei der Entwicklung und entwicklungsbegleitenden Verifikation von komplexen Systemen für den e-commerce zum Einsatz kommen, um zuverlässige Lösungen anzubieten und darüber hinaus diese Systemlösungen nach den hohen Vertrauenswürdigkeitstufen von ITSEC oder CC zertifizieren zu können. Nachweise der Zuverlässigkeit eines Systems können kommuniziert werden, um sachlich berechtigtes Vertrauen zu erwerben. III. WISSENSTRANSFER AUS FAIRPAY DIE BESONDERHEITEN DIESES BEITRAGS Dieser Beitrag muß kurz sein und soll ein unvorhersehbar breites Auditorium mit zum Teil innovativen Erkenntnissen versorgen wieder mal eine unlösbare Aufgabe. Wie hoffnungslos es ist, sie in Angriff zu nehmen, sagt mir folgende Erfahrung: Anfang dieses Jahres habe ich auf einer großen Tagung einen Vortrag zum Thema Sicherheit von e-business und e-payment gehalten und mich bemüht, sozusagen mit Händen und Füßen, und natürlich mit einigen wohlüberlegten umgangssprachlichen Umschreibungen, die komplizierten Sachverhalte, die hinter nachweislicher Zuverlässigkeit von IT-Systemen stecken, verständlich zu machen. Ich würde sagen, dies war der informellste Vortrag, den ich jemals gehalten habe. Der Vortrag wurde gut aufgenommen, es gab eine interessierte Diskussion, und in der sich anschließenden Kaffeepause hörte ich ein kurzes Gespräch von zwei Tagungsteilnehmern über meinen Vortrag, in dem die Worte vielen: sehr interessant, aber sehr abstrakt. Was ist da nur zu tun, wenn wir doch wirklich die Essenz der Arbeiten in FairPay und deren Reichweite einem breiten Auditorium vermitteln wollen?! Es geht doch darum, diejenigen zu erreichen, welche die kritischen Entscheidungen treffen. In diesem Beitrag soll ein spezieller Zugang versucht werden, der darin besteht, im Vortrag ein einziges großes Beispiel zu präsentieren, das deutlich macht, wie man mit den Methoden und mit den Werkzeugen von FairPay Systemeigenschaften nachweisen kann, um so zu gerechtfertigtem Vertrauen zu gelangen, wobei der Ansatz gar nicht auf e-payment beschränkt ist. Die Grundlagen für das Beispiel werden im Folgenden gelegt.

4 IV. FORMALE METHODEN FÜR DIE MODELLIERUNG UND DIE ANALYSE Anhand eines Beispiels soll ohne besondere Vorkenntnisse bemühen zu müssen verdeutlicht werden, welche Methodologie in diesem Beitrag propagiert wird und was sie zu leisten in der Lage ist. Das Beispiel wurde bewußt so gewählt, daß es jedem Leser und Hörer des zugehörigen Konferenzvortrags leicht fallen sollte zu folgen; Praxisrelevanz des Beispiels, das übrigens für Mathematiker Folklore darstellen dürfte, wird nicht fokussiert. Stellen wir uns vor, wir hätten das Problem, eine gerasterte Fläche mit Dominosteinen auszulegen, wobei wir es uns ersparen wollen, die Steine auch noch passend (in bezug auf die üblicherweise auf Dominosteinen abgebildeten Zahlen) zusammenzulegen. Es soll uns genügen, die Ebene zu bedecken. Ob und wie das geht, hängt offenbar von der Gestalt der Fläche ab und natürlich auch noch davon, ob wir über genügend viele Steine verfügen. Betrachten wir eine Fläche wie diese: Abb. 1: Die zugrunde liegende Datenstruktur Wir wollen in der Lage sein, das Problem, wenn irgend möglich, im vorliegenden Fall zu lösen, aber natürlich wollen wir nicht selbst das tun; ein Computerprogramm soll sich damit herumschlagen. Und dieses Programm soll auch dann dazu in der Lage sein, wenn das Feld noch ein bißchen größer ist und wir demzufolge noch weniger Lust verspüren, diese stupide Aufgabe von Hand zu lösen. Genau dazu sind ja Computer da.

5 Wir haben Dominosteine zur Verfügung, die zur Illustration so wie hier rechts dargestellt werden sollen. Wollte man von Hand beginnen, eine Überdeckung der gegebenen Fläche vorzunehmen, dann könnte das etwa wie folgt aussehen: ABB. 2: EINE PARTIELLE LÖSUNG Aber wie gesagt wir wollen das ja gar nicht von Hand versuchen. Wir wollen ein Programm in Auftrag geben, dieses Programm schließlich bekommen und uns darauf verlassen können, daß es zuverlässig ist und genau das tut, was wir brauchen. Was hat dieses Beispiel nun eigentlich mit der Fragestellung des vorliegenden Beitrags über Verläßlichkeit von IT-Systemen zu tun? Wenn von Verläßlichkeit oder gar von Sicherheit die Rede ist, dann meint man je nach Anwendungsgebiet bestimmte Eigenschaften. Im e-business und e-commerce, im allgemeinen, und im elektronischen Zahlungsverkehr, im besonderen, geht es im wesentlichen um solche Eigenschaften wie Integrität, Vertraulichkeit, Authentizität und Verbindlichkeit. Man möchte beispielsweise sichern, daß Daten bei der Übertragung nicht verändert werden können, oder man möchte sicherstellen, daß der Sender einer Nachricht auch eindeutig identifizierbar ist. Diese Zuverlässigkeitsziele werden im allgemeinen durch das Zusammenwirken unterschiedlicher Systemeigenschaften sichergestellt. Dazu kann zum Beispiel gehören, daß eine Dekodierungsaufgabe so kompliziert ist, daß sie nach menschlichem Ermessen nicht gelöst werden kann, oder daß eine SmartCard für die digitale Unterschrift definitiv nach

6 drei falschen PIN-Eingaben gesperrt ist. Will man sich von der Zuverlässigkeit eines IT-Systems überzeugen, kommt man nicht umhin, sich davon zu überzeugen, daß solche kleinen Eigenschaften auch wirklich vorhanden sind. Dabei kommt es sehr genau darauf, was man wirklich will. Am besten, man sagt es einmal so logisch wie möglich. Das hat seine Grenzen, denn es ist ja bekanntlich so, daß bestimmte Sicherheitseigenschaften eigentlich darauf beruhen, daß bestimmte Probleme bislang ungelöst sind. Verschlüsselungen nach dem RSA-Verfahren, beispielsweise, beruhen darauf, daß es sehr schwierig ist, große natürliche Zahlen in ihre Primfaktoren zu zerlegen. Das ist natürlich prinzipiell möglich, und ein Angreifer kann auch Glück haben und zufällig die richtigen Primfaktoren raten. Wir können niemals beweisen, daß dies nicht doch einmal eintreten könnte. Aber man kennt eben zumindest gegenwärtig kein effizientes Verfahren für diese Faktorisierung. Sicherheit ist in bezug darauf also immer nur relativ. Wovon man sich überzeugen kann, ist daß die Frage nach der effizienten Faktorisierung von natürlichen Zahlen nach wie vor als ungelöst gilt. Lassen wir die ungelösten Probleme beiseite und fragen wir uns lieber, ob es nicht auch Fragen der IT-Sicherheit gibt, die man definitiv und verbindlich beantworten kann. Die Herangehensweise ist wie folgt: Bedrohungsanalyse: Man erörtert mit Fachleuten die Bedrohungen des Systems und systematisiert mögliche Angriffe. Die Analyse wird zunächst umgangssprachlich gefaßt, dann aber so weit formalisiert, daß sie erlaubt, den Bedrohungen klare Sicherheitsziele entgegenzusetzen. Erarbeitung von Sicherheitsfunktionen: Eine Sicherheitspolitik ist eine Gesamtheit von Sicherheitsfunktionen zur Erreichung der den Bedrohungen gegenübergestellten Sicherheitsziele. Einzelne Sicherheitsfunktionen werden so weit formal beschrieben, daß es möglich wird, mit der Präzision mathematischer Logik zu fragen, ob ein gegebenes System eine Sicherheitsfunktion realisiert oder nicht. Erfassung relevanter Systemeigenschaften: Sobald eine Sicherheitsfunktion als logische Aussage präzisiert worden ist, steht die Frage, ob ein System diese Eigenschaft nun auch besitzt, ob sie im logischen Sinne gültig ist. Dazu muß man über Systemeigenschaften mit derselben Präzision reden können. Solche Systemeigenschaften, die für den Nachweis einer Sicherheitseigenschaft relevant sein können, werden formalisiert. Computergestützter Nachweis vorhandener Sicherheitseigenschaften: Auf der Basis formaler Systemeigenschaften und formaler Sicherheitsfunktionen steht man vor einem Beweisproblem: Implizieren die Systemeigenschaften die Sicherheitsfunktion? Mit Computerprogrammen, die logische Beweise führen können, nimmt man diese Frage in Angriff. Es ist offenbar, daß man in realistischen Fällen damit rechnen muß, diese Schritte in mehreren Zyklen zu bearbeiten, denn Formalisierungen können sich als ungeeignet erweisen. Es kann sich ja auch zeigen, daß eine bestimmte Sicherheitseigenschaft gar nicht vorhanden und damit auch gar nicht beweisbar ist. Gegebenenfalls hilft eine Revision der Sicherheitspolitik. Aus der Vielzahl der Aspekte, die man hier noch vertiefen könnte, sollen nur zwei

7 ausgewählt werden. Erstens wird in [1], [2], [3], [4], [5], [6] und [7] davon ausgegangen, daß eine Herangehensweise wie die oben geschilderte bereits in frühen Phasen des Systementwurfs praktiziert wird, um rechtzeitig die Weichen für die Zuverlässigkeit eines IT-Systems zu stellen und Design-Fehler zu vermeiden, die später nur mit großem Aufwand behoben werden könnten. Systematische Bedrohungsanalysen, Formulierung von Sicherheitszielen und funktionen, Abbildung von sicherheitsrelevanten Systemeigenschaften und Sicherheitsnachweise müssen entwicklungsbegleitend erfolgen. Die in [6] und [7] diskutierte Fallstudie eines SmartCard-Entwurfs illustriert die Wichtigkeit dieser Herangehensweise. Zweitens sind logische Beweise komplizierter Sicherheitsfunktionen an sich wiederum eine recht komplizierte Angelegenheit wie man sich allein anhand mathematischer Forschung vorstellen kann. Wenn Beweise nicht erfolgreich sind, kann das viele Ursachen haben. Man muß also die Beweismethoden ständig vervollkommnen, muß Taktiken ausarbeiten und erproben und braucht geeignete Werkzeuge (vgl. [2]). Doch zurück zu unserem einführenden Beispiel. Dieses soll uns helfen besser zu sehen, was vor sich geht, wenn man Systemeigenschaften logisch beweisen will. Es soll dazu beitragen, die Reichweite des hier vorgelegten Ansatzes exemplarisch zu erfassen. In unserem Beispiel ist das Ziel, welches vom System realisiert werden soll, nämlich die gesamte gegebene Fläche zu bedecken, nicht gerade eine Sicherheitsfunktion, aber das ist der Logik ja gleichgültig. Eine erste Überlegung ist offenbar: Unsere Fläche entsteht durch Modifikation eines Quadrats, nämlich durch Herausschneiden zweier Eckfelder. Falls die Seitenlänge des Quadrats ungerade ist, hat unsere Fläche ungeradzahlig viele Einzelfelder. Dann kann man sie sowieso nicht mit Dominosteinen bedecken, weil jeder Stein 2 Felder bedeckt. Also fordern wir von Anfang an, daß das zugrunde liegende Quadrat eine geradzahlige Kantenlänge n hat. Ob nun ein Computerprogramm die ihm gestellte Aufgabe immer richtig löst, kann man nicht durch Probieren auf ein paar Beispielfeldern zu gerader Kantenlänge n herausbekommen. Daß das Programm zum Beispiel für n=998 ordentlich arbeitet, garantiert uns noch lange nicht, daß es das auch für n=1000 tut. Man erkennt die substantiellen Grenzen des Testens. Für sicherheitskritische Systemeigenschaften ist Testen keine adäquate Methode der Validation (vgl. [3]). Wir wollen aber nachweisliche Systemsicherheit. Bevor wir untersuchen können, und zwar mit logischen Mitteln, wie oben skizziert, ob ein bestimmtes Computerprogramm die geforderte Eigenschaft hat, eine von uns vorgegebene Fläche der geradzahligen Kantenlänge n (mit herausgeschnittenen Ecken wie in Abbildung 1) mit Dominosteinen ordnungsgemäß zu bedecken, ist es sinnvoll, sich ein paar Notationen zu überlegen. Die einzelnen Felder unserer Fläche bezeichnen wir mit (i,j), wobei i und j zwischen 1 und n variieren können. Die Felder (1,1) und (n,n) werden ausgeschlossen. Um über die Farbe der Felder sprechen zu können, nehmen wir eine Menge {s,w} her, deren Elemente die Farben Schwarz und Weiß bezeichnen sollen. Eine Funktion f ordnet Feldern Farben zu, also z.b. f(2,3)=w. Wenn zwei Felder

8 (r,s) und (u,v) von einem Dominostein bedeckt sind, schreiben wird d((r,s),(u,v)). Man kann d im logischen Sinn als Prädikat auffassen. Sind die beiden Felder bedeckt, dann trifft d((r,s),(u,v)) eben zu, andernfalls nicht. Formulieren wir unser Ziel: Jedes Feld unserer Fläche soll bedeckt sein, und zwar ordentlich, so daß Dominosteine sich nicht überlappen können. Für eine logische Untersuchung ist diese Formulierung noch nicht geeignet. Wir müssen uns schon der Mühe der Formalisierung unterziehen: r,s: (r,s) (1,1) (r,s) (n,n) ( u,v: d((r,s),(u,v)) d((u,v),(r,s)) ) und r,s,u,v,x,y: ( d((r,s),(u,v)) d((r,s),(x,y)) u=x v=y ) ( d((u,v),(r,s)) d((x,y),(r,s)) u=x v=y ) Ob ein Programm uns dieses Ergebnis liefern kann oder nicht, ist noch schwer zu sehen. Wir müssen noch eine Menge Grundwissen heranholen. Noch zwei Beispiele sollen hier dem Leser Anregungen zur Analyse geben, wobei wir annehmen, daß es noch zwei weitere Prädikate even und odd gibt, die genau dann zutreffen, wenn natürliche Zahlen gerade bzw. ungerade sind. r,s: r,s,t: ( f(r,s)=s even(r+s) ) ( f(r,s)=w odd(r+s) ) d((r,s),((r,t)) s=t+1 s+1=t Im weiteren Text wollen wir auf Formeln dieser Art verzichten. Es genügt uns, Gewißheit darüber zu haben, daß es möglich ist, Systemeigenschaften und Ziele eben auch Sicherheitsfunktionen eines Systems mit logischer Präzision ausdrücken zu können. Nun geht es uns um die Reichweite des Ansatzes, Computer zum Beweisen von Systemeigenschaften heranzuziehen. Lassen wir doch, wann immer es irgend möglich ist, Computer für uns über Zuverlässigkeit und Sicherheit nachdenken! In unserem Beispiel würde dies ein Ergebnis des automatisierten Nachdenkens sein: Wenn die Fläche vollständig bedeckt ist, müssen ungeradzahlig viele Dominosteine verwendet worden sein. Na und, wird man fragen, was soll ich damit anfangen? Ja, das kommt vor. Nicht jede Erkenntnis, die uns ein automatischer Beweis liefert, ist brauchbar. Aber da wäre dann noch ein Ergebnis: Wenn die Fläche vollständig bedeckt ist, sind genau so viele schwarze wie weiße Felder bedeckt. Wieder könnte man fragen: Na und...? Aber da ist noch ein weiteres Ergebnis, das uns unser Beweiser liefern kann: Die Anzahl der weißen Feldern in der Fläche ist um 2 größer als die Anzahl der schwarzen Felder. Wow! Jetzt wissen wir, daß unser Problem sogar unlösbar ist, egal wie groß n ist,

9 denn die beiden zuletzt bewiesenen Ergebnisse schließen eine korrekte Lösung aus! Mit einem System wie VSE (vgl. [2]) kann man obige Ergebnisse erzielen. Auf solchen Methoden und Werkzeugen beruht FairPay. Der Ansatz erlaubt wie eben illustriert einschneidende Einsichten in Problemstellungen und Systemeigenschaften zu erlangen, die vollkommen jenseits dessen liegen, was man durch Testen erreichen kann. Auf diese Einsicht zielte unser zugegebenermaßen recht triviales Beispiel. Mit anderen Worten: Formale Methoden, die darauf beruhen, Systemeigenschaften und Sicherheitsfunktionen formal zu beschreiben und das Erreichen von Sicherheitszielen mit logisch verbriefter Sicherheit nachzuweisen, stellen den ultimativen Weg zu zuverlässigen Systemen dar. Sie können qualitative Einsichten liefern, die jenseits der prinzipiellen Grenzen herkömmlicher Systemtests liegen. V. DAS SPANNUNGSFELD VON VERTRAUEN UND NACHGEWIESENER SICHERHEIT Sicherheit nachzuweisen, und zwar mit logischen Mitteln, ist prinzipiell möglich. Aber das allein genügt nicht. Es müssen, damit verbunden, Wege gefunden werden, die objektive Sicherheit subjektiv erfaßbar zu machen. Umgekehrt sollte natürlich nur Vertrauen in wirklich zuverlässige Systeme aufgebaut werden. Das Erzielen objektiver Zuverlässigkeit ist der harte Kern in einem Ensemble von Aktivitäten auf dem Weg zu Trust, Dependability and Security im elektronischen Zahlungsverkehr, im besonderen, und in e-business und e-commerce, im allgemeinen. VI. KONSEQUENZEN FÜR DAS MANAGEMENT UND FÜR DIE SYSTEMENTWICKLUNG Die Bemühungen um einen qualitativen Fortschritt bei subjektiv empfundener und objektiv gegebener Sicherheit im e-commerce verlangen ein breites Spektrum von Maßnahmen. Die erste und entscheidende Einsicht muß sein, den formalen Methoden in der Systementwicklung und im Nachweis von Systemsicherheit den Platz einzuräumen, der ihnen gebührt und den sie ausfüllen können. Formale Methoden bei der Problemanalyse und bei der Systembeschreibung zu fordern und logische Sicherheitsnachweise zu einem festen Bestandteil des Qualitätsmanagements zu machen, ist eine Leitungsentscheidung. Formale Methoden müssen entwicklungsbegleitend eingesetzt werden, beginnend beim sogenannten High Level Design. Eine entsprechende Kultur muß etabliert werden; es gibt keinen anderen Weg zu nachweislicher IT-Sicherheit. Formale Methoden der Systementwicklung gepaart mit logischen Methoden zum Nachweis von Systemeigenschaften müssen zur Routine werden, so wie in anderen ingenieurtechnischen Bereichen sehr formale Methoden und Werkzeuge mit großer Selbstverständlichkeit angewendet werden. Als illustratives Beispiel mag das Gebiet der Differentialrechnung in der Statik dienen Zu diesem Gesamtprozeß müssen auch Forschung und Entwicklung ihren Beitrag leisten, durch eine Vertiefung der theoretischen Grundlagen, durch den Ausbau und die Vervollkommnung solcher Werkzeuge wie VSE-II (vgl. [2]), durch prototypische Anwendungen, die den Erfolge der Herangehensweise propagieren (vgl. [6] und [7]), sowie durch konzertierte Aktionen wie FairPay.

10 VII. FAIRPAY-BEZOGENE REFERENZEN Das Gebiet ist zu umfangreich und zu dynamisch, als daß sich hier die Mühe einer Bibliographie lohnen würde. Was man heute schreibt, müßte man schon morgen aktualisieren. Statt dessen sollen den Lesern Referenzen mit Bezug zu den Arbeiten in FAIRPAY angeboten werden. Wer sich für dieses Projekt, für die ihm zugrunde liegenden Methoden und Theorien sowie für die Gedankengänge des vorliegenden Beitrags interessiert, kann dort weitere Information finden, die von illustrierenden Beispielen zu tiefliegenden theoretischen Untersuchungen reicht. Ergänzt wird die Liste durch die beiden internationalen Kriterienwerke Common Criteria bzw. ITSEC, ohne die man sich in den hier präsentierten Ansatz von FairPay nur schwer hineindenken kann. VIII. LITERATUR [1] M. Auerswald, "Common Criteria for IT Security Evaluation Ausgangspunkt für Zuverlässigkeit im E- Commerce", in Proc. WIWITA 2000, 2. Wismarer Wirtschaftsinformatik-Tage, 15./ , pp [2] D. Hutter, G. Rock, J.H. Siekmann, W. Stephan and R. Vogt, Formal software development in the verification support environment (VSE), in Proc Thirteenth International Artificial Intelligence Research Society Conference, Orlando, FL, USA, May 2000, AAAI Press, pp [3] K.P. Jantke and O. Keller, "Secure Systems Development The Evolving Integration of Validation and Verification", in Proc Fourteenth International Artificial Intelligence Research Society Conference, Key West, FL, USA, May 2001, AAAI Press, pp [4] K.P. Jantke, W. Stephan und R. Vogt, FairPay: Mit formalen Methoden zu zuverlässigen Systemen für den elektronischen Zahlungsverkehr, in Proc. WIWITA 2000, 2. Wismarer Wirtschaftsinformatik-Tage, 15./16. Juni 2000, pp [5] K.P. Jantke and R. Vogt, FairPay Towards a Methodology for Provably Dependable Systems in e- Commerce, in Proc. 45th International Scientific Colloquium, Ilmenau Technical University, Ilmenau, Germany, October 2000, pp [6] B. Langenstein und R. Vogt, Normative für Zuverlässigkeit von SmartCards mit Digitalen Unterschriften, in Proc. WIWITA 2000, 2. Wismarer Wirtschaftsinformatik-Tage, 15./16. Juni 2000, pp [7] B. Langenstein, R. Vogt and M. Ullmann, The Use of Formal Methods for Trusted Digital Signature Devices, in Proc Thirteenth International Artificial Intelligence Research Society Conference, Orlando, FL, USA, May 2000, AAAI Press, pp [8] Common Criteria Oroject Sponsoring Organizations (eds.), Common Criteria for Information Technology Security Evaluation (CC 2.1), August [9] Office for Official Publications of the European Communities (ed.), Information Technology Security Evaluation Criteria (ITSEC 1.2), IX. BIOGRAPHISCHES Dr. Klaus P. Jantke arbeitet seit Anfang 1999 am Deutschen Forschungszentrum für Künstliche Intelligenz (kurz: DFKI) GmbH als Principal Researcher. Er koordiniert das Projekt FairPay (vgl. über Verläßlichkeit im elektronischen Zahlungsverkehr und ist einer der beiden Ko-Leiter des Kompetenzzentrums e-learning am DFKI (vgl. Darüber hinaus leitet er das Verbundprojekt LExIKON (vgl. über Learning for Extraction of Information resp. Knowledge from Open Networks, welches vom BMWi gefördert wird, sowie das Verbundprojekt DaMiT (vgl. Data Mining Tutor: Ein generisches Konzept für das Lehren und Lernen im Internet im Rahmen des BMBF-Programms Neue Medien in der Bildung, das zum sogenannten Zukunftsinvestitionsprogramm der Bundesregierung gehört. Dr. Jantke ist seit 1987 Professor für Informatik, hat u.a. als solcher in Kuwait und Japan gearbeitet und lehrt gegenwärtig Gebiete der Künstlichen Intelligenz wie beispielsweise Algorithmisches Lernen an den Universitäten in Darmstadt und Saarbrücken.

11

12 World Congress Safety of Modern Technical Systems TÜV-Verlag

13 World Congress Safety of Modern Technical Systems Congress-Documentation Saarbruecken 2001 TÜV-Verlag

14 Imprint Printed on paper bleached without chlorine compounds ISBN Edited by: Susanne Hellmund Publisher: TUEV Saarland Foundation Cover design: media machine, Mainz ( by TÜV-Verlag GmbH TÜV Rheinland/Berlin-Brandenburg Group, Cologne 2001 Internet address: Total production: TÜV-Verlag GmbH, Cologne All rights reserved Printed in Germany 2001