Frank Rieger, Sprecher des CCC 
Sicherheit und Open Source
Während mein nicht-Open-Source-System hier gerade versucht hochzufahren, kann ich vielleicht noch einige Worte zum Chaos Computer Club sagen. Der CCC besteht seit 1984. Wir verstehen uns als eine Vereinigung, die versucht, zwischen allen Stühlen, zwischen der Industrie, den Hackern und dem Staat zu vermitteln und bestimmte Prozesse in der Gesellschaft anzuschieben, die eine kritische Begleitung auf dem Weg in die Informationsgesellschaft darstellen. Wir sind da relativ erfolgreich, auch wenn es immer wieder Rückschläge gibt. Eine der Dinge, die uns im letzten Jahr am meisten beschäftigt haben, war genau die Problematik der Krypto-Reglementierung in Deutschland, die da drohte und nun zumindest für die nächsten zwei Jahre erst einmal abgewehrt zu sein scheint.
Heute möchte ich drüber reden, was Open Source mit Sicherheit zu tun hat. Fangen wir mal ganz unten an. Wodurch entstehen eigentlich Sicherheitsprobleme? Das allerwichtigste Problem, das überall immer wieder auftritt, ist, daß die Leute einfach nicht wissen, was sie da tun. Sie haben einen erheblichen Kompetenzmangel beim Coden. Sie wissen nicht genau, welche Algorithmen sie verwenden sollen. Sie wissen nicht genau, welche Probleme entstehen, wenn man bestimmte Wege der Implementierung wählt. Da gibt es einfach erhebliche Lücken im Bewußtsein darüber, was eigentlich passiert, wenn man bestimmte Dinge so oder so tut. In der Wirtschaft sehen wir immer wieder, daß die Prioritätensetzung nicht im Hinblick auf Sicherheit erfolgt. D.h., da wird ein Produkt auf den Markt gebracht, und wichtig ist erst einmal, daß es funktioniert. Die Leute sind zufrieden. Man kann es prima verkaufen. Das Marketing ist glücklich. Es ist eine bunte Verpackung drumrum. Dann ist vielleicht noch ein Schloß drauf, das Sicherheit symbolisieren soll. Und damit ist sozusagen die Sicherheit gewährleistet. Oder man schreibt sich eine hübsche Zertifizierung drauf, die vor zehn Jahren mal für ein komplett anderes Produkt errungen wurde -- siehe Windows NT -- und denkt, man hat die Sicherheit dann damit erreicht.
Ein anderes Problem ist, daß Produkte, die eigentlich von sich aus relativ sinnvoll und sicher sein können, mit komplett falschen Default- und Installationswerten ausgeliefert werden. Typisches Beispiel: man kauft sich einen PC, installiert sich eine aktuelle SuSE-Distribution und guckt dann erschreckt auf die Ports, die offen sind -- damit kann man sich nicht einmal in den IRC wagen, ohne sofort gebombt zu werden. Wir habe damit zu tun, daß Leute nicht darüber nachdenken, daß ein System beim Einschalten sicher sein sollte. Postives Beispiel, auch wenn's nicht Open Source ist: Mac-OS ist, wenn man es hochfährt, ziemlich dicht. Unixe, wie z.B. Urix, auch eine Linux-Distribution, die funktionionieren auch gut und sind sicher, sobald sie installiert sind. Diese Gedankenlosigkeit, daß man nicht darüber nachdenkt, was eigentlich passiert, wenn ein Endanwender herkommt und den Kram installiert, ist eines der größten Probleme überhaupt.
In den Organisationen, in denen Produkte, auch Open-Source-Systeme, entwickelt oder angewendet werden, gibt es oft genug ziemlich große strukturelle und organisatorische Defizite. D.h., daß nicht klar ist, wer eigentlich dafür zuständig ist, daß ein Produkt am Ende sicher ist. Wer ist dafür zuständig, daß die Sicherheit eines Produkts vor der Auslieferung getestet wird? Wer ist, wenn ein neuer Intenet-Service aufgesetzt wird, dafür zuständig zu gucken, daß da keine Kundendaten verlorengehen? Wenn man sich die Geschichte von den 'virtuellen Providern' anguckt, die in den letzten Monaten immer mal wieder hochpoppten und versuchten Internet zu machen und dann plötzlich zwei Wochen später verendeten, wo dann auf dem Heise-Ticker stand, alle Kundendaten waren plötzlich im Internet zu sehen -- Internet Professional war, glaube ich, der letzte, der so verendet ist. Da sehen wir mal wieder, die Leute haben keine Sicherheitskultur. Sicherheit ist ein add-on, da denkt man ganz am Schluß drüber nach. Kurz bevor man das Produkt shipped, wird dann noch irgendetwas gemacht, was Sicherheit simulieren soll, aber es ist tatsächlich kein struktureller Bestandteil der Produktentwicklung. Oft genug ist es auch so, daß die Leute einfach demotiviert sind. Gerade in großen Organisationen sind sie sich bewußt, daß sie hier sowieso nur noch ein paar Monate arbeiten werden. Die machen jetzt die Sache fertig, und ob das hinterher sicher ist, interessiert wirklich niemanden.
Das sind sozusagen die unbewußten Entstehungsfelder von Sicherheitsproblemen: da, wo niemand bösen Willens ist. Es gibt natürlich noch die andere Seite, wo die Leute tatsächlich bösen Willens sind. Das sind die Leute, die versuchen, Kryptografie einzuschränken, die versuchen, Hintertüren -- wenn's schon nicht über den offiziellen Weg geht, dann über den inoffiziellen -- einzubauen, und die denken, zentralistische Strukturen sind der Stein der Weisen und damit wird man auch das nächste Jahrtausend überstehen können.
Das konventionelle oder geschlossene Modell ist: wir halten alles geheim. Typisches Beispiel dafür war GSM, der Standard, mit dem die meisten Mobiltelefone heutzutage funktionieren. Da war es so, daß alle Verschlüsselungssysteme, alle Verfahren, die da verwendet wurden, die irgendwas mit Sicherheit zu tun hatten, geheim waren. Die gab es einfach nicht. Da gab es nur ein paar vage, obskure Andeutungen in ein paar Fachpublikationen, wie es eventuell so ungefähr funktionieren könnte. Der Algorithmus wurde nirgendwo reviewed. Die saßen wirklich mit ihrem Hintern drauf und wollten ihn nicht rauslassen. Was natürlich passierte: letztes Jahr ist ein bißchen Papier ge-leaked, wo im Groben drinstand, wie's geht. Dann haben sich ein paar Leute hingesetzt und eine Kryptanalyse gemacht und noch die restlichen Bestandteile des Algorithmus rekonstruiert und haben eine relativ simple Attacke auf diesen Algorithmus gefunden, die dann auch duchgeführt wurde, und prompt konnte man GSM klonen. Die GSM-Industrie war davon schwerstens überrascht. Die Sache wurde in Amerika publiziert von den *-Hackern und wir haben die hier in Deutschland nachvollzogen, bei Mannesman. Die fielen komplett aus allen Wolken. Denen fielen buchstäblich die Kinnladen runter, weil sie sich darauf verlassen hatten, daß ihr System sicher ist, weil: es ist doch alles geheim und es kann doch niemand wissen, und wieso wißt Ihr denn das jetzt plötzlich?
Dieses Priesterschaftsprinzip ist die konventionelle Art, Sicherheit herzustellen. Wir haben eine kleine Priesterschaft, die darüber wacht, daß das Geheimnis ein Geheimnis bleibt, daß die Götzen angebetet, die kleinen Öllämpchen auf dem Altar angezündet werden und die Papiere nicht nach draußen gehen. Das bewährt sich nun nicht wirklich. Dieses Wissensmonopol ist das, was wir als Security by Obscurity kennen. Ich designe ein System so, daß es von außen auf den ersten Blick nicht durchschaubar ist und seine inneren Wirkungsweisen nicht verstanden werden können -- so glaubt man zumindest. Und wenn man dann der Sache doch nicht so traut, baut man lieber noch so ein paar Gemeinheiten ein, einige Fallen oder Inkonsistenzen, um zu verhindern, daß, falls es einen Security-Bruch gibt, die Sachen zu schnell vorangehen. Dieses geschlossene Modell ist sehr kompatibel mit dem Kulturraum von großen Entitäten wie Siemens z.B. Die finden so etwas echt toll. Die haben da eine kleine Abteilung mit einer großen Stahltür davor, und da ist ein Zahlenschloß und ein Iris-Scanner dran und noch eine große Stahltür und dahinter liegen in dem Safe die drei Blätter Papier, auf denen steht, wie's geht. Da ist etwas, was sie verstehen. Da können sie einen Wachmann davorstellen, der notfalls schießt, und damit ist die Sicherheit dann eigentlich gewährleistet. Daß der Algorithmus, den sie in dem Panzerschrank mit den drei Stahltüren haben, auf jeder beliebigen Chipkarte, die zehn Millionen Mal verteilt wird, nach draußen geht, daran haben sie nicht wirklich gedacht.
Zu den Problemen des geschlossenen Modells gehören in erster Linie Backdoors. Man weiß nicht, wo die Hintertüren dadrin sind. Beispiele gibt es da wirklich in größtem Umfang, angefangen bei der EU-Kommission, die vor mittlerweile zwei Jahren das kleine Problem hatte, daß sie bei den GATT-Verhandlungen (das weltweite Handelsabkommen) merkten, daß die amerikanische Delegation die Antworten auf die Fragen, die sie gerade stellen wollten, immer schon vorher wußten und sich wunderten, wie das denn eigentlich kam. Sie haben dann nachgehakt, ihre Logs gefilzt und gesehen, daß der CIA seit Monaten ihre komplette interne eMail bei der EU-Kommission mitgelesen hat. Die sind da über eine Hintertür in einem Router reingekommen -- einem amerikanischen Router selbstverständlich --, die systematisch ausgenutzt wurde, die auch nicht publiziert war. Die deutsche Regierung hat sich ja nun entschlossen zu sagen, wir verwenden für das Informationssystem Berlin-Bonn eine deutsche Krypto-Hardware. Nur wieviel es ihnen nützt, ist eine sehr interessante Frage. Bisher konnte mir noch niemand glaubhaft versichern, daß alle deutschen Kryptofirmen auch tatsächlich noch in deutschem Besitz sind. In den Handelsregistern finden sich so seltsame Sachen, wie Holdings in Luxemburg. Da sollte man vielleicht noch mal nachgucken. Hintertüren finden sich auch in Firewalls und in ISDN-Anlagen. Da komme ich später noch drauf, wo man sowas überall schon gefunden hat.
Das größte Problem beim geschlossenen Modell, selbst wenn man keine Hintertür drin hat, ist, daß die durchschnittliche Geschwindigkeit der Informationsverbreitung in den letzten fünf Jahren exponentiell zugenommen hat. D.h., die Leute tauschen Informationen deutlich schneller aus und sie wechseln ihre Jobs viel häufiger. Jedesmal, wenn jemand aus einer Sicherheitsabteilung seinen Job wechselt, besteht ein potentielles Sicherheitsrisiko. Der kann noch so viele Non-Disclosure Agreements unterschreiben. Das Wissen befindet sich in seinem Kopf und irgendwann fällt's da halt manchmal auch raus. Wenn ein System schlecht designed ist -- kommt ja vor -- dann ist die Haltbarkeit dieses Sicherheitssystems ziemlich non-deterministisch.
Manchmal wissen sie auch vorher, was das Problem ist. Ein typisches Beispiel: die Deutsche Telekom hat, bevor sie die Telefonkarte eingeführt hat, bei einem Hamburger Sicherheits-Consulting-Unternehmen alle möglichen Systeme, die sie so im Auge hatten, testen lassen. Sie haben sich holografische Karten, Karten mit Magnetstreifen, die mit dem Rausbrennen -- alle Karten, die man so aus anderen Ländern kennt, -- angeguckt und sich letztendlich für die Chipkarte entschieden. Und dieses Unternehmen, Scientific Control Systems, hat ihnen gesagt: Paßt auf, die Sicherheit der Telefonkarte, so wie sie uns vorlag -- das war damals der erste Siemens-Telefonkarten-Chip -- beruht schlicht und ergreifend darauf, daß noch niemand weiß, wie man Chipkarten hackt. D.h., es handelt sich nicht um eine inhärente Sicherheit, sondern tatsächlich nur um einen kleinen Technologievorsprung und wir (dieses Security-Unternehmen) gehen davon aus, daß dieser Technologievorsprung etwa drei, maximal vier Jahre anhält. D.h., dann muß eine neue Chipkartengeneration auf den Markt. Die Telekom hat gesagt, klar, kein Problem, machen wir. Siemens hat gesagt, kriegen wir hin, der Euro-Chip ist in der Mache, das sollte kein Problem darstellen. Gut, sie haben die Telefonkarten eingeführt. Dann kam das Telkom-Marketing auf eine grandiose Idee, und zwar, den Sammlern einzureden, daß nur Karten einen Wert haben, die voll sind. Die haben sich damit einen zinzlosen Kredit in dreistelliger Millionenhöhe erwirtschaftet. Ist ja auch praktisch: die Leute kaufen die Karte, telefonieren sie nie ab, da es ja eine Wertanlage ist, die Telekom nimmt Geld ein für ein Stück Plastik im Herstellungswert von ca. 42 Pfennig und bekommt dafür 50 DM -- einen besseren Profit kann man sich überhaupt nicht vorstellen. Besser als Drogenhandel. Soweit das Marketing. Dann hatten sie so 100 oder 200 Millionen an Karten in den Taschen der Leute rumliegen, die nicht abtelefoniert wurden.
Dann kamen die Techniker und sagten, wir müssen jetzt langsam mal zu Potte kommen und den Euro-Chip einführen, weil: da brodelt was und die Leute wissen langsam, wie man Chipkarten herstellt, geht halt nicht, war unmöglich. Etwa drei, dreieinhalb Jahre nachdem sie die Telefonkarte eingeführt haben, konnte ich mir angucken, wie aus einem Haus gegenüber ein langes Kabel zu einer Telefonzelle gerollt, da ein Oszilloskop angeschlossen und mit Trafowickeldraht ein kleiner Adapter gebastelt wurde, den man in den Schlitz der Telefonkarte stecken konnte und dann guckte man sich mal an, was da so passiert. Und gar nicht viel später gab es den ersten Telefonkartenemulator, der war ein bißchen größer, ein Platinchen und viel Fädeldraht dran, der auf eine alte Telefonkarte gefädelt war, auf dem der Chip rausgebrannt war, aber man konnte damit telefonieren. D.h., Scientific Control Systems hatte mit ihrere Vorhersage tatsächlich recht gehabt und die Telekom hatte ein Problem am Hals. Und dieses Problem haben sie sogar noch heute. Was die Telekom letzendlich gemacht hat, war, den Service einschränken, d.h., man kann von Telefonzellen keine Auslandstelefonate mehr führen. Sie haben etwas mit mechanischen Sicherung probiert, damit man keine Kabel mehr da raushängen lassen konnte, weil so ein kleines Fallbeil runterkam. Das führte nur dazu, daß endlich die gefälschten Chips auf die Telefonkarte integriert wurden und es ist ein richtig fettes Business mit diesen Telefonkarten entstanden. Das war, glaube ich, einer der größten Schäden, der durch Security by Obscurity entstanden ist. Weil sie nicht daran gedacht haben, ein Technologiesystem nicht oder nur unter strengen Auflagen einzuführen, von dem sie schon wußten, daß es ein Problem geben wird. Wie gesagt, ein unbekanntes Verfallsdatum ist ja manchmal auch bekannt.
Reverse Engineering ist mittlerweile für viele Leute ein Hobby geworden. Die meisten Leute, die ich kenne, nehmen, wenn sie sich ein neues Gadget kaufen, erst einmal einen Schraubenzieher, am besten gleich noch vor der Ladentür, um zu gucken, was das so drinnen ist. Es ist mittlerweile total üblich, daß man so ein Gerät aufschraubt, es vor die Digitalkamera hält und das Bild in's Web tut, den Eprom ausliest und auch in's Web tut und guckt, was so passiert. Da entstehen wirklich erstaunliche Effekte, wenn man so etwas tut. Ich habe das mal mit einem kleinen Kenwood-Funkgerät gemacht, wo ich dachte, vielleicht kann man ja die Leistung erweitern und ich bekam 500 eMails von Leuten, die meinten, ich habe auch dieses Gerät und ich will das auch wissen -- bastel, bastel...
Oft genug gibt es keine Rückfallebenen in diesen Sicherheitssystemen, wie z.B. bei der Telefonkarte: die hatten keinen Notfallplan. Sie konnten nur den Service einschränken und die Polizeieinheiten zu den Telefonzellen hetzen, wenn sie etwas festgestellt haben, was wie vier-Stunden-nach-Afghanistan-Telefonieren aussah, aber sie hatten halt nicht irgendeine Art von Notfallplan.
Dieses Priesterschaftsprinzip führt dazu, daß die Anzahl der Tester sehr gering ist. D.h., man kann nur anerkannte Sicherheitsexperte, die ein großes Vertrauen genießen, damit betrauen, diese Sachen im stillen Kämmerlein ohne Hinzuziehung ihrer Studenten zu testen. Das führt einfach dazu, daß sie Fehler übersehen, vollkommen klar. Wenn nur drei Leute so ein System testen, dann sind da Bugs noch und nöcher drin. Soviel zum Problem des geschlossenen Modells.
Das offene Modell, über das wir heute reden, sagt, alle Informationen, die es zu diesem System gibt, sind public, außer die private Keys. Wir haben den Effekt, daß die Fehler in solchen Systemen durch diese öffentliche Betrachtung in der Regel relativ schnell gefunden und auch relativ schnell repariert werden. Was ich sehr interessant finde: dadurch, daß die Sourcen offen sind, werden oft genug nicht nur die Symptome behoben, wie wir das z.B. bei Windows-NT sehen, wo ein Problem im Internet-Information-Server ist und sie sagen, wir haben dafür jetzt gerade keinen Fix, weil das Problem tief im Kernel verborgen liegt und da können wir jetzt gerade nichts tun, sondern wir geben euch mal einen Patch, der verhindert, daß die entsprechenden Informationen bis zum Kernel durchdringen -- also: Pflaster draufkleben auf die großen Löcher im Wasserrohr. Das passiert halt in der Regel bei Open Source-Systemen nicht, da werden die Probleme tatsächlich behoben.
Die Einführung von Backdoors in solche System wird exponentiell schwieriger. Ich sage nicht, daß sie generell unmöglich ist, sondern sie wird nur sehr viel schwieriger, weil natürlich die Chance, daß jemand darüber stolpert, wenn er durch den Source Code geht, relativ hoch ist.
Dieses offene Modell hat auch einige Probleme. Die sollte man auf jeden Fall benennen und nicht übersehen: 'halleluja, Open Source und alles wird gut'. Das ist leider nicht der Fall. In der Praxis treten da einige Sachen auf, die wirklich der Beachtung bedürfen. Große Programme, die nicht von Leuten offen geschrieben worden sind, sondern erst hinterher aus verschiedenen Gründen Open Source gemacht werden, sind extreme schwer zu reviewen. Ich kenne keinen, der von sich behaupten kann, er hat den ganzen PGP-Source durchgelesen und weiß auch sicher, daß da keine Backdoor drin ist. Ein einzelner kann das nicht mehr leisten. Es gibt einfach keine Möglichkeit, so eine Schwarte Source-Code komplett durchzulesen und sich sicher zu sein, daß man nicht irgendetwas übersehen hat. Und wenn man so etwas mit mehreren Personen macht, ist die Gefahr, etwas zu übersehen, noch viel größer. D.h., der Weg zu solchen Kernsicherheitssystemen, und PGP ist für mich ein Kernsicherheitssystem, kann nur sein, daß sie von Anfang an offen entwickelt werden und daß die Gruppe der Leute, die daran arbeitet, die Sache von Anfang an offen macht und daß ein permanenter Review-Prozeß stattfindet. Nur so kann man erreichen, daß diese Probleme nicht eingeführt werden.
Es gibt Patent- und Urheberrechtsschwierigkeiten. Es gibt z.B. einige Juristen, die sich nicht sicher sind, ob die GPL in Deutschland so ohne weiteres durchgeht. Das ist jetzt nicht mein Problemfeld.
Ein Problem, das die Leute in den Unternehmen haben, ist, daß es kein wirklich deterministisches Zeitverhalten beim Fixen von Problemen gibt. Bei den wichtigen Systemen ist das in der Regel kein Problem, weil die Leute da dran sind. Wenn man aber kleinere Systeme benutzt, die nur auf der Arbeitskraft von ein oder zwei Leuten beruhen, kann es sein, daß die gerade im Urlaub sind, wenn ein großes Problem entsteht und sich niemand findet, der das Problem dann löst. Solche Fälle gab es auch schon.
Der Zeitaufwand, wenn man ein komplettes Unternehmenssystem auf Open Source-Basis betreibt -- sich immer die jeweils aktuellen Versionen zu besorgen, dafür zu sorgen, daß die Patches eingespielt werden usw. -- ist relativ hoch. Da ist ganz klar ein Markt für Service-Unternehmen, die auch schon entstehen, die sich darum kümmern, Open Source handle-bar zu machen, d.h. nutzbar und planbar zu machen für Unternehmen. Der Prozeß ist schon angestoßen.
Eines der wichtigsten Probleme ist das des Vertrauens. Dieser Langhaarige, der mir über das Internet einen Patch für mein Problem schickt, ist der denn überhaupt vertrauenswürdig oder hat er mir da gerade einen Trojaner eingebaut? Das kann man halt in der Regel nicht selber entscheiden. Für dieses Problem muß man Mechanismen finden, aber ich denken, da sind wir schon auf einem ganz guten Weg.
Noch ein letztes Wort zu Backdoors. Mich hat stark verwundert, daß die NSA mittlerweile doch relativ großzügig mit Verschlüsselungssystemen umgeht, die sie vor wenigen Wochen oder Monaten noch wie der Teufel gemieden haben oder versucht haben zu verhindern, daß die verbreitet werden. D.h., sie sagen: Okay, die Sache mit der Kryptoexportverhinderung haben wir nicht wirklich hinbekommen, wie sieht denn die Alternativstrategie aus? Und die Alternativstrategie ist ganz klar: Backdoors. Darin haben sie eine wirklich große Erfahrung, angefangen bei der Krypto-AG, wo über Jahrzehnte hinweg die Keys mit im Cyphertext-Stream ge-leakt wurden, bis hin zu Hintertüren, die in irgendwelche Produkte eingebaut werden, z.B. Router, Firewalls, ISDN-Systeme, Betriebssysteme. Da wird, denke ich, in nächster Zukunft deren großes Arbeitsfeld liegen, weil sie genau wissen, daß der Aufwand, die Kryptografie auf dem Transportweg zu brechen, sich so schnell nicht verringern wird, selbst wenn sie noch so viel in die Forschung stecken. Deswegen ist der Weg, den sie gehen werden, Hintertüren. Wir haben auch einen deutlichen Anstieg von Angriffen über Hintertüren gesehen, die von professionellen Industriespionen erfolgen, die solche Hintertüren tatsächlich auch kaufen. Es gibt Leute, die kennen die halt und verkaufen dieses Wissen. Etliches von dem, was an Sicherheitsproblemen da ist, wird mittlerweile nicht publiziert, sondern immer noch unter der Decke gehalten, gerade was ISDN-Systeme betrifft. Man kann diese Hintertüren nur sehr schwer erkennen, wenn man keinen Source dabei hat. Und selbst wenn man den kompletten Source von einem nicht offen entwickelten Produkt hat, gibt es da ein Problem. Systeme, die z.B. den TCP/IP-Strom, der aus meiner Firewall rauskommt, noch einmal checken -- was sind denn da eigentlich für Pakete drin und gibt es Verbindungen zu ungewöhnlichen Lokationen? -- werden eine Zukunft haben, d.h. daß man, ausgehend von der Idee des Intrusion Detection Systems, dazu übergeht ein System zu bauen, das versucht, Backdoor-Kommunikation zu erkennen.
(Transkription vgrass)
[^] top |
 |
