Archiv der Kategorie: IT

Information Technology

Missverständnis

Kommentarrecycling:

LeVampyre schreibt sich einen Wolf um zu erklären, warum sie Datenschutz gut und die Spackeria doof findet. Was sie schreibt, fühlt sich irgendwie richtig an, geht aber am Thema vorbei. Ihrem Text fehlt ein Begriff und damit der Kontext: informationelle Selbstbestimmung. Datenschutz ist nur ein Mittel zum Zweck. Wer »den Mißbrauch von Daten (…) unter Strafe stellen« möchte, braucht erst einmal einen Rahmen, in dem sich Missbrauch definieren lässt. Diesen Rahmen bildet nun nicht der Datenschutz als Selbstzweck, sondern die informationelle Selbstbestimmung als Idee: Jede soll Herrin ihrer persönlichen Informationen und Daten sein.

Informationelle Selbstbestimmung ist der Zweck, Datenschutz nur ein Instrument dazu. Vergisst man den Zweck, während man die Anwendung des Instruments optimiert, kommt Paternalismus heraus. Dann bestimme nicht mehr ich, was mit meinen Daten geschieht, sondern Beauftragte, Minister oder die Subkultur meiner Peer Group. Wenn ich Google, Facebook oder dem ganzen Internet bewusst und absichtlich Daten zur Verfügung stelle, ist das weder ein Datenverbrechen der anderen noch meine eigene Dummheit, sondern zuallererst mein gutes Recht. Der Datenschutz muss mich unvoreingenommen dabei unterstützen, dieses Recht auszuüben, ganz gleich, ob ich etwas verschweigen oder etwas mitteilen möchte.

Gleichzeitig vollziehen sich grundlegende Änderugen in der Art und Weise, wie wir – und Unternehmen – Daten verarbeiten und nutzen. Die spezifischen Regelungen des Datenschutzes stammen aus einer anderen Ära und sie können mit diesen Änderungen nur ungenügend umgehen. Das gilt im Guten wie im Schlechten: die endlose Diskussion um den Personenbezug von IP-Adressen zum Beispiel ist einerseits irrelevant für Google und Facebook, andererseits nervig für alle, die sich damit auseinandersetzen müssen.

Nach meinem Verständnis treiben diese beiden Aspekte die Spackeria, der Mismatch zwischen Idee und Umsetzung sowie der Mismatch zwischen Konzept und Realität. Das Ziel der Spackeria ist nicht, die Informationelle Selbstbestimmung abzuschaffen, sondern den Datenschutz als Mittel und Werkzeug der Realität anzupassen.

Cyber-Krieg, nüchtern betrachtet

Die Süddeutsche hat James A. Lewis (vermutlich den hier) zum Thema Cyberwar interviewt. Herausgekommen ist eine Reihe vernünftiger Ansichten wie diese:

»Ein Staat würde für den Einsatz von Cyberwaffen die gleiche Art militärischer Entscheidungen vornehmen wie für jede andere Art von Waffen. Welchen Vorteil bringt es, die Stromversorgung zu kappen? Und was sind die Risiken dabei? Wenn die USA und China im südchinesischen Meer kämpfen, ist das ein begrenzter Konflikt. Wenn China zivile Ziele auf dem Gebiet der USA attackiert, ist das eine ungeheure Eskalation, die das Risiko birgt, dass die USA auf chinesischem Boden zurückschlagen. Streitkräfte werden gründlich darüber nachdenken, bevor sie einen solchen Angriff wagen. Dazu kommt, dass solche Attacken schwierig sind, und wir dazu neigen, den Schaden zu überschätzen, den sie anrichten. Ich kann mir nicht vorstellen, warum jemand sich die Mühe machen sollte, die Wasserversorgung anzugreifen.«

(sueddeutsche.de: „Wir müssen unsere Verteidigung stärken“)

Lewis betrachtet das Thema nicht im Hollywood- oder Scriptkiddie-Modus, sondern konsequent aus einer militärischen Perspektive. Militärs handeln rational, sie verfolgen taktische und strategische Ziele mit verfügbaren Mitteln und gegen die Handlungen eines Gegeners. Daraus ergibt sich auch das Angreifermodell, das der Verteidigung zugrunde liegt, wie oben im Zitat illustriert. Cyber-Krieg, so Lewis‘ Paradigma, ist keine neue Form des Krieges, die andere verdrängt, sondern eine neue Waffengattung, die den Krieg nicht grundlegend reformiert.

Cookies, Clients und die Cloud

Politiker und Bürokraten wollen die Verwendung von Cookies gesetzlich regulieren, erst die EU (mit unklarem Regelungsgehalt und schleppender Umsetzung), ein paar Jahre später nun auch die SPD. Warum ist das blöd? Ich hole mal etwas weiter aus:

Persönliche Computer, PCs, waren in den 70er und 80er Jahren des letzten Jahrhunderts eine große Sache. Jedem seinen eigenen Computer, klein genug für den Schreibtisch und mit verschiedenen Anwendungsprogrammen für vielerlei Zwecke einsetzbar, das hatte es vorher höchstens als Vision gegeben. Aus dieser Frühzeit der Jedermann-IT stammen viele Vorstellungen, die wir noch heute hegen, darunter die Wurzeln unseres Datenschutzes.

Auf den ersten Blick hat sich seitdem wenig geändert. Aus dem PC auf Arbeit wurde ein Gerätezoo für alle Lebenslagen aus PCs, Note- und Netbooks, Smartphones, Tablets, Internetradios, Spiekonsolen und so weiter, technisch im Grunde genommen immer noch persönliche Computer, nur schöner und kleiner und schneller. Seit den 90er Jahren folgte dem Jedermann-Computer das Jedermann-Netz und im folgenden Jahrzehnt wurde dieses Netz mobil und sozial. Allen Schichten gemein ist, dass ihre Nutzer in Selbstbedienung nach Bedarf Dienste einkaufen, die nach dem Umfang der Nutzung bzw. den zugesicherten Ressourcen abgerechnet werden. Dienstanbieter stellen aus einem Pool an Ressourcen ohne Zeitverzug die jeweils nachgefragten Dienste bereit.

Die jetzige Dekade wird das Jahrzehnt des Cloud Computing. So wie der PC in den 70ern entstand und in den 80ern seinen Namen bekam und sich verbreitete, ist Cloud Computing keine ganz neue Sache, sondern längst erfunden, einsatzbereit und zum Teil auch schon etabliert. Neu ist nur, dass es jetzt einen Namen dafür gibt und alle ein Geschäft wittern, nachdem die Early Adopters vorgemacht haben, dass es funktioniert.

Cloud Computing bedeutet, dass ein Großteil der IT als Dienst ins Netz wandert. Das kann auf verschiedenen Abstraktionsebenen geschehen. Infrastructure as a Service (IaaS) bietet virtuelle Maschinen und Speicher, Platform as a Service (PaaS) liefert Anwendungsplattformen und Software as a Service (SaaS) schließlich macht Anwendungssoftware zu einem Dienst. Ein Beispiel für SaaS ist wordpress.com, wo dieses Blog gehostet wird. Die Schichten lassen sich stapeln, ein SaaS-Anbieter kann auf PaaS-Dienste zurückgreifen, die sich ihrerseits auf IaaS stützen. Die unteren Schichten IaaS und PaaS sind vor allem für Unternehmen interessant, während SaaS in Form von allerlei Webdiensten längst Teil unseres Alltags ist und die klassische Nutzung von Anwendungssoftware auf einem PC teils ersetzt, teils ergänzt.

Geht es um Sicherheit und Datenschutz im Cloud Computing, starren alle wie gebannt auf die Dienstseite. Daten wandern ins Netz, ob aus dem Rechenzentrum eines Unternehmens oder vom heimischen PC, und man weiß nicht genau, wo sie eigentlich gespeichert und verarbeitet werden. Das macht Angst und wirft technische, organisatorische und rechtliche Fragen auf. Hinzu kommt, dass der Übergang von Software in Kartons zu Diensten im Netz in Verbindung mit agilen Entwicklungsmethoden die Softwareentwicklungs- und -lebenszyklen verändert. Es gibt kein Google 3.0, das ich kaufen und dann ein paar Jahre verwenden könnte, sondern Änderungen am Dienst im Wochen-, Tage-, Stunden- und sogar Minutentakt. Continuous Deployment und DevOps nennen wir diese bewusste Vermischung von agiler Entwicklung und Produktivbetrieb.

Ein SaaS-Dienst ist nicht in sich abgeschlossen und unabhängig vom Rest des Netzes, sondern es handelt sich, für Nutzer manchmal schwer erkennbar, um eine Aggregation mehrerer Anwendungs- und Hilfsdienste, ergänzt um spezifische Funktionen des aggregierenden Hauptdienstes. Like-Buttons, Widgets, Videos, RSS-Feeds, Analytics, Werbebanner, Nutzerkommentare, Payment, Fonts und so weiter stützen sich auf Fremddienste, die, oft clientseitig, in den Hauptdienst integriert werden. Hilfsdienste haben meist ihren eigenen Betreiber und sie werden in viele verschiedene SaaS-Dienste eingebunden.

Weniger Aufmerksamkeit erhält beim Blick auf die Cloud die irdische Hälfte des Systems, die Client-Seite. Cloud-Dienste besitzen praktisch immer ein Webinterface, mindestens fürs Management, oft auch – und bei SaaS sowieso – für den eigentlichen Dienst. Der Nutzer bekommt damit eine universelle Client-Umgebung, bestehend aus einem Browser mit generischen Plugins (Flash, Java, Silverlight) und Unterstützungsanwendungen (PDF-Viewer, Office, iTunes) auf dem klassischen PC oder aus einem Browser und anwendungsspezifischen Apps auf mobilen Gadgets wie Smartphones oder Tablets.

Nach dieser langen Vorrede nun zurück zu den Cookies. Das Konzept des Cookies wird demnächst volljährig, es handelt sich ursprünglich um kleine Datenhäppchen, die eine Website einer Browserinstanz zur Speicherung übermittelt. Der Browser merkt sich diese Daten und schickt sie für einen festgelegten Zeitraum bei jeder weiteren Interaktion mit der Website dorthin zurück. Heute gibt es darüber hinausgehende Persistenzmechanismen auch für größere Datenmengen im Browser selbst sowie in verbreiteten Plugins, zum Beispiel im Flash Player.

Jeder Dienst in einer SaaS-Aggregation kann Cookies setzen und mit Hilfe dieser Cookies Daten über das Nutzerverhalten über alle Dienstnutzungen hinweg erfassen und sammeln. Die aggregierten Hilfsdienste erhalten dabei Daten aus verschiedenen SaaS-Anwendungskontexten verschiedener Anbieter und sind gleichzeitig für den Nutzer schwer zu identifizieren. Datenschützer stellen zu Recht die Frage, wie die Dienstnutzer unter diesen Bedingungen wirksam von ihrem Recht auf informationelle Selbstbestimmung Gebrauch machen können. Sie geben darauf aber die falschen Antworten.

De jure und traditionell wäre das Problem durch Kommunikation und Vereinbarungen des Nutzers mit jedem einzelnen involvierten Dienstanbieter zu lösen. Aggregierte Hilfsdienste als Auftragsdatenverarbeitung unter einer Vereinbarung zwischen dem Nutzer und dem Anbieter des Hauptdienstes zu subsumieren, wie es etwa für Analytics-Dienste diskutiert wurde,  vereinfacht die Sache wegen der Mehrfacheinbettung der Hilfsdienste in verschiedenste SaaS-Anwendungen nur scheinbar. Außerdem ändert sich permanent irgendwo irgendwas, so dass wir als Nutzer am Ende nur noch mit Zustimmen beschäftigt wären, wenn uns keine Generalvollmacht diese Mühe abnimmt. Erforderlich sind Lösungen, die die Architektur von SaaS-Mashups und der Client-Plattform als gegeben hinnehmen und darauf effektive Mechanismen für den technischen Datenschutz bereitstellen.

Cookies sind dabei nur ein wenig kritisches Randphänomen. Da sie clientseitig gespeichert werden, lässt sich ihre Speicherung und Übermittlung auch clientseitig effektiv steuern. Verbesserungsbedarf gibt es dabei vor allem in der Usability. Wünschenswert wäre zum Beispiel ein einheitliches User Interface für Einstellungen über alle Teilsysteme (Browser, Plugins, Apps, etc.) des Clientsystems hinweg anstelle getrennter, inkonsistenter Management-Schnittstellen für Cookies, Persistent DOM Storage und Flash-Cookies. Sinnvoll fände ich auch eine Möglichkeit, meine Datenschutzeinstellungen zwischen meinen fünf regelmäßig genutzten Clientsystemen zu synchronisieren statt fünfmal dasselbe konfigurieren zu müssen. Aber Clientsysteme und ihre Eigenschaften kommen in der Diskussion oft gar nicht vor. Soll ich ernsthaft mit dreiundzwanzig Diensten Vereinbarungen treffen, statt mir einmal eine Policy zusammenzuklicken, die meine eigene Technik für mich durchsetzt? P3P hatte zwar Schwächen und hat sich nicht durchgesetzt, aber damals hat man doch immerhin noch das Gesamtsystem angeschaut und eine Komponente an die richtige Stelle gesetzt, nämlich in den Client.

Mit formalisierten Rechtsritualen aus der Frühzeit der Alltags-IT ist das Problem nicht in den Griff zu bekommen. Gesucht sind effektive und benutzbare Mechanismen. Das ist die technische Sicht, die politische Dimension hat Benjamin Siggel vor einiger Zeit im Spackeria-Blog betrachtet.

Juristen sind Pragmatiker

Wenn Security- beziehungsweise Kryptographie-Nerds über die Welt reden, benutzen sie gerne Begriffe wie Beweisbarkeit und Nichtabstreitbarkeit. Diese Begriffe haben eine spezifische technische Bedeutung, sie werden aber auch von anderen verwendet, etwa von Juristen – in anderer Bedeutung. Vermischt man die Bedeutungen in verschiedenen Kontexten, so kommt man leicht auf die Idee, dass elektronische Signaturen oder elektronische Personalausweise eine unheimlich wichtige Sache seien. Nur durch die Hinterlegung landläufiger oder juristischer Begriffe mit gleich benannten, aber inhaltlich verschiedenen technischen Begriffen könne man IT-gestützte Dienste und Abläufe so gestalten, dass sie technisch und rechtlich sicher seien.

Juristen sehen das alles viel entspannter. Wie das Lawblog berichtet, hat das Oberlandesgericht Hamm eine Vereinssatzung für rechtmäßig erklärt, die Mitgliederversammlungen in einem Chatraum vorsieht. Dem Security-Nerd ist das ein Graus: Was da alles passieren könnte! Die Juristen hingegen gehen pragmatisch an die Sache heran. Wenn es keine offensichtlichen, konkreten Probleme gibt, lasst die Leute doch erst mal machen. Wenn’s dann doch Streit geben sollte, kann man sich immer noch vor Gericht treffen und über konkrete Vorwürfe reden.

Damit liegen die Juristen richtig, denn sie bedienen sich intuitiv eines statistischen Bedrohungsmodells. Theoretische Möglichkeiten interessieren den Juristen nicht so sehr, solange sie sich nicht in seiner Lebenserfahrung oder in konkreten Beweisen widerspiegeln. Damit werden theoretische Möglichkeiten, die in der Realität selten vorkommen, geringer gewichtet als erfahrungsgemäß tatsächlich auftretende Sachverhalte. Das so gebildete Modell kann in den zugrundeligenden Annahmen oder in seiner Anwendung auf einen Einzelfall falsch sein; dann haben wir was zu meckern. Aber es ist, gerade wenn es um Voraussagen über Risiken geht, angemessen. Was erfahrungsgemäß vorkommt, wird ernst genommen, weil genügend dokumentierte Fälle vorliegen. Bloße Möglichkeiten dagegen bleiben unberücksichtigt.

Abstrahiert man von den Details konkreter Abläufe, landet man damit genau bei der Definition einer Bedrohung. Eine Bedrohung setzt sich zusammen aus Interessen bzw. Zielen und Fähigkeiten. Beide Komponenten sind erforderlich: ohne Interesse sind die Fähigkeiten egal und ohne Fähigkeiten spielen die Ziele keine Rolle. Erst wenn beides zusammenkommt, wird ein Angriff daraus. Security-Nerds schauen nur auf die Fähigkeiten und ignorieren die Ziele.

Using an Inappropriate Classifier As a Security Mechanism

Zed Shaw has a story to tell about ACLs (Access Control Lists) as a common security mechanism and how they are incapable of modeling actual regulatory requirements:

(Vimeo: The ACL is Dead)

It’s not really a talk about ACLs, it’s really about how companies work and how to survive and stay sane inside enterprises. I’ll focus here, however, on the technical issue that he uses as a hook.

He poses the technical problem as »ACLs not being Turing-complete«. According to my favorite abstraction of security mechanisms, the classifier model, ACL access control schemes are a type of classifier that does not fit the problem. All security mechanisms distinguish deny from allow, just in different sets of entities and with different boundaries between the two subsets. A low complexity classifier can handle only subsets with a simple boundary between them—most entities have only neighbors of the same class, and those near the boundary have other-class neighbors only in one direction—whereas a complex classifier can model more complex class distinctions. The most complex classification would be a random assignment of classes to entities.

Two things (at least) affect the complexity that a classifier can handle: classifier design and feature extraction. Classifier design defines the boundaries that a classifier can model. Feature extraction defines the parameters or dimensions available to the classifier, the degree of abstraction with which the classifier sees the world. Authentication for instance has a high degree of abstraction, it can distinguish entities but nothing else. Access control is richer in the parameters it uses, including besides the identity of entitites also properties of objects and actions. Yet, as the talk illustrates, these dimensions are not sufficient to properly express regulatory requirements. Whether this is a problem of the mechanism or a problem of the requirements I leave for the reader to ponder.

The Point of Penetration Testing

I’m glad to see that the community starts to acknowledge what penetration testing really means. We never encountered the empty hands issue as we never sold the let’s-see-if-we-can-hack-it kind of a penetration test. We carry out vulnerability assessments based on whichever information we can get about a system or product, the more the better, and use testing as a means of getting more, or clarifying information. The point of a penetration test is not to find and demonstrate one or a handful of arbitrary attacks, the point of a penetraion test is to identify vulnerabilities that need attention. Sure, it is fun to give an uberhacker demo after the test, and we do that, too, if we’ve found gaping security holes. But more important in a penetration test is good coverage of the potential vulnerabilities, and a sound assessment of their importance, relative to the purpose and risk profile of a system. I even remember pentesting projects where we found only a few relatively minor issues in a low-risk website – and made our clients happy by telling them just that. There is really no need to be disappointed if a penetration test ends without a root shell. There is no point in withholding information from testers, reducing their efficiency. And there is no point in testing just the infrastructure but not the applications.

Neat XSS Trick

I just learned a neat XSS trick from a blog post by Andy Wingo. This is old news to the more proficient web application testers among my readers, but it was new to me and I like it. I wasn’t aware that one could redirect function calls in JavaScript so easily:

somefunction = otherfunction;

somewhere in a script makes somefunction a reference to otherfunction. This works with functions of the built-in API, too, so any function can become eval:

alert = eval;

or

window.alert = eval;

So if you can inject a small amount of script somewhere, and a function parameter elsewhere, you can turn the function that happens to be called into the eval you need. This PHP fragment illustrates the approach:

<?php
// XSS vulnerability limited to 35 characters
print substr($_GET["inject1"], 0, 35);
?>

<script>
// URL parameter goes into a seemingly harmless function - which we
// can redefine to become eval
<?php $alertparam = htmlspecialchars(addslashes($_GET["inject2"]), ENT_COMPAT ); ?>
alert('<?=$alertparam?>');
</script>

The first PHP block allows up to 35 characters to be injected into the page unfiltered through the inject1 URL parameter, just enough to add to the page this statement:

<script>alert=eval;</script>

or

<script>window.alert=eval;</script>

The second block embeds the value of the inject2 URL parameter in JavaScript as the parameter of alert() after some (imperfect) escaping. This one has unlimited length but goes into a seemingly harmless function – until somebody exchanges the function behind the identifier alert.

To see it work, put the PHP code on your web server and call it with a URL like this:

xss.php?inject1=<script>window.alert=eval;</script>&inject2=prompt('Did you expect this? (Yes/No)');

This works fine with Firefox 9 and, if XSS filter is disabled, IE 9. Safari 5.1.2 silently blocks the exploit, telling me about it only in debug mode. If you really need to, you’ll probably find an evasion technique against client-side XSS filters. IE seems to need window.alert, while Firefox is happy with just alert in inject1.

Unterschätzte Risiken: Sicherheitsbewusstsein – und Kindergartenbedrohungsmodelle

Die Vorgeschichte:

Jemand hat eine Schadsoftware verbreitet, die den Datenverkehr befallener Systeme umleitet. Das FBI hat die dafür verwendeten Server unter seine Kontrolle gebracht und zunächst weiterlaufen lassen, will sie aber demnächst abschalten. Das BSI stellt zusammen mit der Telekom eine Website bereit, mit der man seinen PC auf Befall prüfen kann und ggf. ein Tool zur Bereinigung angeboten bekommt.

Das Ergebnis:

»Verwirrung um die Schadsoftware DNS-Changer: User fürchten nach dem Aufruf zum Rechner-Selbsttest des Bundesamtes für Sicherheit in der Informationstechnik, sie könnten sich den Staatstrojaner einfangen. Die Behörde weist die Vermutung zurück.«

(Focus Online:
Angst vor Hacker-Angriff und dem Staatstrojaner: Internetnutzer trauen dns-ok.de nicht)

Kinder, das ist doch blöd. Wenn ich einen Staatstrojaner unter die Leute bringen will, dann mache ich das nicht so, dass mein Werk nach drei Stunden aufgeflogen und durchanalysiert ist. Und überhaupt, woher habt Ihr Euer Angreifermodell? Was muss man geraucht haben, um bei jeder Handlung der Behörden eines demokratischen Rechtsstaates zuerst eine gegen sich selbst gerichtete Verschwörung zu vermuten? Sicher, Behörden machen manchmal Mist, zuweilen auch richtig großen und mit Vorsatz. Aber so eine plumpe Verteilaktion, wie Ihr sie unterstellt? Ihr seid ja nicht ganz dicht.

The German eID system explained and discussed

We just finished reviewing the final, ready-to-print version of our article Electronic Identity Cards for User Authentication—Promise and Practice, which will appear in the upcoming issue of IEEE Security & Privacy Magazine (vol. 10, no. 1, jan/feb 2012, DOI: 10.1109/MSP.2011.148). We outline how the German eID system works and discuss application issues. Here is our abstract:

Electronic identity (eID) cards promise to supply a universal, nation-wide mechanism for user authentication. Most European countries have started to deploy eID for government and private sector applications. Are government-issued electronic ID cards the proper way to authenticate users of online services? We use the German eID project as a showcase to discuss eID from an application perspective. The new German ID card has interesting design features: it is contactless, it aims to protect people’s privacy to the extent possible, and it supports cryptographically strong mutual authentication between users and services. Privacy features include support for pseudonymous authentication and per-service controlled access to individual data items. The article discusses key concepts, the eID infrastructure, observed and expected problems, and open questions. The core technology seems ready for prime time and government projects deploy it to the masses. But application issues may hamper eID adoption for online applications.

We think that eID functions of government-issued ID cards will not replace means of everyday online authentication. With eID, there will be few new use cases for ID cards, eID just supports online versions of the traditional use cases. Most of the traditional use cases in Germany involve bureaucracy or legal requirements: legal protection for children and young persons, required identification of mobile phone users or bank account holders, or procedures of administrative bodies involving »Ausweis bitte!« at some point. For those who followed the debate and rollout in Germany, there should be nothing new in our article, but the article may come in handy as a reference for international audiences.

Our article will be in good company as it will appear in a theme issue on authentication. If I read the preprints collection correctly, there will be a user study by Amir Herzberg and Ronen Margulies,  Training Johnny to Authenticate (Safely), and an article by Cormac Herley and Paul van Oorschot, A Research Agenda Acknowledging the Persistence of Passwords (authors‘ version). It seems sexy to many to call the days of the password counted—IBM just predicted password authentication would die out soon—but if I had to make a bet I would follow Cormac and Paul.

The final version of our article will be paywalled by IEEE, but you can find our preprint with essentially the same contents on our website.

Eine gute Idee schlecht umgesetzt

Das Infor­mations­system der Gesund­heits­bericht­erstat­tung des Bundes ist eine Fundgrube für statistische Gesundheitsdaten, die Joseph Kuhn vom Gesundheits-Check zu Recht empfiehlt. Dort erfahren wir zum Beispiel, dass in der Bundesrepublik des Jahres 1989 aus jeder Milli0n Personenkilometer für Kfz-Insassen 1,31 verlorene Lebensjahre resultierten, aus dem Radfahren hingegen nur 0,02 und damit weniger als aus der Benutzung von Bus (0,11) und Bahn (0,05).

Diese Tabelle hätte ich gerne verlinkt, aber da fängt der Ärger an. Die Inhalte haben keine festen URLs, sondern die Site merkt sich die Navigation ihres Benutzers irgendwo in ihrem Session Management. Wer die Site in mehreren Tabs oder Fenstern öffnet, bekommt beim Reload einer Seite Schwierigkeiten, und verlinken lässt sich anscheinend nur eine Fehlermeldung, aber kein Inhalt.

Stärken zeigt die Site nur in der Erfüllung formaler Anforderungen, vulgo: Compliance. Auf der Startseite prangen CSS- und HTML-Validator-Buttons, und barrierenfrei gibt man sich auch. Das ist nur leider völlig bedeutungslos, solange die Grundfunktionen kaputt sind.

Vielleicht hätten sie die Site nicht in der DDR bei Robotron bauen lassen sollen. Genau danach sieht sie nämlich aus.

Was könnte schiefgehen?

Eine brilliante Idee. Um sich vor Trojanischen Pferden auf ihrem PC zu schützen, gehen Sie auf eine Website, klicken Sie einen Button und installieren Sie damit ein Programm auf ihrem Rechnern. Danach sind Sie sicher:

»Dem im Netz kursierenden Duqu-Trojaner kann man durch einen Klick auf einer Microsoft-Seite den Zugang zum Windows-Rechner verwehren. Anwender müssen folgendes tun: Anwender sollten auf http://dpaq.de/VH2BY unter «Enable» den Button «Fix it» drücken und damit ein kleines Programm installieren, das den Zugriff auf die betroffene Windows-Schwachstelle in einer Programmbibliothek verhindert, erklärt das Bundesamt für Sicherheit in der Informationstechnik.«

(LVZ Online: Duqu-Trojaner einfach aussperren)

Was könnte dabei schiefgehen? Seht selbst, das sind die Buttons:

Toll, nicht wahr?

Homecomputer im Test

Damals wusste man noch nicht so recht, was man mit einem Computer zu Hause anstellen soll, und arbeitete sich an offensichtlichen, aber nicht unbedingt nützlichen Anwendungen ab:

Wer beispielsweise die Bestände seines gut sortierten Weinkellers elektronisch speichern möchte, müßte – sobald ihm der Sinn nach einem edlen Tropfen steht – folgende Prozedur hinter sich bringen: Heimcomputer einschalten, Programmkassette in den Recorder einlegen, Programm laden, Kassette wechseln und »Weinkellerdaten« in den Rechner einlesen, Befehl zur Auswahl eines trockenen ’82er Württembergers eingeben, eintragen in den Daten bestand, dass die Flasche nun bald geleert sein wird. Schreiben der gesamten Daten zurück auf die Kassette. Wegräumen der Kassetten und Ausschalten des Rechners. Während der elektronisch ausgerüstete Weinkenner nun den Weg in den Weinkeller antritt. um die richtige Flasche zu suchen, hebt der technisch rückständige Bacchant gerade das weite Glas und trinkt auf die gute alte Zeit, als man Wein noch mit Kennerblick auswählte.

GI SICHERHEIT 2012

Deadline für Beiträge ist der 24. Oktober 2011. Details unter http://sicherheit2012.cased.de/.

GI SICHERHEIT 2012 Sicherheit – Schutz und Zuverlässigkeit

Fachtagung vom 5. – 7. März 2012
Kongresszentrum darmstadtium
Schlossgraben 1, 64283 Darmstadt

Die Sicherheit 2012 ist die regelmäßig stattfindende Fachtagung des Fachbereichs  ”Sicherheit – Schutz und Zuverlässigkeit” der Gesellschaft für Informatik e.V. Sie bietet einem Publikum aus Forschung, Entwicklung und Anwendung ein Forum zur Diskussion von Herausforderungen, Trends, Techniken und neuesten wissenschaftlichen und industriellen Ergebnissen. (…)

Trust Center

Nach dem Vorfall bei Diginotar − Unbekannte haben sich mehrere von Diginotar ausgestellte SSL-Zertifikate verschafft, und eines davon blieb längere Zeit unbemerkt gültig − schimpfen viele über das Geschäft der Zertifikatsaussteller und deren vorinstallierte CA-Zertifikate in Webbrowsern. Es ist einfach, Dinge für kaputt zu erklären, aber damit verbessert man nicht unbedingt die Welt. CAs heißen auch Trust Center. Das ist die bessere Bezeichnung, denn mit einem realistischen Vertrauensbegriff ergibt alles einen Sinn.

Vertrauen ist ein Vorurteil zur Reduktion sozialer Komplexität, eine Erwartung an das Verhalten anderer, die erfüllt oder auch entäuscht werden kann. Ob online oder im Alltag, ich könnte vor jeder Interaktion mit anderen gründlich prüfen, mit wem ich es zu tun habe, und  Vorsichtsmaßnahmen gegen das Scheitern ergreifen. Das wäre aber aufwändig, vor allem Im Verhältnis zur Größe und Häufigkeit von Alltagsgeschäften wie dem Kauf eines belegten Brötchens oder dem Aufbau einer SSL-Verbindung. Also lasse ich die Vorsichtsmaßnahmen weg und ersetze sie durch Vertrauen.

Unbekannte ohne Interaktionshistorie bekommen ein Basisniveau an Vertrauen zugeordnet, das begrenzt ist: einem Fremden im Park werde ich gerne drei Jonglierbälle im Wert von ca. 20 Euro borgen, nicht aber mein Fahrrad. Wiederholte erfolgreiche Interaktion lässt das Vertrauen wachsen. Wer ein paarmal im Park mit mir jongliert und meine Bälle nicht an Hunde verfüttert hat, bekommt unter Umständen höhere Werte anvertraut. Ich verborge auch mein Fahrrad, nur nicht an jeden. Enttäuschtes Vertrauen wird unmittelbar zerstört, wenn die Enttäuschung bemerkt wird. Es kann danach dauerhaft zerstört bleiben oder erneut aufgebaut werden, möglicherweise von einem niedrigeren Startniveau als bei Unbekannten.

Vertrauen lässt sich böswillig ausnutzen. Dazu muss sich der Angreifer lediglich anders verhalten als sein Opfer es erwartet und dabei im Verfügungsrahmen des ihm entgegengebrachten Vertrauens bleiben. Ein unseriöser Spendensammler auf der Straße nutzt das Basisvertrauen gegenüber Unbekannten, während ein Anlagebetrüger oft bewusst Vertrauenspflege betreibt, um größere Summen anvertraut zu bekommen. Solche Vertrauensbrüche sind verboten und werden verfolgt. Unsere Gesellschaft hält Vertrauen für so nützlich, dass sie seine böswillige Ausnutzung bestraft. Auf diese Weise erleichtert sie uns das Vertrauen ineinander und damit die soziale und ökonomische Interaktion.

Analoge Vorgänge beobachten wir im Zusammenhang mit Diginotar und anderen SSL-CAs. Den vorinstallierten CAs zu vertrauen, erleichtert unseren Alltag. Unser Vertrauen bleibt begrenzt, Bankgeschäfte zum Beispiel mit ihrem vergleichsweise hohen Verlustpotenzial stützen sich nicht alleine auf SSL, sondern verwenden weitere Mechanismen. Das Vertrauen in Diginotar ist aufgrund des Vorfalls nun zerstört. Vasco als Mutterfirma hat die Wahl, die Investition abzuschreiben oder neues Vertrauen aufzubauen, vorzugsweise unter neuem Namen, um scheinbar unbelastet beim Basisniveau anfangen zu können.

Das einzige gefährliche Trugbild, das ich hier sehe, ist die falsche Perfektionserwartung, die aus vermeintlichen Sicherheitsversprechen folgt. Browser mit vorinstallierten CA-Zertifikaten geben kein Sicherheitsversprechen, sondern sie ermöglichen Vertrauen, nicht mehr und nicht weniger. Wer an der Verwendung von CA-Zertifikaten wirklich etwas verbessern möchte, der sollte daran arbeiten, Vertrauensbrüche schnell und verlässlich erkennbar zu machen. Das halte ich für das eigentliche Problem: ich bekomme nur zufällig und unsystematisch mit, wie sich eine CA verhält.

(Das war zuerst ein Kommentar auf Google+, passt aber besser hier ins Blog.)

Zwei lesenswerte Rants

Die aktuelle Ausgabe des IEEE Security and Privacy Magazine enthält zwei schöne Rants, beide zum Thema Realitätssinn. Leider liegen die Artikel hinter einer Paywall, ich empfehle sie trotzdem.

Ian Grigg und Peter Gutmann beschäftigen sich in The Curse of Cryptographic Numerology mit der vielfach anzutreffenden einseitigen Fokussierung auf Schlüssellängen unter Vernachlässigung realer Bedrohungen und praktischer Aspekte. Sie argumentieren, dass das nicht nur am Problem vorbeigeht, da Kryptographie selten gebrochen und häufig umgangen wird, sondern auch den pragmatischen Einsatz mit nicht idealen, aber im Anwendungskontext ausreichenden Schlüssellängen behindert.

In Vulnerability Detection Systems: Think Cyborg, Not Robot lässt sich Sean Heelan über akademische Arbeiten zu Sicherheitstestverfahren aus und attestiert ihnen Irrelevanz in der Praxis. Er nimmt kein Blatt vor den Mund und empfiehlt den Wissenschaftlern, sich doch bitte mal mit aktuellen Sicherheitsbugs, Testverfahren und Exploit-Methoden zu beschäftigen.