Unterschätzte Risiken: Radon
(youtube)
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.
Flawed Security Economics
I just stumbled upon a piece of economics-of-security reasoning that amazes me:
»Bank robbers steal approximately $100 million per year in the US. (…) To prevent this, banks spend $600 million per year on armored car services and $25 million per year on vault doors. The FBI spends $50 million per year investigating robberies. A good deal more is spent on security guards—approximately 1 million in the US, paid about $24 billion per year (outsourcing makes it difficult to say how many work for banks). In summary, the cost of protecting against bank robberies far exceeds the loss.«
(Michael Lesk, Cybersecurity and Economics, IEEE S&P Nov./Dec. 2011)
I don’t doubt the figures, but the conclusion does not make sense to me. Why should one put the cost of security measures in relation to the losses that they don’t prevent? The $100 million per year are the losses that remain after security. What the security investment prevents is the losses that would occur without it, not the losses that continue to occur despite the effort. I’d love to see an estimation of this quantity. The author even gives a hint towards the possible magnitude, as he continues:
»To look at a less safe society, in a single 2007 bank robbery in Baghdad, robbers made off with $280 million (it was an inside job).«
Perhaps it is even normal for the cost of security to exceed the losses that remain, once the security spending has been optimized?
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.
Unterschätzte Risiken: Fußball
Woche für Woche ziehen sich Sportler schwere Kopfverletzungen zu. Wir könnten zur besten Sendezeit zusehen, wenn wir das Fernsehen nicht für ein Medium abnehmender Relevanz aus dem vorigen Jahrhundert hielten. Man diskutiert sogar über Schutzhelme. Ist schon wieder Radsportsaison? Nein, es geht um Fußball:
»Die Liste der bösen Kopfblessuren in der laufenden Saison ist lang und prominent besetzt: So hatte es zum Beispiel Klaas Jan Huntelaar (Schalke), Michael Ballack (Leverkusen), Sven Bender und Neven Subotic (beide Dortmund) sowie Gojko Kacar (HSV) in der Hinrunde erwischt.«
(FAZ.NET: Schmerzhafter Zufall?)
Wo bleibt der zuständige Minister mit einer Helmpflichtforderung?
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:
http://vimeo.com/2723800
(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.
Internet 2011 in numbers
Die Daten der letzten Internet-Volkszählung: Internet 2011 in numbers hat Royal Pingdom zusammengetragen. Security ist nicht dabei, aber falls mal jemand Basisdaten braucht, um etwas hochzurechnen oder in Relation zu setzen, ist die Sammlung vielleicht nützlich.
In einem Wort
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.
Staatstrojaner jetzt mit Preisschild
30 Planstellen und 2,2 Millionen Euro Sachmittel kostet ein neuer Staatstrojaner. Mindestens.
Fünf Blüten auf 10.000 Einwohner
»Rund 39 000 gefälschte Geldscheine registrierte die Notenbank im vergangenen Jahr mit einem Schaden von 2,1 Millionen Euro. Im Vorjahr hatten 60 000 Falschnoten noch Einbußen von 3,4 Millionen Euro verursacht.
(…)
Rechnerisch kommen jährlich fünf (2010: sieben) Blüten auf 10 000 Einwohner. Im gesamten Euro-Raum liegt das Verhältnis bei 18 Fälschungen auf 10 000 Einwohner.«(Echo Online: Weniger Euro-Blüten beschlagnahmt als je zuvor)
Safe and sorry
A common delusion in security engineering is the idea that one could secure a system by identifying items that need protection (assets), describing the ways in which they might be damaged (threats or attacks, which are not synonymous but often confused), and then implementing countermeasures or mitigations such that all, or the most common, or the most damaging threats are covered. The system thus becomes secure with respect to the threat model, so the reasoning. This is the model underlying the Common Criteria, and it works fine as a descriptive model. To give an example from everyday life, consider a bicycle as an asset. If your bicycle gets stolen (the threat), your damage is the value of the bicycle plus any collateral damage that the loss may cause you, such as coming late to an appointment, having to pay for a taxi or public transport instead of riding your bicycle, and having to go to the gym for workout instead of getting a workout for free on your way to work. The typical countermeasure against this threat is locking the bicycle to a fence, pole, or other appropriate object. Locking your bicycle reduces the risk of it being stolen. What could possibly go wrong? Besides the obvious residual risk of your countermeasures not being strong enough, this could go wrong:
This (ex-)bicycle was and remains properly locked and no vulnerability in the lock or in items the lock depends on have been exploited. Yet, somebody made a fortune stealing bicycle parts, and somebody else lost a bicycle to an attack. What’s the problem? The problem is the gross simplification in the asset-threat-countermeasure model, which neglects three important factors:
- Adaptive adversaries. A countermeasure does not oblige the adversary to stick to the original attack plan that the countermeasure is targeted at. Security measures change the threat model. They don’t force the adversary to give up, they force the adversary to change strategy and tactics.
- The victim’s loss and the adversary’s gain are not necessarily the same. In the case of the bicycle above, the lock may reduce the attacker’s gain to the black market value of the removed parts. The victim’s loss is still one bicycle.
- Asset dependencies. Thinking of a bicycle as one asset is an abstraction. A bicycle is really a collection of assets—its parts—and an asset by itself. Such dependencies, nested assets in this case, are common.
The bicycle lock, it turns out, is not really a bicycle lock, it’s a bicycle frame lock. It protects only one sub-asset of the bicycle, and an economically motivated adversary can make a gain that seems worth the risk without breaking the lock.
Prescriptive threat modeling—threat modeling done with the aim of finding a proper set of security features for a system—needs to take these issues into account. A good threat model anticipates changes in attacker behavior due to security measures. A good threat model considers not only damages to the victim but also gains of the adversary, as the latter are what motivates the adversary. And good security engineering is biased towards security, always overestimating adversary capabilities and always underestimating the effect of security measures, systematically.
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.
In einem Wort
Der Sicherheitsbegriff im Wandel
Was die Politik unter Sicherheit versteht, ändert sich im Laufe der Zeit. Gabi Schlag beschäftigt sich mit dem Begriff und seinem Wandel. Auszug:
»Spätestens seit den 1990er Jahren, so haben viele Kommentatorinnen und Experten angemerkt, zeichnet sich jedoch eine erneute begriffliche Transformation ab: immer häufiger reden wir über Risiko und Vorsorge, über Gefährdungen als Folge von Modernisierung und Technologisierung unserer Gesellschafts- und Arbeitswelt. Die Risikosemantik, so Christopher Daase und Oliver Kessler (2008), rekurriere dabei auf eine Redefinition von Ungewissheit und Wahrscheinlichkeit und führe zu einem Sicherheitsparadox: Sicherheitspolitik reagiert nicht mehr nur auf Gefahren, sondern produziert gleichsam neue Sicherheitsprobleme.«
Unterschätzte Risiken: Sepsis
Die meisten Menschen sterben bekanntlich im Bett, zum Beispiel so:
»Das Kompetenznetz Sepsis hat vor wenigen Jahren nachgewiesen, dass in Deutschland jeden Tag 162 Patienten an dieser Eskalation sterben. Die Zahl ist fast so hoch wie die Zahl der Herzinfarkttoten. Damit ist die Sepsis die dritthäufigste Todesursache, obwohl sie nur selten in der Todesursachenstatistik erscheint, weil dort nur die Grunderkrankungen gelistet werden. Ein Drittel aller intensivmedizinischen Kosten entstehen bei der Behandlung der Sepsis.«
(FAZ.NET: Sepsis-Therapie: Infektion außer Kontrolle)
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.
In einem Wort
Life lessons from an ad man
(YouTube)
Risikoanalyse für Gauner
FAZ.NET präsentiert in einer Galerie von Infografiken dieses schöne Stück, das die Aufklärungsquoten verschiedener Verbrechens- und Vergehensarten zeigt und ordnet. Demnach werden Geldfälscher, Geiselnehmer und Autohehler fast immer gefasst, Autoknacker sowie Auto- und Taschendiebe hingegen fast nie. Zur Berufsberatung für legalitätsflexible Arbeitssuchende fehlen jetzt noch analoge Aufstellungen der mittleren Gewinne pro Tat sowie der mittleren Strafe, falls man erwischt wird. Mit diesen Angaben könnten wir ausrechnen, welche Verbrechen sich lohnen. Falls jemand Zahlen hat oder Leute kennt, die Zahlen haben, her damit.
Enttäuschte Vorfreude
Liebe Microsoft,
wenn ein Button unter einer Sicherheitswarnung mit Details beschriftet ist,
wäre es schön, wenn ein Klick darauf auch Details anzeigen würde. Und nicht die Hilfe öffnen, die mir SSL erklärt. Mich würde hier zum Beispiel interessieren, welche Inhalte denn gemeint sind, damit ich meine Entscheidung in Kenntnis der Umstände treffen kann. Stattdessen bleibt mir nichts anderes übrig, als immer auf JaNein zu klicken. Dabei brauche ich keine Hilfe, das schaffe ich auch so.
Sicher ist sicher? 