A classification of CTI Data feeds

(Crossposted on the blog.)

I was recently involved in discussions about the procurement of Cyber Threat Intelligence (CTI) feeds. This lead to discussions on the nature of CTI and what to do with it. Here is how I see this topic.

One way to structure and classify CTI feeds is to look at the abstraction level at which they operate. As Wikipedia puts it: 

  • Tactical: Typically used to help identify threat actors (TAs). Indicators of compromise (such as IP addresses, Internet domains or hashes) are used and the analysis of tactics, techniques and procedures (TTP) used by cybercriminals is beginning to be deepened. Insights generated at the tactical level will help security teams predict upcoming attacks and identify them at the earliest possible stages.
  • Operational: This is the most technical level of threat intelligence. It shares hard and specific details about attacks, motivation, threat actor capabilities, and individual campaigns. Insights provided by threat intelligence experts at this level include the nature, intent, and timing of emerging threats. This type of information is more difficult to obtain and is most often collected through deep, obscure web forums that internal teams cannot access. Security and attack response teams are the ones that use this type of operational intelligence.
  • Strategic: Usually tailored to non-technical audiences, intelligence on general risks associated with cyberthreats. The goal is to deliver, in the form of white papers and reports, a detailed analysis of current and projected future risks to the business, as well as the potential consequences of threats to help leaders prioritize their responses.

With tactical CTI, there a reasonable chance that it can shared on a machine-to-machine basis with full semantic information that makes it possible to automate the processing for detection and prevention purposes. Many commercial security devices are sold with a subscription to the vendor’s own data-feeds. This ranges from simple anti-spam solutions, over filters for web proxies to rules for SIEMs.

While it is possible to encode operational CTI in standardized data exchange formats like STIX2, it is much harder for automated systems to operationalize this information. For example, what automated technical reaction is possible to “threat actor X is now using compromised CPEs in the country of its targets for C2 communication”? Yes, one can store that kind of information in OpenCTI (or a similar Threat Intelligence Platform (TIP)) and map it to the ATT@CK framework. That can be valuable for the human expert to plan defenses or to react better during incidents, but it is not detailed enough automated defense.

With strategic CTI, we are on the human management layer. This is never designed for automated processing by machines.

Types of IOCs

Focusing on the technical layer, we find that there are a number of different types of information encoded in the data feeds. One way to look at this is the Diamond Model of intrusion analysis which is built around information on adversary, capability, infrastructure, and victim. While this is a very valuable model for intrusion analysis, it is too complex for a simple categorization of CTI feeds.

I propose the following three basic types:

Type 1: Attack Surface Information

Many of the feeds from Shadowserver fall in this category. Shodan data can also be a good example. There is now a bunch of companies focusing on “cyber risk rating”, which all try to evaluate the internet-visible infrastructure of organizations.


  • “On IP-address A.B.C.D, at time X, we detected a Microsoft Exchange server running a version that is vulnerable to CVE-202X-XXXX”.
  • “The time-server at IP addres Y can be abused as ddos-reflector.”
  • “On IP address Z, there is an unprotected MongoDB reachable from the Internet.”

Notable points are:

  • This is very specific information about a concrete system. Usually, it is very clear who is responsible for it.
  • There is no information about an actual compromise of the listed system. The system might be untouched or there may already be a number of webshells deployed on it.
  • There is no information about an attacker.
  • This is sensitive (potentially even GDPR-relevant) information.
  • This information is (almost) useless to anybody but the owners of the system.
  • Thus, the coordinating CSIRT should pass this information on to the maintainers of this system and to nobody else. is usually tagging these events with “vulnerable / vulnerable system” or “vulnerable / potentially unwanted accessible service”.

Expected response from system owner: 

  • Mitigate the threat by patching / upgrading / removing the system or maybe even accept the risk (e.g. “yes, we really want to run telnet enable on that server”).
  • Verify that the system has not been breached yet.

Type 2: Threat Actor IOCs

This is the opposite: the information is solely about the threat actor and the resources this group is using, but there is no clear information on the targets. Typical information contained in these IOCs is:

  • The domain-name of a command & control (C2) server of the TA
  • An IP address of a C2 server
  • Filename and/or hash of malware used by the TA
  • Email subject, sender and sending IP address of a phishing mail
  • Mutex names, registry-keys or similar artefacts of an infection
  • URL-pattern of C2 connections


  • A RAT Remcos campaign was detected 2023-06-14 to use
    • Mutex: Rmc-MQTCB0URI: /
    • Email-attachment: Shipment_order83736383_document_file9387339.7z
    • MD5: 2832aa7272b0e578cd4eda5b9a1f1b12
    • Filename: Shipment_order837363.exe

Notable points are:

  • This is detailed information about a threat actor infrastructure, tools and procedures.
  • There is often no information about targets of these attacks. Sometimes, some targeting information is known, like “This TA usually attacks high-tech companies”.
  • This information is potentially useful for everybody who that actor might target.
  • Unless one thinks that attacker IP-addresses deserve GDPR-protection, this data has no privacy implication.
  • Thus, the coordinating CSIRT should pass this information on to all constituents who are capable of operationalizing such CTI. is usually not sending this kind of information pro-actively to all constituents, instead we operate a MISP instance which holds these IOCs. Security automation on the side of the constituent is welcome to use the MISP APIs to fetch and process the IOCs.
  • If the targeting of the TA is sufficiently well known and specific, will pass on the IOCs directly to the constituent’s security team.
  • In rare cases, the TA is abusing infrastructure of one of our constituents. In that case, we have a mix with the next type of CTI.

Expected response from system owner:

  • Add the IOCs to any sort of incident prevention system, e.g., filter lists in proxies, EDR or AV software.
  • Add the IOCs to the incident detection system, e.g., create suitable rules in SIEMs.
  • Ideally, also perform a search in old logs for the newly acquired IOCs.

Type 3: Infection data

Sometimes we receive cyber threat information that is very specific and concerns a live incident inside a constituent’s network.

Examples are:

  • “We detected at timestamp X a webshell placed on a Citrix server. IP-address = A.B.C.D, path = /logon/LogonPoint/uiareas/mac/vkb.php”
  • “Our darknet monitoring detected that someone is selling VPN credentials for on the platform X”
  • “After a takedown of botnet X we are monitoring botnet drone connections to the former C2 servers. On [timestamp], the IP address A.B.C.D connected to our sinkhole.”
  • “We managed to get access to the infrastructure of threat actor X. According to the data we found there, your constituent Y is compromised.”
  • “Please find below information on IPs geolocated in your country which are most likely hosting a system infected by SystemBC malware. […] Timestamp, IP-address, hostname, c2 ip-address”
  • “There are signs of malicious manipulations on the Website of domain X, there is a phishing page at /images/ino/95788910935578/login.php”

Notable points are:

  • This is usually very specific information about a live incident involving a concrete system.
  • In the best case, the information is good enough to trigger a successful investigation and remediation.
  • The threat actor is often, but not always, named.
  • This is sensitive (potentially even GDPR-relevant) information.
  • This information is (almost) useless to anybody but the owners of the system.
  • This information can be very time-sensitive: a quick reaction can sometimes prevent a ransomware incident.
  • Thus, the coordinating CSIRT should pass this information quickly on to the maintainers of this system and to nobody else. is usually tagging these events with “intrusions / system-compromise” or “fraud / phishing”

Expected response from system owner:

  • Start the local incident response process.
  • Clean up the known infection and investigate the possibility of additional compromises in the affected network (lateral movement?).

Tooling is using IntelMQ to process feeds of type 1 and 3. CTI feeds of type 2 are handled by our MISP installation.

CERT Internet

Boeing vs. Microsoft

2019: Boeing uses a single “angle of attack” sensor to control the automatic pitch control software (MCAS). A software upgrade to use both AOA sensors was sold as an optional extra. Result: two planes crashed, killing 346 people. The damages and the subsequent grounding of the whole 373 Max fleet cost Boeing a few billion dollars.

2023: Microsoft sold access to advanced logs in their MS-365 service as an add-on, premium product. Luckily, someone did buy it, and used the data provided to detect a significant intrusion in the whole Azure infrastructure.

For good or bad, we do not treat security as seriously as safety.


I think this will change for critical infrastructure.

Microsoft should think hard what that would mean. If one can ground a fleet of planes for safety reasons, I see no fundamental reason not to temporarily shut down a cloud service until it can prove that it solved a design flaw.

We just need a regulatory authority with a bit more desire to be taken seriously.


A network of SOCs?

Crossposted on the blog.


I wrote most of this text quickly in January 2021 when the European Commission asked me to apply my lessons learned from the CSIRTs Network to a potential European Network of SOCs. During 2022, the plans for SOC collaboration have been toned down a bit, the DIGITAL Europe funding scheme proposes multiple platforms where SOCs can work together. In 2023, the newly proposed “Cyber Solidarity Act” builds upon this and codifies the concept of a “national SOC” and “cross-border SOC platforms” into an EU regulation.

At the CSIRTs Network Meeting in Stockholm in June 2023 I gave a presentation on  the strenghts and flaws in the CSoA approach. A position paper / blog-post on that is in the works.

The original text (with minor edits) starts below.


The NIS Directive established the CSIRTs Network (CNW) in 2016, and the EU Cybersecurity Strategy from 2020 tries to do something similar for SOCs (Security Operation Centres).

I was asked by DG-CNECT to provide some lessons identified from the CWN that might be applicable for the SOC Network (SNW).

The following points are not a fully fleshed out whitepaper, instead they are a number of propositions with short explanations.

The most important point is that one cannot just focus on the technical aspects of SOC collaboration. That is the easy part. We know which tools work. The same stack that we developed for the CSIRTs Network can almost 1:1 support SOC networks.

Our colleagues from CCN-CERT presented the Spanish SOC Network at various meetings recently. Yes, there was one slide with their MISP setup, but the main content was the administrative side and the incentive structure they built to encourage active participation by all members.

Human Element


Any close cooperation needs a basic level of trust between participants. The more sensitive the topic and the more damage could potentially be done by the misuse of information shared between the organisations, the more trust is needed for effective collaboration.

There must be an understanding that one can rely on others to keep secrets, and to actually communicate if something important for the partner is learned.

Trust is not binary

Trust is not a binary thing: There is more than “I trust” or “I don’t trust”; it always depends on the concrete case if you trust someone enough to cooperate in this instance.

Trust needs Time

Some basic level of trust is given to others based on their position (e.g., I trust the baker to sell me edible bread; I trust every police officer to do the basics correctly), but only repeated interactions with the same person/organisation increases the trust over time. (See “The Evolution of Cooperation”)

Thus, one needs to give all these networks time to establish themselves and the trust relationships.

These things really take time. We are talking about years.

Physical meetings (incl. social events) help

Bringing people together is very helpful to bootstrap cooperation.

You can’t legislate Trust

There are limited possibilities to declare ex cathedra that one has to trust someone. It might work do certain degree if people are forced by external events to collaborate (e.g., call the police if you have to deal with a significant crime; or reporting requirements to authorities; or hand your kids over to day-care/school/ …).

Even in these cases, these organisations have to be very careful about their reputation: misuse of their trust positions will significantly affect how much trust is given, even under duress.

Persons or Teams

Trust can be either anchored to persons or to organisations. I might trust a certain barber shop to get my haircut right, but I’ll prefer to go the same person if the cutter got it right the last time.

Experience has shown that is possible to establish institutional trust: If I know that Team X is competently run, then I will not hesitate to use the formal contact point of that team.

Still: if something is really sensitive, I will try to reach the buddy working for that other team with whom I have bonded over beer and common incidents.

Group Size

Close cooperation in groups cannot be sustained if the number of participants increases beyond a certain limit. This has been observed in multiple fora, amongst them FIRST, TF-CSIRT, and ops-t (which was actually an experiment in scaling trust groups).

As a rule of thumb: whenever you cannot have every member of the group present their current work/topics/ideas/issues during a meeting, then the willingness to have an open sharing decreases significantly. This puts the limit at about 15 to 20 participants. If lower levels of cooperation are acceptable, then group sizes can be larger.

Corollary: Group Splits

If a group becomes too big, then there is a chance that core members will split off and create a new, smaller forum for more intense collaboration.

This is similar to what happens with groups of animals: if one pack becomes too big to be viable, it will split up.

Adding members

Organic growth from within the group works best.

An external membership process (as in the CNW, where existing members have no say over the inclusion of a new team from another EU Member State) can be very detrimental to the trust inside the group.



Any level of participation in a network of peers is not free of costs. Nobody in this business has spare time for anything. Even just passive participation via the odd telephone conference or even just reading emails costs time and is thus not free.

Active participation, be it travelling to conferences, working on common projects, manually forwarding information, or setting up Machine to Machine (M2M) communication can carry significant costs. These must not exceed the benefits from the participation in the network.

Corollary: Separate tooling is detrimental to sharing

Sharing information into a network must be as low-friction as possible. If an analyst has to re-enter information about an incident in a different interface to share the data, then the chance is high that it will not happen. Optimally, the sharing option is built into the core systems and the overhead of sharing is just selecting with whom.


The flip side is often not so easy to quantify: what are the concrete benefits of collaboration? If the bean-counters ask to justify the cost, there should be clear business reasons why the costs are worth it. “Interesting discussions” and “being a good corporate citizen” is not a long-term sustainable motivation.

It must be as clear as possible what value each participant will get from such a network.

Beware of freeloaders and the “Tragedy of the Commons” effect.


Networks work best between organisations that are comparable in size, their jobs, and their position in the market. Their technology and informational needs should be roughly the same. They should face similar tasks and challenges. For example, the SOC of VW and the SOC of Renault should have roughly the same job and thus an exchange of experiences and data might be mutually beneficial.

Vendor/customer mix can kill networks

If two members of a network are actually in a vendor/customer relationship in terms of cyber security, then this is a strong detriment to collaboration. Even just a potential sale is tricky: if one member is describing his problem, then someone else should not be in the position to offer his own commercial product of service to address that problem.

I have seen this work only if the representative of the vendor can clearly differentiate between his role as network partner and his pre-sales job. This is the exception, not the rule.

Competition (1)

Ideally, the member of the network should be in no competition to one another. Example: the security team of Vienna’s city hospitals and the equivalent team of the Berlin Charité are a best case: their hosting organisations are working in the same sector, but there is absolutely no competition for customers between those two.

If the hosting organisations are actually competing with each other (see the VW vs. Renault example from above, or different banks), then a cooperation on IT security is not a given. Nevertheless, it is also not impossible, as competitors are often collaborating with respect to lobbying, standardization or interconnection. One positive example I have seen are the Austrian banks, who are cooperating about e-banking security based on the premise that the customers will not differentiate between “e-banking at Bank X is insecure” and “e-banking is insecure”.

Competition (2)

Even trickier is the case of SOCs not just protecting the infrastructure of their respective hosting organisation, but also offering their services on a commercial basis to any customer (“SOC outsourcing”). Anything one SOC shares with the network then potentially helps a direct competitor. Example: both Deloitte and Cap Gemini offer SOC outsourcing and Threat Intel reporting. Their knowledge base is their competitive advantage and why should they share this freely with a competitor when they are selling the same information to a customer?

Such constellations are extremely difficult, but not impossible to manage.

The trick to deal with competition in such networks is to move the collaboration to a purely operational / technical layer. These people are used to deal with their peers in a productive way.

Alignment of interest

This all boils down to

  • Is it a good commercial decision for my SOC to participate in the network?
  • Is it a good commercial decision to share data into the network?


All members must make the clear management decision to participate in such network and must allocate human power to it. In some way, such networks operate a bit like amateur sport clubs or open-source projects: they thrive based on the voluntary work done by their members. I have seen too many cases where such networks fail simply because members lost interest and did not invest time and effort in running them effectively.

Running a network


While not strictly necessary, a paid back-office increases the chances of success significantly. Someone has to organize meetings, write minutes, keeps tracks on memberships, produces reports, and provides an external point of contact.

Doing this on a voluntary basis might work for very small and static networks, where a round-robin chair role can succeed.

Connecting people

Bringing people together is the basis foundation of a collaboration network. Only in the case where the network is only the distribution of information from a handful of central sources to all members (i.e., a one-way information flow), then this might not be needed. This can be done by (in order of importance)

  • Physical meetings (conferences, workshops, …)
  • Continuous low-friction instant messaging
  • Mailing-lists
  • Web-Forums

Generic central tooling

Any network, regardless of topic, needs a few central tooling components:

  • A directory of members (preferably with self-service editing)
  • A file repository
  • An administrative mailing-list
  • A topical mailing-list
  • An instant messaging facility

A decent Identity and Access management covering all these tools is recommended (but not strictly necessary in the first iteration). The toolset created for the CSIRTs Network (MeliCERTes 2) can help here.

Exchange of Information

In the end, the main motivation of such network is information sharing with the intention of making members more effective in their core task. Here are some thoughts on that aspect:

Compatible levels of Maturity

If members are at very different levels of technological and organisational maturity, then any information exchange is of limited value. A common baseline is helpful.

Human to Human

This is the easiest information exchange to get going, and some topics really need to be covered on the human layer: people can talk about experiences, about cases, about what works and what does not.

It is also possible to exchange Cyber Threat Intelligence (CTI) between humans: the typical write-up of a detected APT campaign, including all the Indicators (IoCs) found during the incident response, is exactly that.

This sounds easy, but is costly in terms of human time. On the receiving side, the SOC needs to operationalize the information contained to make the automated systems detect a similar campaign in the local constituency.

Information Management

The way a SOC is gathering, storing, correlating and de-duplicating the CTI that is powering its detection capability is a core element in the SOC internal workflow. Its maturity in this respect drives the possibilities of collaboration on the topic of CTI.

One (not uncontroversial) theory on this topic is the “Pyramid of Pain” concept from David Bianco, where he describes the levels of abstractions in CTI. The lower levels are easy for SIEMs to detect, but also trivial for the threat actor to change. The challenge for SOCs is to operate at a higher level than what the threat actors is prepared to change frequently.


In theory, SOCs should be able to cross-connect their CTI systems to profit from each other’s learnings and thus increase the overall detection capability of SOC Network. Regrettably, this is non-trivial on multiple fronts:

Data protection / customer privacy

They must be ensure that no information about the customer where the CTI was found during IR, leaks out. Sometimes this is easy and trivial sometimes it is not. Thus, unless the SOC is very mature at entering CTI into their system, people will want to check manually what is being shared.

Data licencing

Many SOCs buy CTI data from commercial sources. Such data needs to be excluded from automatic data sharing.

Data compatibility

While there are a number of standards for CTI data exchange (e.g., STIXX/TAXII, MISP or Sigma rules), this is far from being a settled topic. Especially if you want to move up in the pyramid of pain.

Sharing tools

In addition to sharing information, it is also possible that members of the network share the tools they have written to perform various aspects of a SOCs job.

Austria Politics

Ein paar Thesen zu aktuellen Gesetzesentwürfen

(Diesen Blogpost habe ich 2017 für den Blog geschrieben. Das hier ist quasi eine Sicherheitskopie.)

Das Thema “LE going dark in the age of encrytion” kocht mal wieder hoch, und noch schnell vor den Neuwahlen wurden entsprechende Gesetzesentwürfe eingebracht. Ich will hier aus technischer Sicht ein paar Argumente in die Diskussion einwerfen, beschränke mich hier aber rein auf den Aspekt Überwachung trotz Verschlüsselung. Die anderen Punkte (Registrierung und Zugriff auf Kameras, Zugriff auf Daten der ISPs, …) sind zwar auch interessant, treffen aber nicht so sehr in das Kerngeschäft von CERTs, ich werde sie daher nicht mit dem Hut kommentieren.


Wir leben in einer vernetzten Welt, ein lokaler Blickwinkel reicht nicht.

Echte End-to-End Verschlüsselungen in internetbasierten Kommunikationsplattformen (Messenger, VoIP, …) verhindern, dass deren Betreiber Auskunft über Kommunikationsinhalte ihrer Nutzer geben können. Gut gemachte Verschlüsselung für Harddisks und Handys heißt das gleiche: der Hersteller kann die Devices seiner Kunden nicht einfach entsperren.

Natürlich wäre es für das FBI und andere Polizeibehörden im Westen sehr hilfreich, wenn dem nicht so wäre, und sie immer auf die Mithilfe von Apple, Microsoft, Google, Facebook & co bauen könnten, um an die Daten und die Kommunikation von Verdächtigen heranzukommen. Das hat nur zwei ernsthaft böse Konsequenzen:

  • Die gleichen Möglichkeiten gelten dann auch für die Polizei von fast allen Staaten dieser Welt. Man mag dem Rechtsschutz in Österreich noch vertrauen, aber es gibt genug Staaten (und weit weg von unserer Insel der Seligen müssen wir da gar nicht), in denen solche Werkzeuge in den Händen des Staates für Repression, Wirtschaftsspionage und Korruption verwendet werden.
  • Es ist für die betroffenen Anbieter ein massiver Imageschaden, wenn sie hier mitspielen. Das kann sich vielleicht gerade noch ein Monopolist erlauben, Firmen die im freien, global Markt operieren, können das nur ablehnen.

In anderen Worten: wir können nicht verhindern, dass das gleiche Werkzeug, mit dem eine österreichische Firma mit ihren Außenstellen und Mitarbeitern im Ausland geschützt kommunizierten kann, auch von einem Übeltäter bei uns benutzt wird, um der Strafverfolgung vermeintlich zu entkommen.

Das Rad der Zeit kann man nicht zurückdrehen

Das Internet basiert auf der Idee, dass das Transportnetz nichts von den Applikationen wissen muss, sondern sich rein auf den Datentransport beschränkten kann. Damit wurde eine Innovationskraft freigesetzt, die andere Ansätze (erinnert sich noch jemand an die ISDN Vision aus den 80ern?) komplett überrollt hat.

Ganz ähnliches ist bei PCs und Handys passiert: Erst mit der Möglichkeit, fast beliebige Programme auf diesen Computern laufen zu lassen, wurden sie erst wirklich interessant und so wurden sie zu Plattformen für vielfältigste Anwendungen und Nutzungen.

Wir leben in einer Welt, in der “breit verfügbare, generische Kommunikationsmittel” und “billige, mächtige, frei programmierbare Computer” eine Tatsache sind. Und auch wenn diese Idee im Zeitalter von App Stores (Apple, Windows 10 S), Staatlichen Firewalls (China) oder VPN-Verboten (aktuell Russland) etwas unter Druck kommt, glaube ich nicht, dass das Rad der Zeit hier komplett zurückgedreht werden kann.

Über das Internet kann man beliebige Kommunikation tunneln, das Netz selber kann hier nicht regulierend eingreifen. Und welche Programme auf unseren Endgeräten laufen, können wir in weitem Rahmen selbst bestimmen. Software zur Kommunikation von staatlicher Seite zu verbieten, hat sich in westlichen Demokratien bis jetzt als undurchsetzbar herausgestellt.

Auch das Wissen um Kryptografie (Verschlüsselung) ist inzwischen so breit gestreut und die Algorithmen sind überall über einfache APIs ansprechbar, dass auch die Verfügbarkeit von Kyptografie nicht mehr umkehrbar ist.

Kryptografie schwächen heißt Sicherheit schwächen

Bei der Einführung von Transportverschlüsselung (SSL/TLS) hat die US Regierung eine Zeit lange versucht, nur den Export von abgeschwächten Versionen zu erlauben. Das hat sich als Bumerang erwiesen, wie die Forscher schreiben, die die “DROWN” Lücke gefunden haben:

For the third time in a year, a major Internet security vulnerability has resulted from the way cryptography was weakened by U.S. government policies that restricted exporting strong cryptography until the late 1990s. Although these restrictions, evidently designed to make it easier for NSA to decrypt the communication of people abroad, were relaxed nearly 20 years ago, the weakened cryptography remains in the protocol specifications and continues to be supported by many servers today, adding complexity—and the potential for catastrophic failure—to some of the Internet’s most important security features.

The U.S. government deliberately weakened three kinds of cryptographic primitives: RSA encryption, Diffie-Hellman key exchange, and symmetric ciphers. FREAK exploited export-grade RSA, and Logjam exploited export-grade Diffie-Hellman. Now, DROWN exploits export-grade symmetric ciphers, demonstrating that all three kinds of deliberately weakened crypto have come to put the security of the Internet at risk decades later.

Today, some policy makers are calling for new restrictions on the design of cryptography in order to prevent law enforcement from “going dark.” While we believe that advocates of such backdoors are acting out of a good faith desire to protect their countries, history’s technical lesson is clear: weakening cryptography carries enormous risk to all of our security.

Die Suche nach “NOBUS” (Nobody but us) Schwachstellen/Hintertüren in Verschlüsselungsverfahren hat sich in weitem Bereich als Suche nach dem heiligen Gral herausgestellt. Das klingt gut, mag auch eine Zeit funktionieren, aber dann explodiert das mit hohem Schaden. Ein plakatives Beispiel dafür sind die “TSA” Schlösser für Koffer, für die es bekannte Zweitschlüssel gibt. Es hat nicht lange gedauert, bis diese als 3D-Druckvorlagen im Netz auftauchten.

Daher: wenn man sichere Verschlüsselung haben will, auf die man sich verlassen können muss, dann kann man im Design der Software und der Algorithmen nicht schon absichtlich Hintertüren einbauen.

Kryptografie ist kein Safe

Manchmal wird die Verschlüsselung von Daten mit dem Versperren von Akten in Safes verglichen. Es gibt hier aber einen wichtigen Unterschied:

Für die Sicherheit von Safes wird bewertet, wie lange ein Angreifer unter gewissen Randbedingungen (Werkzeug, Lärmentwicklung, …) braucht, um den Tresor aufzubrechen. Dass der Safe geknackt werden kann, steht außer Zweifel, es geht immer nur um “wie lange mit welchen Mitteln”.

Bei Kryptografie ist es nur theoretisch gleich: mit genug Einsatz von roher Rechenleistung lassen sich die gängigen Verfahren knacken, nur ist bei aktuellen Algorithmen das “genug” schlicht außerhalb des derzeit technisch Machbaren. (OTPs und Quantencomputer lasse ich hier außen vor.)

In der klassische IT ist Security ist noch schwieriger zu erreichen als in der Kryptografie, aber auch ein gesperrtes iPhone lässt sich nicht einfach nur mit roher Gewalt öffnen.

Was heißt das für die Polizei und Gerichte?

Das Gewaltmonopol ist hier kein Joker, der immer sticht. Der Staat kann hier seinen Willen nicht immer hart durchsetzen. Ein österreichisches Bundesgesetz zieht gegen die Gesetze der Mathematik den Kürzeren.

Fähigkeiten von Malware / Kontrolle der Verwendung

Wenn wir vor Ort bei einer Vorfallsbehandlung helfen, kommt sehr oft die Frage, was denn die gefunden Schadsoftware alles hätte machen können. Mit viel Glück kann man manchmal beantworten, was gemacht wurde, aber die Frage der Möglichkeiten endet meistens mit “Sie konnte auch Programme nachladen und ausführen”. Aus der Sicht des Angreifers ist das auch sehr verständlich: das hält den Code klein und den Handlungsspielraum groß. So können gezielt Werkzeuge und Funktionalitäten nachgeladen werden.

Aus rein technischer Sicht besteht kaum ein Unterschied zwischen dem Vorgehen einer Tätergruppe, die spionieren will und der Polizei, die mittels einer eingebrachten Software eine (vielleicht bald) legitimierte Kommunikationsüberwachung eines Verdächtigen durchführt.

Auch hier muss das Tool fast zwangsläufig generisch sein, es muss es dem Polizisten ermöglichen, auf den vorgefundenen Messenger zu reagieren und entsprechende Module nachzuladen. Ich halte daher Aussagen der Form “Die Software kann exakt nur das, was rechtlich erlaubt ist” für technisch nicht haltbar.

Damit haben wir aber ein Audit-Problem. Wie stellen wir sicher, dass das wirklich alles gesetzeskonform abläuft und nicht ein übermotivierter Beamte alle seine technischen Möglichkeiten im Sinne seines Ermittlungsauftrages ausreizt? Hier braucht es dann deutlich mehr als nur einen Juristen als Rechtsschutzbeauftragte, es braucht eine entsprechende Protokollierung und technisch geschulte Kontrolleure.

Das sehe ich im aktuellen Entwurf nicht.

Mobiltelefone sind wie Wohnungen

Mit gutem Grund legt der Gesetzgeber einen anderen Maßstab bei der Durchsuchung einer Wohnung im Vergleich zu der eines Autos an. Die Verletzung der Privatsphäre der eigenen vier Wände ist so signifikant, dass es eine wirklich starke Argumentation seitens des Staates geben muss, um das zu erlauben.

Es gibt global gesehen die ersten Richtersprüche die festhalten, dass die Daten, die heute in Smartphones gespeichert sind, so intimer Natur sein können (Kommunikationsarchiv, Bilder, Videos, Adressbücher, Terminkalender, Social Media, …) dass für eine polizeiliche Durchsuchung die gleichen Maßstäbe anzulegen sind, wie für Wohnungen.

Der aktuelle Vorschlag nimmt das auf, indem er nur auf Kommunikationsüberwachung, nicht aber auf Durchsuchung abzielt. Ich halte das für in der Praxis nicht so schön trennbar, wie sich das die Juristen vorstellen.

Implantieren der Überwachungssoftware

Die Gretchenfrage ist aber, wie denn die Software der Überwacher auf den PC oder das Handy des zu Überwachenden kommt.

Das war früher mit Windows 95 & co noch relativ einfach: wenn man das Gerät in die Hand bekommt, kann man leicht Software installieren. Ein aktuelles Windows braucht hingegen eigentlich immer ein Passwort und ist darüber hinaus noch mit Secure Boot und BitLocker gegen Manipulationen geschützt. Bei Handys schaut es ähnlich aus, aktuelle Modelle lassen sich auch nicht so einfach mit nur einem USB-Kabel manipulieren. Dort kommt noch dazu, dass man schwerer unbeobachtet an das Gerät kommt.

Und das ist gut so. Der Schutz von sensiblen persönlichen oder Firmendaten, die auf mobilen Computern (Laptops, Smartphones, …) gespeichert sind, ist bei jeder Risikobetrachtung (und sei es nach ISO 27k) ein wichtiges Thema. Ein verlorenes Handy oder ein gestohlener Laptop darf für Firmen nicht den Verlust der darauf gespeicherten Daten bedeuten. Diese Absicherung wird den Firmen vom Staat über mehrere Gesetze auch unter Androhung von Strafen vorgeschrieben, das reicht vom DSG bis hin zum kommenden NIS-Gesetz.

Ähnliches gilt auch für die Einbringung von Überwachungssoftware aus der Ferne. Das ist – aus rein technischer Sicht – einfach nur ein weiterer Advanced Persistent Threat (APT). Ob eine kriminelle Bande eine Bank infiltrieren will, um Geld zu bekommen, ob ein fremder Staat in Firmen eindringt um Wirtschaftsspionage durchzuführen, oder ob irgendein Geheimdienst die IT Systeme eines Ministeriums knacken will, um politische Spionage zu betreiben, alles das passiert mit genau denselben Methoden, die auch unsere Polizei anwenden müsste, um in System der vermuteten Kriminellen die Software für die Überwachung einzubringen.

Hier liegt die Krux der Sache: im Normalfall will der Staat, dass sich Bürger und Firmen erfolgreich gegen solche Angriffe absichern, aber wenn der Angriff von der Polizei kommt, soll er a) erlaubt sein und b) funktionieren. Ja, ersteres kann man mit einem Beschluss im Parlament durchsetzen, zweiteres nicht. Da sind wir wieder beim gleichen Thema wie oben bei der Kryptografie:

Sicherheitssysteme bewusst so zu schwächen, dass nur “die Guten” die Lücken nutzen können, funktioniert nicht.

Schizophrenie bezüglich Sicherheit vs. Überwachungsmöglichkeiten

Wir haben also sowohl bei der Kryptografie als auch bei der Sicherheit von IT Systemen zwei sich widersprechende Ziele:

  1. Die Systeme sollen so sicher sein, dass Bürger, Firmen und auch Behörden sicher Daten verarbeiten und vertraulich kommunizieren können. Dazu muss die Integrität der verwendeten Systeme nach bestem Stand der Technik geschützt werden und die verwendeten Algorithmen dürfen keine bekannten Schwächen aufweisen. Werden Schwachstellen gefunden, müssen diese sofort an den Hersteller gemeldet werden, damit sie behoben werden können.
  2. Der Staat will zur Verhinderung und zur Aufklärung von Verbrechen einen Einblick in die Kommunikation und die Daten von Verdächtigen bekommen können. In anderen Staaten kommt hier auch noch der Wunsch dazu, Schwachstellen für Geheimdienstaktivitäten und einen potentiellen “Cyberkrieg” zu horten.

Beide Ziele voll zu erfüllen geht schlicht nicht.

Jeder Staat muss für sich entscheiden, welches Ziel Priorität hat.

Davon unbenommen kann der Staat aber auch noch entscheiden, in welchem Rahmen die Polizei Fehler von Verdächtigen in deren Verwendung von IT Systemen (und deren Schwächen) ausnutzen darf.

Ob Österreich jetzt auch bei den üblichen Verdächtigen die Überwachungssoftware einkauft (dass diese im BM.I entwickelt wird, halte ich nicht für realistisch), wird den Markt von 0-days und diesen Lösungen nicht messbar beeinflussen. Wie seriös solche Firmen agieren, konnte man schön an dem HackingTeam Datenleak erkennen. Und natürlich wird auch hier den potentiellen Kunden manchmal mehr versprochen, als man halten kann.

Wenn aber die Grundsatzentscheidung zu den Prioritäten auf staatlicher Seite nicht klar getroffen wird, dann bringt man die Verwaltung und die Exekutive in eine Zwickmühle: sollen sie auf IT-Sicherheit oder auf Überwachungsmöglichkeiten hinarbeiten?

Die Hersteller scheinen ihre Wahl getroffen zu haben: für sie ist Überwachungssoftware Malware und wird bei Erkennung entfernt.



I’m getting a lot of Usenet deja-vues when looking at the Mastodon architecture. A collection of servers that create a shared space for communication.

I like it. It should be this way: independent of a single operator.

But it’s hard to pull off the scaling and the abuse management. The Usenet Death Penalty (UDP) seems to have been built in and actually being used to keep misbehaving servers from ruining the experience for everybody.

Anyway, I’m, let’s see if this link works as validation.

Austria Politics

#define gerechte Pensionen

Weil mal wieder der Generationenvertrag in Sachen Pensionen im Gespräch ist, und Alt gegen Jung diskutiert, will ich hier mal einen Gedanken einwerfen, der zu oft ignoriert wird.

Wir haben ein Umlagesystem bei den Pensionen: die jetzt Arbeitenden zahlen die Pensionen der vorigen Generation in der Erwartung, dass dann ihre Kinder und Enkel das Gleiche für sie machen werden. Alles gut und sinnvoll, aber was genau meinen wir eigentlich mit „das Gleiche machen“?

Durch die demoskopischen Entwicklungen und die Änderungen in der Lebenserwartung sind die Randbedingungen nicht konstant geblieben, die Frage hat daher keine triviale Antwort. Ich sehe grob zwei Ansätze, wobei ich bewusst nicht behaupte, dass der eine wahrer ist als der andere.

Der anspruchsbasierte Ansatz

Nach x Jahren Arbeit / ab dem y. Lebensjahr hat man einen Anspruch auf eine Pension in der Höhe von f(Arbeitseinkommen). Wenn die Generation, die jetzt in Pension ist, das für ihre Vorgänger ermöglicht hat, dann ist es nur fair, wenn auch sie zu den gleichen Konditionen in Pension gehen können. Ja, an ein paar der Parameter wurde in den letzten Jahren leicht gedreht, etwa der Funktion, die aus dem Einkommen über die Berufsjahre die Pensionshöhe ermittelt, aber der Ansatz blieb der gleiche: man hat sich eine Pension in einer gewissen Höhe verdient, und die haben die Kinder und der Staat zu garantieren. „Ist ja fair, wir haben das gleiche für unsere Vorfahren gemacht.“

Der kostenbasierte Ansatz

Wir können aber auch andersherum rechnen: die jetzigen Pensionisten mussten während ihres Arbeitslebens für die Unterstützung ihrer Eltern/Großeltern einen gewissen Teil ihres Einkommens abgeben. Teils direkt per SV-Abgaben auf ihr Einkommen, teils per Arbeitsgeberbeiträge auf ihren Lohn aber auch über Zuschüsse aus dem regulärem Staatsbudget. Das könnte man sicher aus historischen Statistik- und Budgetdaten für jedes Nachkriegsjahr ausheben. Der genaue Prozentwert spielt hier keine Rolle, aber ich bin mir sehr sicher, dass er über die Jahre hinweg gestiegen ist, weil die Bevölkerung nicht mehr so stark wächst (was das Ganze in Richtung Ponzi-Schema gerückt hat) und die Lebenserwartung viel stärker gestiegen ist als das Pensionseintrittsalter. Man kann gut argumentieren, dass das nicht fair ist. Warum sollen heutigen Arbeitenden mehr ihrer Wirtschaftsleistung an die Pensionisten abgeben, als was diese früher für ihre Vorgänger abgegeben haben?

Aus einer rein rationalen Sicht sind beide Ansätze gleich richtig. Beide sind in sich konsistent und logisch. Der Mathematiker und Informatiker in mir sagt: wenn man bei einer Optimierungsaufgabe die Zielfunktion nicht klar definiert (hier „Was ist gerecht?“), dann kann man nicht objektiv die beste Lösung suchen. Das geht mir bei der aktuellen Debatte ab. Die Anerkennung, dass es mehr als einen Blickwinkel auf das Thema gibt, und dass man daher einen politischen Kompromiss suchen wird müssen.

Aber in einem Bereich bin ich ganz hart für den kostenbasierten Ansatz: Angeblich sind die Politikerpensionen in Italien komplett aus dem Ruder gelaufen, weil schon kurze Karrieren dort großen Pensionsansprüche triggern. Hier wäre ein hartes „Aber in Summe kriegen sie nicht mehr als x% vom BIP.“ hilfreich.  

Austria Internet Politics

ID Austria und der Bundestrojaner

[2022-08-16: ein paar Klarstellungen hinzugefügt.]

Letztens hat wer auf Twitter geschrieben, dass es doch sein könnte, dass in die für ID Austria vorgesehene Smartphone App („Digitales Amt“) ein Bundestrojaner eingebaut ist. Ich halte das für ausgesprochen unwahrscheinlich, die Argumente dahinter (neben den trivialen “das schaffen sie nicht” und “das wäre illegal”) eignen sich aber nicht für Twitter, daher dieser Blogpost.

Auf die Frage, warum SMS nicht mehr sicher genug ist, und warum eine App am Smartphone als zweiten Faktor die Lösung sein soll, will ich hier nicht eingehen. Das ist ein anderes Thema, und ist in der Form auch gar nicht mehr wahr, da auch FIDO Tokens (Level 2) unterstützt werden. Auch das Thema Datenschutz will ich hier nicht ansprechen.


Wir sind in Österreich gewöhnt, dass der Staat uns Mittel in die Hand gibt, uns mit sehr guter Qualität auszuweisen (und wir unsere Gegenüber), also zu beweisen, wer wir sind. Pässe und Personalausweise sind hilfreich. Wo es das nicht flächendeckend gibt (etwa im angelsächsischem Raum), dort wird dann auf so schwache Hinweise wie Stromrechnungen zurückgegriffen und dort gibt es viel mehr Probleme mit Betrug per Identitätsdiebstahl.

Es ist daher nicht überraschend, dass schon länger versucht wird, das gleiche Konzept auch auf die virtuelle Welt im Internet zu übertragen. Auch hier wäre es in vielen Fällen gut, wenn ich mich (als Nutzer, der einen Browser bedient) klar gegenüber einer Webseite ausweisen kann. Das kann von simplen e-Commerce bis hin zu e-Government reichen. Klar ist das oft mühsam, aber es ist oft zu meinem eigenen Schutz, damit niemand anderer in meinem Namen etwas machen kann. Beispiel aus der offline-Welt von 2007: Ich hebe eine große Summe Bargeld am Bankschalter ab, damit ich mein neues Auto bar bezahlen kann. Darauf will man sowohl meine Bankkarte, als auch einen Ausweis sehen und entschuldigt sich für die Umstände. Ich sag drauf: im Gegenteil, ich wäre sauer, wenn sie jemandem mehrere tausend Euro von meinem Konto geben, ohne sicherzustellen, dass das wirklich ich bin.

Nicht immer ist der „True Name“ relevant, sondern es ist nur wichtig, dass man beim Webservice wiedererkannt wird. Dafür reichen dann Sachen wie „Login via Google/Twitter/Facebook“, wobei es mir massiv gegen den Strich geht, meine Online-Aktivitäten auf vielen Webseiten vom Vorhandensein meines Google-Accounts abhängig zu machen. Weil bei den dortigen Gratis-Accounts habe ich null Handhabe, wenn irgendeine KI meint, sie müsse meinen Account sperren.

Ich halten es daher für ausgesprochen gut, dass sich der Staat in das Thema Online Authentication einmischt. Die Historie der Bürgerkarte will ich hier nicht breittreten, aber mit der eIDAS Verordnung auf EU-Ebene entsteht langsam ein föderiertes System von nationalen Identifikationsmethoden, die es jedem EU Bürger erlauben wird, sich EU-weit online zu identifizieren. Das ist einer der Kernbausteine des EU Single Market, und die EU treibt auf vielen Seiten das Thema Verifikation von Online-Identitäten voran. Das kann man jetzt gut finden, oder nicht, siehe etwa meine Blogposts zu NIS2 und Domaininhabern.

eID  / ID Austria

Aus dem obigem ergibt sich, dass ID Austria kein kurzfristiges Projekterl wie etwa das „Kaufhaus Österreich“ ist. ID Austria ist für Österreich nicht optional. Es ist strategisch wichtig, um die national Souveränität in der Onlinewelt zu erhalten. Und es ist eine Vorgabe von der EU, die umzusetzen ist.

Kurz: das Teil ist wichtig, da hängt viel dran. Das muss funktionieren. Was bewirkt sowas in der Umsetzung? Viel Aufmerksamkeit, jede Menge Leute, die mitreden und entsprechende Kontrolle.

Ist es daher denkbar, dass eine (illegale) Spionagekomponente als Teil des offiziellen Projektplans der ID Austria aufgenommen wurde? Keine Chance. Da sind zu viele Leute involviert. Das gefährdet deren Baby massiv.

Gäbe es ein bewusstes Backdoor und würde das enttarnt werden, so hätte das massiv negative Effekte. Auf die Beteiligten und das Thema eID. Das wäre ein Spiel mit sehr hohem Risiko.

Beteiligte Player

Früher habe ich, wie sicher viele andere auch, die Behörden als eine Einheit gesehen. Im Zuge der Zusammenarbeit mit der öffentlichen Verwaltung ist mir aber klargeworden, dass das völlig falsch ist. Erst mal muss man zwischen Bund, Ländern und Gemeinden unterscheiden, die oft divergente Interessen haben. Aber auch der Bund ist kein Atom: jedes Ministerium ist eigenständig, hat eigene Ziele, Prozesse und House-Rules. Zoomt man weiter, so sieht man weiter Strukturen, gerade das BMI und das BMLV sind Paradebeispiele von komplexen Organisationen mit jeder Menge interner Interessenskonflikte und Friktionen.

Wenn man also die Frage stellt, ob der Staat in die ID Austria App („Digitales Amt“) einen Bundestrojaner einbaut, dann muss die erste Rückfrage sein: Wer genau würde das tun?

Das Thema eID ist ein bisschen ein Wanderpokal: lange war das im Bundeskanzleramt angesiedelt, mit Schwarz-Blau wurde es an das BMDW (Bundesministerium für Digitalisierung und Wirtschaftsstandort) übergeben, und jüngst ist es in das Finanzministerium verschoben worden. Aus welcher Ecke käme der Wunsch, in die App eine Überwachungsfunktion einzubauen? Beim letzten Gesetzesvorschlag in die Richtung war das Innenministerium (genauer, das Bundeskriminalamt) zuständig. (Theoretisch könnte man noch an das BMLV/Abwehramt denken, in der Praxis passt das aber überhaupt nicht.)

Wir haben erst jetzt mit der Schwarz-Grünen Koalition BMI und BMx in der gleichen Couleur. Dass ein blauer Innenminister so etwas im der schwarzen BMDW-Frontfrau im Geheimen ausdealt? Nah. Und dass das nach Koalitionsende geheim bleibt? Sehr unrealistisch.

Neben den Ministerien ist aber auch noch der Technologiepartner im Spiel. Das BMDW programmiert die App ja nicht selber. Soweit ich weiß, ist das in diesem Fall das Bundesrechenzentrum (BRZ). Wie soll das BMI, das hier gar nicht Auftraggeber ist, und auch keine juristische Grundlage dafür hat, dem BRZ einreden, in die App noch was reinzugeben? Auf welcher Basis? Mit welchem Budget?


Die anlasslose „Überwachung“ mittels der Vorratsdatenspeicherung wurde von den Höchstgerichten gekippt. Die von Schwarz-Blau angestrebte gezielte Kommunikationsüberwachung von Verdächtigen per Software am Handy wurde auch untersagt.

Eine Überwachungskomponente in der ID Austria App ist daher rechtlich sicher nicht zulässig.

Ja, man kann natürlich behaupten, dass das irrelevant ist, weil Gesetze gebrochen werden können. Meiner Erfahrung nach kommt das vielleicht im Kleinen vor, je mehr Personen aus verschiedenen Organisationen im Spiel sind, umso unwahrscheinlicher ist das.

Der Kreis der Verschwörer ist zu groß, und Vorteil, den sie daraus ziehen, ist zu abstrakt. Klassische Korruption passt hier nicht als Motiv, wie sollte man diesen Gesetzesverstoß zu privater Bereicherung nutzen? Was haben die Leute im BMDW oder BRZ davon, dass sie hier mitspielen? Für das BMDW wäre das ein Eigentor mit Anlauf. Und was würde es der Polizei wirklich bringen? Sie können mit dem potentiell erlangten Wissen ja nicht vor Gericht gehen, solange das ganze Schema illegal ist.

Weiters muss man sich noch die Frage stellen, ob die Tätergruppen, die gerne für diverse Überwachungsphantasien herhalten müssen, überhaupt die App haben. Pöhse Ausländer, Organisierte Kriminalität, Terroristen? Die haben sicher die App, um damit ihren Meldeschein auszufüllen und bei Volksbegehren zu unterschreiben. Genau.


Im Gegensatz zum Einsatz von klassischer polizeilicher Überwachungssoftware wird die „Digitales Amt“ App über die normalen App-Stores verteilt. Was heißt das?    

  • Die App muss durch die Sicherheitschecks von Apple und Google durch. Ja, die sind nicht perfekt, aber: Das muss bei jedem kleinen Update funktionieren, immer und immer wieder. Es reicht nicht, dass das einmal unerkannt bleibt. Egal, was die beiden in Zukunft machen, die Überwachungskomponente darf nie erkannt werden.
  • Kauft man diese aber wo zu, ist die Chance sehr hoch, dass diese mal irgendwo auffliegt und dass dann die Erkennungen entsprechend verbessert werden.
  • Die App wird als normale App installiert und bekommt nur einen minimalen Satz an Rechten. Für die Nutzung als Spionagewerkzeug bräuchte sie viel mehr Privilegien, die sie sich über Schwachstellen erarbeiten müsste. Das ist nicht einfach und ein „moving target“.
  • Apps sind ziemlich einfach zu de-kompilieren. Es ist daher anzunehmen, dass sich mal wer den Code (der ja verfügbar ist) anschaut.


  • Die Kosten+Risiko – Nutzen Rechnung geht für den Staat nicht auf
  • Die Involvierten haben großteils negative Motivation, warum sie das machen sollten
  • Technisch schwierig. Hohes Risiko, enttarnt zu werden
  • Es wäre klar illegal
  • Es sind viel zu viele Player involviert


Es wäre kein Fehler, wenn man – analog zur Covid-Tracking App – auch hier die Civil Liberties- und Datenschutz-NGOs einbindet und mit wirklich offenen Karten spielt.

In Bezug auf den Datenschutz wurde das auch gemacht, die Datenschutz-Folgenabschätzung vom Research Institute ist umfassend und erklärt gut die Datenflüsse und Behandelt die Risiken in dieser Hinsicht.

Von einem unabhängigen Code-Review, Sicherheitstests oder laufenden Einsichtmöglichkeiten in den Source-Code der App habe ich aber (noch) nichts gehört.

System Administration

Parsing the EU Digital COVID Certificate

I recently go my first Covid-19 shot, and shortly after that I received my QR code that is supposed to prove to anybody that I’m vaccinated.

Of course, I was interested in the actual technical implementation of the thing so I started tinkering around. Initially, I wasn’t sure whether the QR code just links to a webpage or is a standalone document, but reading the documentation quickly made clear that it simply contains a signed document.

There is a python snippet floating around that does all the decoding (decode base45, decompress, decode cbor, ignore signature, cbor decode), but I was wondering whether I can just use standard Linux command-line tools to do the same.

To my big surprise, I could not find a simple base45 decoder to be used on the command line. Neither the GNU coreutils (which supports a bunch of encodings) or basez have implemented base45 yet. For a quick coding exercise, getting code into the coreutils was a bit too ambitious, so I rolled my own in a few minutes. I haven’t done coding in C for quite some time, so this was fun. (while probably not necessary, this should be doable as a one-liner in Perl)

Next step: The libz decompression. Here, too, I was surprised that my Debian box did not have a simple program ready to do it. After some googling, I found that
zlib-flate -uncompress
does the trick. zlib-flate is included in the qpdf package.

Update: The debian package zlib1g-dev contains a few example programs, zpipe.c does exactly what I need. Just copy the file from /usr/share/doc/zlib1g-dev/examples/ , compile with “cc -o zpipe zpipe.c -lz”.

Then cbor: at first this looked easy, there is a libcbor0 in Debian and appropriate modules for Perl and Python. But a command-line tool? That’s not included by default.

Initially, I tried using
python3 -m cbor2.tool
and then continue with jq to select the right element (jq ‘.”CBORTag:18″[2]’ seems to do the trick) but I ran into encoding issues: I did not manage to extract the element in binary form, I always had escape sequences like ‘\x04’ or ‘\u0012’ in there which are not suitable for next step of cbor decoding.

Update: I’ve now read a bit more about the cbor standard and on the things it can do that JSON can’t, is handling raw binary data. JSON knows strings, yes, but they are character strings encoded in utf-8, not sequences of octets. Back in the old days of latin1 that might not have mattered that much, but these days you really shouldn’t mix those two.

So this is still work in progress, watch this space for updates.


  • I’m not the only one who tried this, see also this blogpost by Corentin Dupont.
  • Based on troubles with faked certificates, I had a closer look at the key distribtion and updates of the Austrian green pass system. I documented the results in a blogpost at


Ein anderer Vorschlag zu Facebook

Markus Sulzbacher schlägt im Standard vor, Facebook aus Datenschutz/Kartellrechtsgründen zu zerschlagen.

Ich hätte da einen andere, deutlich subtilere Idee:

Facebook (das social media network) selber halte ich nicht für wahnsinnig wichtig, diese Netze kommen und gehen und Facebook wird hier keine Ausnahme sein. Ich halte WhatsApp für die langfristig deutlich spannendere Plattform, weil sie ein deutlich grundlegenderes Thema mit noch stärkerem Metcalfe’s Law Effekt behandelt: Die simple (text/voice) Kommunikation zwischen zwei Menschen und (fast noch wichtiger) in Gruppen.

Es gibt aus regulatorischer Sicht dafür aber bereits eine klare Lösung, die beim Telefonnetz super funktioniert hat und die Monopole erfolgreich aufgebrochen hat: Die Pflicht zur transparenten Vernetzung der Telefonanbieter inklusive Nummernportierung.

Daher: es wäre einfach an der Zeit, IM Systeme mit einer gewissen Marktmacht, also etwa Skype, WhatsApp, Facebook Messenger, iChat, … genauso zu behandeln, wie Telefonnetze und SMS und deren Interoperabilität vorzuschreiben.

Ja, das kann Österreich nicht im nationalen Alleingang machen, aber die EU hätte die Macht dazu.

Ob die EU auch die Eier dafür hat, ist die offene Frage.

Windows 10

A nugget from the Windows 10 Event log

While investigating why Outlook stopped working, I found the following in the EventLog:


2117? WTF?