All posts by Sven Türpe

About Sven Türpe

Sven Türpe is a computer scientist. His current research focus is on security engineering methods, techniques, and tools. All opinions expressed in this blog are his own.

So ungefährlich ist Radfahren

Zur Helmdiskussion hatte ich hier lange nichts. Eigentlich lohnt das auch nicht, denn wer an den Nutzen eines Fahrradhelms glauben möchte, lässt sich erfahrungsgemäß von Argumenten nicht umstimmen. Doch heute bin ich über eine Zahl gestolpert, die sogar mich überrascht hat, obwohl sie mit meiner Alltagserfahrung kompatibel ist. Der großbritische nationale Gesundheitsdienst (National Health Service, NHS) macht wie so ziemlich jede Krankenkasse Werbung fürs Radfahren und hat in diesem Zusammenhang eine FAQ zur Gefährlichkeit dieser Betätigung zusammengestellt. Darin heißt es unter anderem:

“Official figures taken from the NTS suggest that the general risk of injury from cycling in the UK is just 1 injury per 19,230 hours of cycling.”

Eine Verletzung auf 19 230 Stunden Radfahren, das heißt selbst ein Fahrradkurier muss gute zehn Jahre jeden Arbeitstag acht Stunden unterwegs sein, um sich einmal zu verletzen*. Wer lediglich jeden Tag eine halbe Stunde zu seinem Büro radelt und abends zurück, der braucht sogar Jahrzehnte, um sich einmal zu verletzen. Dass Radfahren so sicher ist, hätte ich trotz vieler unfallfreier Jahre im Sattel nicht erwartet.

*) Ein Arbeitsjahr in einem Vollzeitjob hat ca. 2000 Stunden einschließlich der Urlaubstage.


Securing Your PC (1980s Style)

There was a time when personal computers came with security built into their hardware. For about a decade from 1984 on, virtually every PC featured a key lock. Depending on the particular implementation, locking would prevent powering on the computer, keyboard input, hard drive access, opening the case, or a combination thereof. This video tells the story:

From today’s perspective the key lock looks like a weak if not pointless security mechanism. In the best case it makes tampering with the hardware slightly harder—attackers have to equip themselves with tools and spend some time using them—while not at all addressing all the software vulnerabilities that we care about so much today.

Nevertheless the design made a lot of sense.

First, a keylock is a usable security mechanism. Everyone is familiar with key locks and knows how to use them, no complicated setup is required, and there is little potential for mistakes.

Second, an attacker’s physical access to hardware internals defeats most software security mechanisms. Physical access control is therefore a prerequisite for security against certain threats.

Third, personal computers at that time were not really threatened by online or software attacks, perhaps with the exception of relatively harmless viruses spreading through exchanged floppy disks. Someone tampering with the computer was indeed one of the more realistic threats.

Fourth, seemingly minor security gains can be rather effective when put in context. While forcing attackers to carry tools and use them may not seem like a great complication for them, it may suffice to prevent opportunistic attacks as well as quick serial attacks against multiple consecutive targets.

Security technology has evolved to make key locks obsolete, but they made sense at the time of their introduction.

Application Layer Snake Oil

TL;DR: The author thinks Snowden’s home security app, Haven, is snake oil regardless of the algorithms it uses. Operational security is at least as hard as cryptography and no app is going to provide it for you.

Bogus cryptography is often being referred to as snake oil—a remedy designed by charlatans to the sole end of selling it to the gullible. Discussions of snake oil traditionally focused on cryptography as such and technical aspects like the choice of algorithms, the competence of their designers and implementers, or the degree of scrutiny a design and its implementation received. As a rule of thumb, a set of algorithms and protocols is widely accepted as probably secure according to current public knowledge, and any poorly motivated deviation from this mainstream raises eyebrows.

However, reasonable choices of encryption algorithms and crypto protocols alone does not guarantee security. The overall application in which they serve as building blocks needs to make sense as well in the light of the threat models this application purports to address. Snake oil is easy to mask at this level. While most low-level snake oil can be spotted by a few simple patterns, the application layer calls for a discussion of security requirements.

Enter Haven, the personal security app released by Freedom of the Press Foundation and Guardian Project and associated in public relations with Edward Snowden. Haven turns a smartphone into a remote sensor that alerts its user over confidential channels about activity in its surroundings. The intended use case is apparently to put the app on a cheap phone and leave this phone wherever one feels surveillance is need; the user’s primary phone will then receive alerts and recordings of sensed activity.

Haven is being touted as “a way to protect their [its users] personal spaces and possessions without compromising their own privacy.” The app allegedly protects its users against “the secret police making people disappear” and against evil maid attacks targeting their devices in their absence. To this end, Haven surveils its surroundings through the smartphone’s sensors for noise, movement, etc. When it detects any activity, the app records information such as photos through the built-in camera and transmits this information confidentially over channels like the Signal messenger and Tor.

Alas, these functions together create a mere securitoy that remains rather ineffective in real applications. The threat model is about the most challenging one can think of short of an alien invasion. A secret police that can make people disappear and get away with it is close to almighty. They will not go through court proceedings to decide who to attack and they will surely not be afraid of journalists reporting on them. Where a secret police makes people disappear there will be no public forum for anyone to report on their atrocities. Just imagine using Haven in North Korea—what would you hope to do, inside the country, after obtaining photos of their secret police?

Besides strongly discouraging your dissemination of any recordings, a secret police can also evade detection through Haven. They might, for example, jam wireless signals before entering your home or hotel room so that your phone has no chance of transmitting messages to you until they have dealt with it. Or they might simply construct a plausible pretense, such as a fire alarm going off and agents-dressed-as-firefighters checking the place. Even if they fail to convince you, you will not be able to react in any meaningful way to the alerts you receive. Even if you were close enough to do anything at all, you would not physically attack agents of a secret police that makes people disappear, would you?

What Haven is trying to sell is the illusion of control where the power differential is clearly in favor of the opponent. Haven sells this illusion to well pampered westerners and exploits their lack of experience with repression. To fall for Haven you have to believe the  premise that repression means a secret police in an otherwise unchanged setting. This premise is false: A secret police making people disappear exists inevitably in a context that limits your access to institutions like courts or media or the amount of support you can expect from them. Secret communication as supported by Haven does not even try to address this problem.

While almost everyone understands the problems with low-level snake oil and how to detect and avoid it, securitoys and application layer snake oil continue to fool (some) journalists and activists. Here are a few warning signs:

  1. Security is the only or primary function of a new product or service. Nothing interesting remains if you remove it.
  2. The product or service is being advertised as a tool to evade repression by states.
  3. The threat model and the security goals are not clearly defined and there is no sound argument relating the threat model, security goals, and security design.
  4. Confidentiality or privacy are being over-emphasized and encryption is the core security function. Advertising includes references to “secure” services like Tor or Signal.
  5. The product or service purports to solve problems of operational security with technology.

When somebody shows you a security tool or approach, take the time to ponder how contact with the enemy would end.

Wechselnde Prioritäten

Sicherheit ist schwer, weil das Angreiferverhalten nicht einmal statistisch konstant bleibt. Diese Erfahrung machte auch die DDR kurz vor ihrem Ableben:

Jahrzehntelang hatte man sich intensiv auf einen militärischen Konflikt mit dem Klassenfeind vorbereitet. Dem preußischen Militarismus stand die DDR in nichts nach und die männliche Bevölkerung war hervorragend  militärisch ausgebildet. Der Einsatz der Armee gegen das eigene Volk kam auch deshalb nicht in Frage – es hätte sich zu wehren gewusst und die Armee war fürwahr eine Volksarmee.

Verbraucherschutz ist auch nur Populismus

Der Deutschlandfunk nahm die Pleiten von Air Berlin und Monarch Airlines zum Anlass, mit Klaus Müller, Vorstand des Verbraucherzentrale Bundesverbands (vzbv), über verfallende Flugtickets zu sprechen. Er fordert eine Pflicht zur Insolvenzversicherung, wie sie seit Jahren für Pauschalreisen gilt, und begründet seine Forderung so:

»Weil hier die Politik und auch die Flugbranche seit Jahren ihre Hausaufgaben nicht gemacht haben. Weil wir nicht wie bei Pauschalreisen zum Beispiel eine Insolvenzversicherung haben. Sprich: Der Kunde, der früh die Tickets schon bezahlt hat, bevor er eine Leistung bekommen hat, ist zurzeit der Depp. Er steht da ohne eine Leistung und verliert sein Geld, seine Urlaubsfreude. Das ist einfach nicht in Ordnung. Das ist Politik- und Marktversagen.«

(DLF: Fluglinien-Pleiten und Verbraucher – Airlines sollten Insolvenzversicherung anbieten)

Das ist populistische Kackscheiße. Versicherungen sind sinnvoll gegen existenzbedrohende Risiken, die sie auf ein Kollektiv umlegen. Deswegen sollte jeder ein Haftpflichtversicherung haben, Hausrat muss man abwägen und Händi-, Fahrrad- oder Reiserücktrittsversicherungen sind sinnlos.

Schäden, für die man anderen ersatzpflichtig ist, kann man leicht versehentlich verursachen, und wenn etwa Menschen verletzt werden oder Gebäude niederbrennen, wird es teuer. Das ist ein klarer Fall für eine Versicherung, die für besonders riskante Fälle wie den Betrieb von Kraftfahrzeugen sogar vorgeschrieben ist. Ebenfalls unverzichtbar ist eine Krankenversicherung, denn Krankheitskosten können schnell das Vermögen übersteigen und sparen lässt sich daran schlecht.

Eine Hausratversicherung ist schon nicht mehr so eindeutig nötig. Wer zu Hause keine Wertsachen hortet und ausreichende liquide Reserven hat, kann selbst dem Totalverlust seines Hausrats, etwa durch einen Brand,  vergleichsweise gelassen entgegensehen. Natürlich wäre so etwas ärgerlich, aber eben doch zu verschmerzen. Für andere mag eine Versicherung attraktiv sein, weil sie weniger Reserven haben oder ihr Hausrat einen höheren Wert.

Komplett unnütz sind Kleinkramversicherungen gegen ärgerliche, aber überschaubare Schäden: Händiverlust, Fahrraddiebstahl, Hochzeitsrücktritt und so weiter. Solche nach oben begrenzten Risiken kann man selbst tragen und man kommt im Mittel auch nicht günstiger davon, wenn man sie versichert. Diese unnützen Versicherungen versprechen den Versicherern jedoch ein gutes Geschäft und man bekommt sie allerorten aufgeschwatzt.

Vor schlechten Geschäften, mit denen uns Versicherer bei ungenügender Gegenleistung Geld aus der Tasche ziehen, sollten uns Verbraucherschützer wie Klaus Müller eigentlich warnen und manchmal tun sie das auch. Die Forderung nach einer Zwangsversicherung einzelner Risiken passt dazu nicht und die vorgebrachten Argumente sind so fadenscheinig, dass man sie leicht gegen die Forderung wenden kann:

»Ich finde, 100.000 Einzelfälle sind schon eine ganze Menge.«


Das sind sie in der Tat – aber eben auch dann, wenn man ihnen für jeden Flug ein paar Euro extra aus der Tasche zieht, ob sie wollen oder nicht. Politik- und Marktversagen wäre es, mich zum Kauf einer Leistung zu nötigen, die ich nicht will und die auch keinen berechtigten Interessen meiner Mitmenschen dient.

Verdient „cyber“ so viel Aufmerksamkeit?

Millionen Euro
Schäden durch Cybercrime (2016) 51
Jahresetat des BSI (2016) 89
Schäden durch Fahrraddienbstahl (2014) 100
Jahresetat des BSI (2017) 107
Schaden durch NotPetya bei Maersk 170…256
Schaden durch organisierte Kriminalität (2016) >1.000
Schäden durch Ladendiebstahl 2.000
Schäden durch Wirtschaftskriminalität (2011) 4.100
Rundfunkgebühren (2015) 8.131
Verkehrsinfrastrukturinvestitionen (2016) 12.296
Schaden aus Cum-Ex- und Cum-Cum-Betrug (kumuliert) 31.800
Verteidigungshaushalt (2017, inkl. CIR) 37.005
Bürokratiekosten der Wirtschaft pro Jahr 45.140
Unbelegte Cyberschadensdrohung von Bitkom und Verfassungsschutz 50.000
Googles weltweiter Umsatz (2016) 79.450
(89.460 $)
Jährlicher Umsatzverlust durch schlechte Führungskräfte 105.000
Umsatz im Lebensmitteleinzelhandel (2016) 176.000
Bundeshaushalt (2017) 329.100
Bruttoinlandsprodukt (2016) 3.124.364
(3.466.639 $)

Cyberzeilen sind fett markiert. Zu jeder Zahl ist die Quelle verlinkt. Ich aktualisiere die Tabelle ab und zu mit weiteren Angaben.

Can Penetration Testing Trigger Change in Development Teams?

Software penetration testing has become a common practice in software companies. Penetration testers apply exploratory testing techniques to find vulnerabilities, giving developers feedback on the results of their security efforts—or lack thereof. This immediate benefit is mostly uncontested, although it comes with the caveat that testers find only a fraction of the present vulnerabilities and their work is rather costly.

Security experts commonly recommend that developers should respond to the results of a penetration test not merely by fixing the specific reported vulnerabilities, but rather analyze and mitigate the root causes of these vulnerabilities. Just as commonly, security experts bemoan that this does not seem to happen in practice. Is this true and what prevents penetration testing from having an impact beyond defect fixing?

Studying Software Developers

We studied this question by observing a product group of a software company over the course of a year. The company had hired security consultants to test one of its products for security defects and subsequently train the developers of this product. We wanted to know how effective this intervention was as a trigger for change in development. To this end we conducted two questionnaires, observed the training workshop, analyzed the contents of the group’s wiki and issue tracker, and interviewed developers and their managers.

The product group in our study comprised several Scrum teams, development managers, and product management. Scrum is a management framework for agile software development. Scrum defines three roles—Development Team, Product Owner, and Scrum Master—and artifacts and ceremonies for their collaboration. The Development Team is responsible for and has authority over technical matters and development work; the Product Owner is responsible for requirements and priorities; and the Scrum Master facilitates and moderates their collaboration.

The participants of our study appreciated the penetration test results as feedback and the training workshop as an opportunity to learn. They managed to address the particular vulnerabilities reported by the consultants. They also felt that security needed more attention in their development work. Yet, after addressing the vulnerabilities uncovered by the penetration test, they returned to their familiar ways of working without lasting change.

Analyzing our observations through the lens of organizational routines, we found three key factors inhibiting change in response to the penetration test and training: successful application of existing routines, the organizational structure of roles and responsibilities, and the overall security posture and attitude of the company.

(1) Existing Routines

To address the immediate findings of the penetration test, our developers used an existing bug-fixing and stabilization routine. Defect reports arrive asynchronously and sometimes require quick response; developers therefore commonly dedicate some—variable—percentage of their working time to defect fixing in response to reports. The penetration test fed the team dozens of new defects at once, but developers hat a routine to deal with it. Moreover, management tracked the number of open defects, so that the sudden increase raised attention and created pressure on the team to get this number down.

Feature development, on the other hand—where change would have to occur—remained mostly unaffected. Feature development followed the process of Scrum and the penetration test neither had a specific impact here nor did it feed requests or ideas into this routine.

(2) Organizational Structure

Following the ideas of Scrum and agile development, a strong division of labor and responsibilities characterized the organizational structure in the setting of our study. Product management and product owners were responsible for the direction of the development work, whereas development teams enjoyed a certain autonomy in technical questions. This structure worked as a social contract: managers expected developers to take care of security as a matter of quality and developers were keen to deliver the features requested by management. However, the penetration test had little impact on the manager’s priorities beyond the pressure to reduce the number of open defects. The developers thus found themselves in a situation where security was not explicitly required and additional security work could not be justified.

(3) Business Role of Security

Finally, security had limited perceived importance for the business of the studied company, which thus far had not experienced any public security disaster and did not actively sell security. The company therefore lacked a security narrative that could have been used to justify security efforts beyond defect fixing. This, together with the inherent low visibility of security and insecurity, shaped priorities. Product managers knew that features sell their products—new features are easy to show and explain, whereas security improvements are not. Security was perceived as contributing little to the success of the product and the company, making it a low-priority requirement.

Our study points to some of the complexities of managing software development and of triggering change by interventions. While it would be tempting to assign blame to a single factors, such as agile development or negligent management, the problem is really more complicated. Organizational structures and routines exist and they are shaped by business needs. Scrum, for example, is highly beneficial for the studied company. One might even ask whether the company’s dealing with security is a problem in the first place. Are they perhaps doing the right thing for their market and customers?

Our Paper:

A. Poller, L. Kocksch, S. Türpe, F. A. Epp; K. Kinder-Kurlanda: Can Security Become a Routine? A Study of Organizational Change in an Agile Software Development Group. Proceedings of the 2017 ACM Conference on Computer Supported Cooperative Work and Social Computing (CSCW’17), February 25–March 1, 2017, Portland, OR, USA.
[DOI: 10.1145/2998181.2998191, BibTeX, slide deck]

Von der Datentransaktion zur Datenemission

Datenschutz ist regelmäßig ein Thema in diesem Blog, denn seine Schutzziele und Mechanismen überschneiden sich mit denen der IT-Sicherheit oder stehen mit ihnen in Wechselwirkung. Datenschutz ist auch regelmäßig der Gegenstand öffentlicher Debatten. Das ist einerseits verständlich, denn wir sind heute überall von vernetzter IT umgeben. Andererseits verlaufen solche Debatten oft bizarr, weil der Datenschutz politisch instrumentalisiert und mit sachfremden Aspekten vermischt wird. Dabei ist die Frage für sich und ohne Ballast schon schwer genug: Was soll, was kann, was bedeutet Datenschutz heute und in Zukunft?

Mit einem Aspekt dieser Frage habe ich mich zusammen mit Jürgen Geuter und Andreas Poller in einem Beitrag zur Konferenz Die Zukunft der informationellen Selbstbestimmung des Forums Privatheit Ende 2015 beschäftigt, der jetzt endlich im Konferenzband erschienen ist. Wir beschäftigen uns darin mit der Frage, wie sich die Paradigmen der Informationstechnologie seit der Entstehungszeit des deutschen Datenschutzrechts verändert haben und unter welchen Bedingungen Persönlichkeitsrechte im Zusammenhang mit der Datenverarbeitung heute geschützt werden sollen.

Der Datenschutz hat seine Wurzeln in den 1970er und 1980er Jahren. Das vorherrschende Verarbeitungsparadigma der EDV, wie man die IT damals nannte, war das der Datenbank. Darauf sind die Regeln des BDSG erkennbar zugeschnitten; sie geben der Datenerfassung und -verarbeitung ein Gerüst aus expliziten Transaktionen zwischen Betroffenen und verarbeitenden Stellen, mit denen die Betroffenen ihr Recht auf informationelle Selbstbestimmung wahrnehmen.

Heute prägen andere Paradigmen die Informationstechnik: die allgegenwärtige Vernetzung, die eine detaillierte Kontrolle durch explizite Transaktionen unpraktikabel macht, und das maschinelle Lernen, welches das Verständnis der Verarbeitungsvorgänge und die Einflussnahme darauf erschwert. Die Vorstellung einer expliziten Datenerhebung nebst informierter Einwilligung passt deshalb nicht mehr zur Technik und ihren vielfältigen Anwendungen.

Wir haben die neuen Bedingungen in eine Emissionsmetapher gepackt: Jeder von uns sendet fortlaufend Daten aus, die sich im Netz verbreiten und dort von verschiedenen Akteuren aufgefangen und verarbeitet werden, vergleichbar der Art und Weise, wie sich Licht von einer Lichtquelle im Raum ausbreitet. Das schließt Eingriffe nicht aus, aber sie müssen auf diese Verhältnisse zugeschnitten sein. Eine umfassende Lösung dafür können wir nicht präsentieren, aber wir diskutieren einige Ansätze.

Der ganze Beitrag:

Sven Türpe; Jürgen Geuter; Andreas Poller: Emission statt Transaktion: Weshalb das klassische Datenschutzparadigma nicht mehr funktioniert. In: Friedewald, M.; Roßnagel, A.; Lamla, J. (Hrsg.) (2017): Informationelle Selbstbestimmung im digitalen Wandel. Wiesbaden: Springer Vieweg DOI: 10.1007/978-3-658-17662-4_14, © Springer. [BibTeX]

Was heißt hier „cyber“?

Die Cyberwehr dient Neuland. Was heißt das?

Seit einigen Jahren und erst recht seit der Ankündigung des Verteidigungsministeriums, die Bundeswehr um das eben aufgestellte Kommando Cyber- und Informationsraum (KdoCIR) als neue Teilstreitkraft zu erweitern, reden alle vom Cyberkrieg. Die Online-Armee soll „Waffensysteme und Computernetze der Bundeswehr schützen, aber auch zu Angriffen in der Lage sein.“

Konkreter wird die öffentliche Diskussion selten. Von hackenden Russen und Chinesen (Spy vs. Spy?) – seltener: Amerikanern et al. – mit staatlichem Auftrag ist öfter die Rede und gelegentlich erinnert jemand an Stuxnet als erste „Cyberwaffe“. Was, wenn jemand so eine Cyberwaffe gegen kritische Infrastrukturen wie die Wasser- oder Energieversorgung unseres Landes einsetzt? Müssen wir da nicht zurückschlagen können?

Jetzt haben wir also eine Cyberwehr, die irgendwas mit Internet, Hacking und IT-Sicherheit macht, auch offensiv und im Ausland, um uns vor sowas zu beschützen. Wann braucht sie dafür ein Bundestagsmandat oder Routingrechte für die Cyber- und Informationsräume anderer Staaten? Wo verlaufen die Grenzen zwischen Angriff und Verteidigung? Ergeben solche Fragen überhaupt einen Sinn und was unterscheidet das Cybermilitär von der Security-Abteilung eines Unternehmens?

Die öffentliche Berichterstattung und Diskussion wirft munter verschiedene Dimensionen des Themas durcheinander. Ich sehe mindestens drei verschiedene Aspekte:

  1. „Cyber“ als IT-Betrieb und Sicherheitsmanagement, wie wir sie kennen: Jede Organisation muss sich um den sicheren Betrieb und das Sicherheitsmanagement ihrer vernetzten Systeme kümmern, so auch die Bundeswehr. Das ist in erster Linie eine Admin- und Abwehraufgabe und für eine Armee die Ausdehnung von Wachdienst und Spionageabwehr ins Internet sowie auf die militärischen Kommunikationssysteme und die IT der Waffensysteme. Bundestagsmandate braucht man dafür so wenig wie für das zivile Gegenstück nach BSI-Kompendium. Soldaten braucht man dafür auch nur bedingt; die Bundeswehr könnte auch einen IT-Dienstleister beauftragen.
  2. „Cyber“ als Erweiterung des Waffenarsenals und Operationsraums: Im Rahmen militärischer Einsätze werden zusätzlich oder alternativ zu herkömmlichen Waffen auch „Cyberwaffen“ eingesetzt, das heißt das Ziel der Operation wird auch durch Eingriffe in Netze und IT-Systeme verfolgt. Statt Bomben auf Kraftwerke zu werfen, könnte die Truppe beispielsweise versuchen, den Strom im Operationsgebiet mit anderen Mitteln abzuschalten. Für solche Einsätze braucht die Bundeswehr ohnehin ein Mandat.
    Abzuwarten bleibt, wie gut „Cyberwaffen“ in diesem Zusammenhang wirklich funktionieren. Kanonen, Gewehre, Geschosse und Bomben haben den Vorteil, im Kern sehr einfachen Funktionsprinzipien zu folgen. Sie lassen sich massenhaft herstellen und unter Feldbedingungen flexibel gegen verschiedene Ziele einsetzen. Ob es eine gute Idee ist, die Energieversorgung zu hacken, statt ein Kommando ins oder Bomber übers Kraftwerk zu schicken, wird sich zeigen.
  3. „Cyber“ als neuer Raum für Konflikte geringer Intensität: Die Informationstechnik ermöglicht auch neuartige Aktionsformen unterhalb der Schwelle zum offenen militärischen Konflikt. Stuxnet ist das prominenteste Beispiel: Ein Staat verfolgt Ziele im Ausland durch Eingriffe in fremde IT-Systeme. Solche Operationen haben eher einen geheimdienstlichen als einen militärischen Charakter.
    Solche Operationen sind neu und international gibt es damit wenig Erfahrung, deshalb stellen sich hier die interessanten Fragen: Was ist ein militärischer Angriff, was nur ein unfreundlicher Akt? Welche Ziele sind legitim, welche Antworten angemessen? Und wie findet überhaupt heraus, wer der Angreifer war? Aufgrund der geheimdienstlichen Natur solcher Operationen wäre die Forderung nach einem vorher zu erteilenden spezifischen Bundestagsmandat kontraproduktiv. Stuxnet illustriert all diese offenen Fragen.

Um qualifiziert und zielführend zu diskutieren, müssen wir uns auf klare gemeinsame Begriffe einigen. Wenn Euch jemand vollcybert oder von hybriden Bedrohungen schwätzt, dann fragt ihn also erst einmal, wovon er eigentlich redet. Denkt daran: „Cyber“ ist immer für eine Geschichte gut und nicht alle Geschichten stimmen auch.

(Getriggert von Holger Schauer bei G+)

PS: Thomas Wiegold erklärt nüchtern, was das KdoCIR tut. Außerdem gibt’s dort die Rede der Vercyberungsministerin zum Anhören und auszugsweise zum Nachlesen.

CfP: 3rd Workshop on Security Information Workers (WSIW 2017)

There will be another edition of WSIW this year and it will be part of SOUPS again, which is in turn co-located with the Usenix Annual Technical Conference. WSIW is concerned with  all kinds of security information work and the people doing such work, like developers, administrators, analysist, consultants, and so on. We were there last year with early results of our penetration testing in software development study. If the subject of your reseach is security work, please consider submitting to WSIW.


Workshop website:

Submissions due: 2017-05-25

Vortrag: „Security by Design?“

Triggerwarnung: work in progress

Vergangene Woche durfte ich auf dem 1. IT-Grundschutztag 2017 zum Thema Security by Design? vortragen. Das Leitthema der Veranstaltung war Application Security und ich habe passend zu unserer Forschung einen Blick auf die Softwareentwicklung geworfen. Sichere Software ist leicht gefordert, aber die Umsetzung im Entwicklungsalltag bereitet Schwierigkeiten: In frühen Phasen der Entwicklung kämpft man mit Ungewissheit und es ist schwer, Entscheidungen zu treffen; später weiß man mehr, aber die Veränderung wird schwierig – nicht nur technisch, sondern auch in den Strukturen und Routinen des Entwicklerteams.

Der Vortrag entstand aus einer früheren Fassung, die ich gemeinsam mit Andreas Poller auf dem Workshop „Partizipatives Privacy by Design“ im vergangenen Oktober in Kassel gehalten habe. Aus Andreas’ Vortrag auf der CSCW’17 habe ich mir auch Slides geborgt.

Wer die Tonspur zu den Slides hören möchte: einfach fragen.

What the Cypherpunks Got Wrong

Cypherpunk ideas have a long legacy and continue to influence how we are discussion matters of security and privacy, particularly in the relationship between citizens and governments. In a nutshell, cypherpunks posit that we can and should keep government intervention minimal by force-protecting our privacy by means of encryption.

Let us begin with what they got right:

“For privacy to be widespread it must be part of a social contract.”

 (Eric Hughes: A Cypherpunk’s Manifesto)

Social contracts are the basis of every society; they define a society and are represented in its formal and informal norms. Privacy is indeed a matter of social contract as it concerns very fundamental question of what the members of a society should know about each other, how they should they should learn it, and how they may or may not use what they know about others.

Privacy is not merely a matter of hiding information so that it cannot be found. The absence of expected features or utterances carries information, too. Some societies, for example, expect their members to actively demonstrate their allegiance. Members of such a society cannot merely hide what they think, they also have to perform their role as expected if they have no desire to become a leper.

What the cypherpunks got entirely wrong was their conception of social contracts and the hope that cryptography could be the foundation upon which they, the cypherpunks, would build their own. Cypherpunks believe that cryptography would allow them to define their own social contract on top of or next to the existing ones. This has not worked and it cannot work. On the one hand, this is not how social contracts work. They are a dimension of a society’s culture that evolves, for better or worse, with this society.

On the other hand, cryptography–or security technology in general–does not change power relationships as much as cypherpunks hope it would. Governments are by definition institutions of power: “Government is the means by which state policy is enforced.” Cypherpunks believe that cryptography and other means of keeping data private would limit the power of their governments and lay it into the cypherpunks’ hands. However, the most fundamental power that any working government has is the power to detain members of the society it is governing.

In an echo of cypherpunk thinking, some people react to an increased interest of the U.S. Customs and Border Protection (CBP) in travelers’ mobile devices with the suggestion to leave those devices at home while traveling. After all, the CBP cannot force you to surrender what you do not have on you, so the reasoning. This thinking has, however, several flaws.

First, from a security point of view, leaving your phone at home means to leave it just as unattended as it would be in the hands of a CBP agent. If the government really wants your data, nothing better could happen to them than getting access to your phone while you are not even in the country.

Second, the government is interested in phones for a reason. Cryptography and other security mechanisms do not solve security problems, they only transform them. Cryptography in particular transforms the problem of securing data into a problem of securing keys. The use of technology has evolved in many societies to the point where our phones have become our keys to almost everything we do and own online; they have become our primary window into the cloud. This makes phones and the data on them valuable in every respect, for those trying to exert power as well as for ourselves. You lose this value if you refrain from using your phone. Although it seems easy to just leave your phone at home, the hidden cost of it is hefty. Advice suggesting that you do so is therefore not very practical.

Third, this is not about you (or if it is, see #1 above). Everyone is using mobile phones and cloud services because of their tremendous value. Any government interested in private information will adapt its approach to collecting this information to the ways people usually behave. You can indeed gain an advantage sometimes by just being different, by not behaving as everyone else would. This can work for you, particularly if the government’s interest in your affairs is only a general one and they spend only average effort on you. However, this same strategy will not work for everyone as everyone cannot be different. If everyone left their phones at home, your government would find a different way of collecting information.

By ignoring a bit of context, cypherpunks manage to arrive at wrong conclusions from right axioms:

“We cannot expect governments, corporations, or other large, faceless organizations to grant us privacy out of their beneficence.”

“We must defend our own privacy if we expect to have any.”

(Eric Hughes: A Cypherpunk’s Manifesto)

This is true, but incomplete. Power must be contained at its source (and containment failures are a real possibility). Cryptography and other security technology does not do that. Cryptography can perhaps help you evade power under certain circumstances, but it will by no means reverse power relationships. What you really need is a social contract that guarantees your freedom ad dignity.


(Expanded version of a G+ comment)


Encryption Will Not Give You Free Speech

“Freedom of speech is the right to articulate one’s opinions and ideas without fear of government retaliation or censorship, or societal sanction.”Wikipedia

Reports of a vulnerability in WhatsApp are making the rounds today after The Guardian boosted the signal. Besides the fact that there is not really a backdoor, but rather a feature that represents a reasonable choice in a tradeoff between confidentiality and availability, the Guardian also repeats a common mistake: confounding encryption and free speech.

“Privacy campaigners criticise WhatsApp vulnerability as a ‘huge threat to freedom of speech,’” writes The Guardian. This is bullshit. As per the definition cited above, free speech means you can say things without fear. Being able to say things only in private and needing strong technical privacy guarantees is the opposite of free speech. You need encryption for that which you cannot say without fear.

Yes, encryption can be a tool against those who suppress you (though a weak one, as your adversary can easily use your use of encryption against you – or deny you due process altogether and persecute you without any trace of evidence and probable cause). But encryption will never give you free speech, it will only support your inner immigration.

Re: Offener Brief zu DNA-Analysen in der Forensik

Mahnungen vor dräuenden Gefahren verkaufen sich immer, sind doch vorhergesagte Probleme nie auszuschließen, ohne dass man ein Risiko eingeht und etwas ausprobiert. So lässt sich beliebig lange spekulieren, was alles passieren könnte, wenn man täte, was man wegen der Risiken besser bleiben ließe. Als neuester Gegenstand solcher „kritischen“ Betrachtungen bietet sich die Forderung nach einer Ausweitung der zulässigen DNA-Analysen in der Polizeiarbeit an. Folgerichtig haben Sozialwissenschaftler einen Offenen Brief zu DNA-Analysen in der Forensik verfasst der zur Vorsicht mahnt und seine Autorinnen als unverzichtbare Expertinnen anbietet. Der Tenor: Erweiterte DNA-Analysen seien viel zu kompliziert als dass man einfache Polizisten unbegleitet mit ihren Ergebnissen arbeiten lassen dürfe. Am Ende steht wenig mehr als die Schlussfolgerung, dass es zu Fehlern kommen könne. Dies jedoch ist eine banale Aussage: Fehler sind in der Polizeiarbeit Alltag und das System aus Gesetzgebung, Polizei und Justiz kann damit gut umgehen. Selbstverständlich muss man die Auswirkungen neuer Methoden betrachten, aber zur Panik gibt es keinen Anlass. Unser Rechtsstaat irrt sich recht zuverlässig zugunsten der Verdächtigen und die Forensiker wissen selbst ganz gut, wo die Grenzen der verschiedenen Analyseverfahren liegen. Unschätzbare Risiken können wir jeder Technik unterstellen, das hilft nur niemandem.


An In-Depth Study of More Than Ten Years of Java Exploitation

My colleagues Philipp Holzinger, Stefan Triller, Alexandre Bartel, and Eric Bodden had a closer look at Java and the vulnerabilities discovered in the Java runtime environment during the last decade. They started from known exploits, identified the vulnerabilities exploited, and analyzed and grouped their root causes. Philipp’s presentation of the results at CCS’16 has been recorded and published on YouTube:


The paper is also available online:

P. Holzinger, S. Triller, A. Bartel, E. Bodden: An In-Depth Study of More Than Ten Years of Java Exploitation. Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS’16), Vienna, Austria, Oct. 24-28, 2016. DOI: 10.1145/2976749.2978361. Artifacts: