About

This is a private blog by Jens Lechtenbörger.

Jens Lechtenbörger

OpenPGP key: 0xA142FD84
(What is OpenPGP? Learn how to protect your e-mail.)


Creative Commons License
Unless explicitly stated otherwise, my posts on this blog are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

I Love Free Software

I love Free Software!
Today is Valentine’s Day, which is a popular occasion to celebrate love. I love free software. In case you don’t know: Free software is software that respects our freedom, and I suggest that you take a close look.

Today I’d like to recommend a pair of nifty, lovely Android apps that I use on a regular basis to improve my vocabulary, namely AnkiDroid with QuickDic. (Needless to say, both are available via F-Droid, an alternative app store that provides nothing but free software.)

AnkiDroid is a tool to memorize things based on flashcards, organized in decks. In a nutshell, you create cards with different contents on back and front, AnkiDroid presents one side of a card, and you try to recall the other, telling AnkiDroid how easy it was to recall the matching content. The frequency of how often a single card’s side is presented is determined by a so-called spaced repetition algorithm. Essentially, the better you know a card, the less frequently it is presented. Lots of card decks are available on the Web and can be imported into AnkiDroid. I don’t use that feature, however.

Instead, I use AnkiDroid with the offline dictionary app QuickDic, which offers dictionaries for lots of (pairs of) languages. Whenever I look up an intriguing word or phrase in QuickDic, I long-press that dictionary entry to invoke a share dialog. Selecting AnkiDroid in that dialog creates a pre-filled flashcard in AnkiDroid, which just needs minor tweaking to create a new card. Learning vocabulary has never been simpler.

I love free software.

I love Free Software!

Die irreführende Rhetorik für mehr Überwachung

Unser von Grundgesetz und Europäischer Menschenrechtskonvention zugesichertes Abwehrrecht zur Privatsphäre gegenüber dem Staat wird unter dem Vorwand der Terrorbekämpfung seit Jahren weiter eingeschränkt. Die Begründungen für zusätzliche Einschränkungen werden mit mehr oder weniger geschickter, aber in jedem Fall irreführender Rhetorik vortragen, die zu selten als solche entlarvt wird. Überlegen Sie selbst.

Der Bundesminister des Innern, Herr Dr. Thomas de Maizière, argumentierte in einer Rede am 20.1.2015, dass Verschlüsselung notwendig sei, damit wir, die Bevölkerung, uns sicher im Internet bewegen könnten. Trotzdem sollten Sicherheitsbehörden in der Lage sein, verschlüsselte Kommunikation zu entschlüsseln. Er versuchte, diese Forderung nach unwirksamer oder umgehbarer Verschlüsselung durch eine Analogie aus der physischen Welt vernünftig erscheinen zu lassen: Wir alle schließen unsere Häuser ab, in die die Polizei unter rechtsstaatlichen Voraussetzungen eindringen darf.

Diese Analogie ist aus mehreren Gründen irreführend:

  • Das Eindringen in unsere Häuser erfolgt in begründeten Einzelfällen. Demgegenüber wird unsere Kommunikation im Internet von Geheim- und Nachrichtendiensten abgehört, gespeichert und analysiert, und zwar im Wesentlichen vollständig, hemmungslos und unkontrolliert, wie wir spätestens seit den Enthüllungen von Edward Snowden wissen.
  • Das Eindringen in unsere Häuser erfordert personellen Aufwand, was ein Vorgehen mit Verstand und Augenmaß erzwingt. (Dies ändert sich, je mehr Smartphones, Smart-TVs, Smart-Watches, smarte Brillen usw. wir als zusätzliche Augen und Ohren jenseits unserer Kontrolle einsetzen.) Demgegenüber laufen Spionage und Überwachung im Internet weitgehend automatisiert ab, was anlasslose Massenüberwachung unter Missachtung der Unschuldsvermutung ermöglicht.
  • Das Eindringen in unsere Häuser ist für uns (meistens) erkennbar und damit anfechtbar. Demgegenüber finden Spionage und Überwachung im Internet hinterrücks statt. Welche Daten von wem zu welchen Zwecken erfasst werden, bleibt im Verborgenen und lässt uns keine Möglichkeit zu rechtsstaatlicher Gegenwehr.

Diese Unterschiede zwischen Überwachung in der physischen Welt und Überwachung im Internet erfordern, dass wir unsere Kommunikation verschlüsseln, wenn wir an Privatsphäre interessiert sind. Wenn „vertrauenswürdige“ staatliche Stellen diese Verschlüsselung umgehen können, dann werden das auch nicht vertrauenswürdige staatliche Stellen und andere Kriminelle schaffen. Das ist inakzeptabel.

Unser Bundesinnenminister steht mit seiner wirren Analogie leider nicht allein. In ähnlicher Weise behauptete Herr Troels Oerting, der Leiter des Europäischen Zentrums zur Bekämpfung der Cyberkriminalität, dass die verschlüsselte Kommunikation so ähnlich wirke wie der Kofferraum eines Autos, der bei einer Polizeikontrolle nicht geöffnet werden könne. Offenbar entgehen auch Herrn Oerting die fundamentalen Unterschiede (a) des begründeten Vorgehens im Einzelfall unter Personaleinsatz mit rechtsstaatlichen Abwehrmöglichkeiten und (b) der anlasslosen, automatisierten und unbemerkbaren Massenüberwachung ohne Möglichkeit zur Gegenwehr. Vermutlich dieser haarsträubenden Logik folgend forderte im Januar 2015 der Anti-Terror-Koordinator im Rat der Europäischen Union, Herr Gilles de Kerchove, die Hinterlegung kryptografischer Schlüssel. Höchst bedenklich.

Unser Bundesinnenminister ist auch an anderer Stelle zu schnell, um die Feinheiten der Realität angemessen zu würdigen. So behauptet er in seiner oben erwähnten Rede mit Bezug auf den Terroranschlag auf Charlie Hebdo:

Die Ereignisse in Paris verdeutlichen einmal mehr, dass wir gemeinsam handeln müssen, und zwar nicht nur im Bereich der so genannten „realen“ Welt. Das Handeln krimineller und terroristischer Bestrebungen findet genauso in der „virtuellen“ Welt statt […]

Die Ereignisse in Paris mögen vieles verdeutlichen, mit der virtuellen Welt hatten sie herzlich wenig zu tun. Die Attentäter waren verschiedenen staatlichen Stellen im Vorfeld bekannt, aber ihre Überwachung wurde zu früh beendet. Davon, dass die Täter verschlüsselt kommuniziert hätten, ist nirgends die Rede – auch nicht in der ministeriellen Rede. Dass er dieses Attentat dennoch zur Rechtfertigung der Umgehung von Verschlüsselung, unserer einzigen Waffe gegen anlasslose Massenüberwachung und andere Kriminalität im Internet, verwendet, ist ungeheuerlich.

Im Ausland ist die Lage nicht besser. So versprach Premierminister David Cameron seinen Landsleuten angesichts des Attentats in Paris, im Falle seiner Wiederwahl Terroristen keine sicheren Kommunikationsräume zu lassen. Dem Premierminister ist offenbar ebenso wie unserem Innenminister entgangen, dass das Attentat nichts mit sicherer terroristischer Kommunikation zu hatte. Darüber hinaus macht seine Aussage klar, wohin die Reise gehen soll: Wer unbekannten Terroristen keine sichere Kommunikation zugestehen will, darf niemandem sichere Kommunikation zugestehen. Von Ihnen und mir ist nicht auszuschließen, dass wir unbekannte Terroristen sind; daher müssen wir überwacht werden, und zwar überall, wo dies technisch machbar ist.

Momentan gibt es noch vergängliche, unaufgezeichnete, private Gespräche. In Familien, mit Wildfremden, zwischen ganz normalen und zwischen verrückten Menschen. Auch die Brüder Kouachi werden sich vor ihrem Anschlag auf Charlie Hebdo über ihre Pläne unterhalten haben. Hatten sie ein Recht auf private Gespräche? Haben wir, die wir anders als sie nicht in Terror-Camps ausgebildet worden sind, dieses Recht, oder wollen wir es uns nehmen lassen, Cameron folgend?

Bevor Sie urteilen, sei daran erinnert, dass die Gefahr, ein Terroropfer zu werden, verschwindend klein ist. Laut Zahlen der New York Times vom Juli 2013 starben seit 2005 jährlich 23 Amerikaner durch Terror. Dreiundzwanzig. Etwa doppelt so viele starben an Bienen- und Wespenstichen, 15-mal so viele durch Stürze von Leitern. In Deutschland gab es nach Angaben der Tagesschau im Januar 2015 bisher nur einen einzigen islamistischen Anschlag – und zwar im März 2011 mit zwei Todesopfern. Demgegenüber gibt es bei uns jährlich mehr als 3.000 Verkehrstote. An den Folgen von Alkoholmissbrauch sollen in Deutschland 74.000 Menschen pro Jahr sterben.

Bevor Sie urteilen, sei zudem daran erinnert, dass Terroristen in Europa und in den USA in den vergangenen Jahren regelmäßig im Vorfeld auffällig geworden sind und Sicherheitsbehörden vor ihren Untaten bekannt waren. Offenbar fehlte es an gezielter Überwachung, um Anschläge zu verhindern. Wer trotzdem vorgibt, die Situation durch anlasslose Massenüberwachung oder durch die Schwächung von Verschlüsselungstechniken verbessern zu können, sollte sich rechtfertigen müssen oder ausgelacht werden.

Haben wir also ein Recht auf vergängliche, unaufgezeichnete, private Gespräche? Im Grunde spielt die Antwort auf diese Frage zumindest für Kommunikation im Internet keine Rolle: Wenn Sie denken, dass Sie dieses Recht haben sollten, müssen und können Sie es sich nehmen. Sie dürfen Ihre Kommunikation nicht kommerziell orientierten Datenkraken anvertrauen, und Sie müssen Ihre Kommunikation verschlüsseln.

Verschlüsselung ist alternativlos. Im Januar 2015 sind Berichte hochrangiger europäischer Gremien erschienen, die dies nachdrücklich belegen. Zum einen empfiehlt der Rechtsausschuss der Parlamentarischen Versammlung des Europarats durchgängige Verschlüsselung zum Schutz unserer Privatsphäre. Zum anderen empfiehlt auch der Ausschuss für Technikfolgenabschätzung des EU-Parlaments den Einsatz von Ende-zu-Ende-Verschlüsselung und Anonymisierungsdiensten zum Schutz der Privatsphäre.

Ich rate Ihnen, für private Kommunikation nicht auf die Dienste bekannter Datenkraken zurückzugreifen, sondern freie Software zur Verteidigung Ihrer Grundrechte einzusetzen, insbesondere GnuPG zur E-Mail-Selbstverteidigung und Tor oder JonDo zur Anonymisierung im Internet.

Lassen Sie sich nicht in die Irre führen, sondern verteidigen Sie Ihre Grundrechte!

Certificate Pinning for GNU/Linux and Android

Previously, I described the dismal state of SSL/TLS security and explained how certificate pinning protects against man-in-the-middle (MITM) attacks; in particular, I recommended GnuTLS with its command line tool gnutls-cli for do-it-yourself certificate pinning based on trust-on-first-use (TOFU). In this post, I explain how I apply those ideas on my Android phone. In a nutshell, I use gnutls-cli in combination with socat and shell scripting to create separate, certificate pinned TLS tunnels for every target server; then, I configure my apps to connect into such a tunnel instead of the target server, which protects my apps against MITM attacks with “trusted” and other certificates. Note that nothing in this post is specific to Android; instead, I installed the app Lil’ Debi, which provides a Debian GNU/Linux system as prerequisite for the following.

Prepare Debian Environment

Lil’ Debi by default uses DNS servers of a US based search engine company, which is configured in /etc/resolv.conf. I don’t want that company to learn when I access my e-mail (and more). Instead, I’d like to use the “normal” DNS servers of the network to which I’m connected, which gets configured automatically via DHCP on Android. However, I don’t know how to inject that information reliably into Debian (automatically, upon connectivity changes). Hence, I’m currently manually running something like dhclient -d wlan0, which updates the network configuration. I’d love to hear about better solutions.

Next, the stable version of gnutls-bin does not support the option --strict-tofu. More recent versions are available among “experimental” packages. To install those, I switched to Debian Testing (replace stable with testing in /etc/apt/sources.list; do apt-get update, apt-get dist-upgrade, apt-get autoremove). Then, I installed gnutls-cli:
apt-get -t experimental install gnutls-bin

Afterwards, I created a non-root user gnutls with directories to be used in shell scripts below:
useradd -s /bin/false -r -d /var/lib/gnutls gnutls
mkdir /var/{lib,log}/gnutls
chown gnutls /var/{lib,log}/gnutls
chmod 755 /var/{lib,log}/gnutls

For network access on android, I also needed to assign gnutls to a special group as follows. (Before that, I got “net.c:142: socket() failed: Permission denied” or “socket: Permission denied” for network commands.)
groupadd -g 3003 aid_inet
usermod -G aid_inet gnutls

Finally, certificates need to be pinned with GnuTLS. I did that on my PC as described previously and copied the resulting file ~/.gnutls/known_hosts to /var/lib/gnutls/.gnutls/known_hosts.

Certificate Pinning via Tunnels/Proxies

I use socat to create (encrypting) proxies (i.e., local servers that relay received data towards the real destinations). In my case, socat relays received data via a shell script into GnuTLS, which establishes the TLS connection to the real destination and performs certificate checking with option --strict-tofu. Thus, the combination of socat, shell script, and gnutls-cli creates a TLS tunnel with certificate pinning against MITM attacks. Clearly, none of this is necessary for apps that pin certificates themselves. (On my phone, ChatSecure, a chat app implementing end-to-end encryption with Off-The-Record (OTR) Messaging, pins certificates, but other apps such as K-9 Mail, CalDAV Sync Adapter. and DAVdroid do not.) For the sake of an example, suppose that I send e-mail via server smtp.example.org at port 25, which I would normally enter in my e-mail app along with the setting to use SSL/TLS for every connection, which leaves me vulnerable to MITM attacks with “trusted” certificates. Let’s see how to replace that setting with a secure tunnel. First, the following command starts a socat proxy that listens on port 1125 for incoming network connections from my phone. For every connection, it executes the script gnutls-tunnel.shand relays all network traffic into that script:
$ socat TCP4-LISTEN:1125,bind=127.0.0.1,reuseaddr,fork \
EXEC:"/usr/local/bin/gnutls-tunnel.sh -s -t smtp.example.org 25"

Second, the script is invoked with the options -s -t smtp.example.org 25. Thus, the script invokes gnutls-cli to open an SMTP (e-mail delivery) connection with TLS protection (some details of gnutls-tunnel.sh are explained below, details of gnutls-cli in my previous article). If certificate verification succeeds, this establishes a tunnel from the phone’s local port 1125 to the mail server. (There is nothing special about the number 1125; I prefer numbers ending in “25” for SMTP.)

Third, I configure my e-mail app to use the server named localhost at port 1125 (without encryption). Then, the app sends e-mails into socat, which forwards them into the script, which in turn relays them via a GnuTLS secured connection to the mail server smtp.example.org.

Shell Scripting

To setup my GnuTLS tunnels, I use three scripts, which are contained in this tar archive. (One of those scripts contains the following text: “I don’t like shell scripts. I don’t know much about shell scripts. This is a shell script. Use at your own risk. Read the license.”)

First, instead of the invocation of socat shown above, I’m using the following wrapper script, start-tls.sh, whose first argument needs to be the local port to be used by socat, while the other arguments are passed on. Moreover, the script redirects log messages to a file.
#!/bin/sh
umask 0022
LPORT=$1
shift
LOG=/var/log/gnutls/socat-$LPORT.log
socat TCP4-LISTEN:$LPORT,bind=127.0.0.1,reuseaddr,fork EXEC:"/usr/local/bin/gnutls-tunnel.sh $*" >> $LOG 2>&1 &

Second, gnutls-tunnel.sh embeds the invocation of gnutls-cli --strict-tofu, parses its output, and writes log messages. That script is too long to reproduce here, but I’d like to point out that it sends data through a background process as described by Marco Maggi. Moreover, it uses a “delayed encrypted bridge.” Currently, the script knows the following essential options:

  • -t: Use option --starttls for gnutls-cli; this start with a protocol-specific plaintext connection which switches to TLS later on.
  • -h: Try to talk HTTP in case of errors.
  • -i: Try to talk IMAP in case of errors.
  • -s: Try to talk SMTP, possibly before STARTTLS and in case of errors.

Third, I use a script called start-tls-tunnels.sh to start my TLS tunnels, essentially as follows:
#!/bin/sh
TLSSHELL=/bin/sh
TLSUSER=gnutls
run_as () {
su -s $TLSSHELL -c "$1" $TLSUSER
}
# SMTP (-s) with STARTTLS (-t) if SMTPS is not supported, typically to
# port 25 or 587:
run_as "/usr/local/bin/socat-tls.sh 1125 -t -s smtp.example.org 587"
# Without -t if server supports SMTPS at port 465:
run_as "/usr/local/bin/socat-tls.sh 1225 -s mail.example.org 465"
# IMAPS (-i) at port 993:
run_as "/usr/local/bin/socat-tls.sh 1193 -i imap.example.org 993"
run_as "/usr/local/bin/socat-tls.sh 1293 -i imap2.example.org 993"
# HTTPS (-h) at port 443:
run_as "/usr/local/bin/socat-tls.sh 1143 -h owncloud.example.org 443"

Once the Debian system is running (via Lil’ Debi), I invoke start-tls-tunnels.sh in the Debian shell. (This could be automated in the app’s startup script start-debian.sh.) Then, I configure K-9 Mail to use localhostwith the local ports defined in the script (without encryption).

(You may want to remove the log files under /var/log/gnutls from time to time.)

Certificate Expiry, MITM Attacks

Whenever certificate verification fails because the presented certificate does not match the pinned one, gnutls-tunnel.sh logs an error message and reports an error condition to the invoking app. Clearly, it is up to the app whether and how to inform the user. For example, K-9 Mail fails silently for e-mail retrieval via IMAP (which is an old bug) but triggers a notification when sending e-mail via SMTP. The following screen shot displays notifications of K-9 Mail and CalDAV Sync Adapter.

MITM Notifications of K-9 Mail and CalDAV Sync Adapter

The screenshot shows that in case of certificate failures for HTTPS connections, I’m using error code 418. That number was specified in RFC 2324 (updated a couple of days ago in RFC 7168). If you see error code 418, you know that you are in deep trouble without coffee.

In any case, the user needs to decide whether the server was equipped with a new certificate, which needs to be pinned, or whether a MITM attack takes place.

What’s Next

SSL/TLS is a mess, and the above is far more complicated than I’d like it to be. I hope to see more apps pinning certificates themselves. Clearly, users of such apps need some guidance how to identify the correct certificates that should be pinned.

If you develop apps, please implement certificate pinning. As I wrote previously, I believe these papers to be good starting points:

You may also want to think about the consequences if “trust” in some CA is discontinued as just happened for CAcert for Debian and its derivatives. Recall that CAcert was a “trusted” CA in Debian, which implied that lots of software “trusted” any certificate issued by that CA without needing to ask users any complicated question at all. Now, as that “trust” has been revoked (see this bug report for details), users will see warnings concerning those same, unchanged (!), previously “trusted” certificates; depending on the client software, they may even experience an unrecoverable error, rendering them unable to access the server at all. Clearly, this is far from desirable.

However, if your app supports certificate pinning, then such a revocation of “trust” does not matter at all. The app will simply continue to be usable. It is high time to distinguish trust from “trust.”

Certificate Pinning for GNU Emacs

GNU Emacs is where is spend most of my computer time. Using Emacs, I’m writing texts in general and this post in particular, I’m programming, I’m reading RSS feeds and news articles, I’m reading and writing e-mails. Emacs is highly customizable and extensible which is great, in general. However, in the past Emacs valued convenience over security, and by default it does not protect against man-in-the-middle (MITM) attacks. This is about to change with upcoming releases.

In a previous post, I explained how certificate pinning protects against MITM attacks and I recommended GnuTLS with its command line tool gnutls-cli for do-it-yourself certificate pinning based on trust-on-first-use (TOFU). In this post, I explain my Emacs configuration for certificate pinning with GnuTLS. The lisp code shown in the following is executed from ~/.emacs, as usual.

Emacs comes with at least three different libraries to establish SSL/TLS connections (net/gnutls.el, net/tls.el, gnus/starttls.el), and some libraries implement their own approach (e.g., net/imap.el). Which approach is used when does not seem to be documented; in general, it depends on what software is installed on your machine. By default, various Emacs libraries will use net/gnutls.el, which is vulnerable to MITM attacks. So I disable that library if it is available:

(if (fboundp 'gnutls-available-p)
    (fmakunbound 'gnutls-available-p))

Without net/gnutls.el, lots of code falls back to net/tls.el, which uses gnutls-cli, but with the switch --insecure. Clearly, that option is called “insecure” for a reason, and by replacing that option certificate pinning based on TOFU can be activated:

(setq tls-program '("gnutls-cli --strict-tofu -p %p %h")

(Recall from my previous post that you need a recent version of GnuTLS for this to work.)

In particular, the above change enables certificate pinning for news servers via NNTPS. E.g., I’m using the following for news.gmane.org:

(setq gnus-select-method
      '(nntp "news.gmane.org"
	     (nntp-open-connection-function nntp-open-tls-stream)
	     (nntp-port-number 563)
	     (nntp-address "news.gmane.org")))

(Recall from my previous post that you need to pin the server’s certificate first, e.g., via gnutls-cli --tofu -p 563 news.gmane.org. The same holds for every server.)

I’m sending e-mails via mail/smtpmail.el, which also defaults to net/gnutls.el but falls back to gnus/starttls.el. In my case, that library uses gnutls-cli, and option --strict-tofu can be added via a variable, starttls-extra-arguments:

(setq starttls-extra-arguments '("--strict-tofu"))

I’m reading e-mails via net/imap.el, which does not use net/gnutls.el but its own approach based on Openssl’s s_client. While s_client is great to debug SSL/TLS connections, it is useless for everyday encryption as it prints an error message if certificates cannot be verified, but it opens the connection anyways. And, those errors are not shown in Emacs. So, switch to gnutls-cli with certificate pinning:

(setq imap-ssl-program '("gnutls-cli --strict-tofu -p %p %s"))

To summarize, this is what I’m currently using in and recommending for Emacs:

(if (fboundp 'gnutls-available-p)
    (fmakunbound 'gnutls-available-p))
(setq tls-program '("gnutls-cli --strict-tofu -p %p %h")
      imap-ssl-program '("gnutls-cli --strict-tofu -p %p %s")
      smtpmail-stream-type 'starttls
      starttls-extra-arguments '("--strict-tofu")
      )

Certificate Pinning with GnuTLS in the Mess of SSL/TLS

Lots of modern communication is “protected” from spying eyes and other criminals via an Internet standard called Transport Layer Security (TLS) or its outdated predecessor Secure Sockets Layer (SSL). In the following, I’m using the term “SSL/TLS” to refer to both of them. In a nutshell, SSL/TLS is a mess. It’s security has been, can be, and is being broken on several layers. In this post, I’m trying to clarify my understanding and recommend the use of certificate pinning by default. In particular, I start to describe how I’m using GnuTLS for certificate pinning in the form of trust-on-first-use. In subsequent posts, I’ll explain certificate pinning in real use cases.

I assume a basic understanding of TLS. Please read the Wikipedia entry on TLS first, if necessary.

The Mess

SSL/TLS is a mess for at least three major reasons.

First, SSL/TLS requires certificates issued by “trusted” certificate authorities (CAs). Previously, I wrote on trust vs. “trust” in the context of e-mail encryption, and that reasoning applies to SSL/TLS as well: Our software (browsers, e-mail clients, apps) “trusts” all certificates issued by “trusted” CAs. However, I do not trust (without quotes, in the original meaning of the term) a single CA. How could I? I don’t know anything about them, except for the recurring horror reports where someone was able to pay, bribe, trick, compel, force, or operate a “trusted” CA to issue “trusted” certificates. See my previous post for more details. In essence, if you “trust” without reason, you are vulnerable to so-called man-in-the-middle attacks, where third parties steal your secrets, your passwords, and your credit card details. And you will be blissfully ignorant, unable to see that anything bad is going on.

Second, lots of software is simply broken when it comes to certificate validation. SSL/TLS APIs and libraries are too complicated for the average software developer to get it right. And some developers just don’t care. If you are a software developer, you must read the following two peer-reviewed, highly accessible publications. Really, please read them.

As a software developer you are going to implement certificate pinning, right? Otherwise, all users of your software will be defenseless against man-in-the-middle attacks.

Third, client and server need to negotiate a cipher suite, and there are lots of insecure choices. If you operate a server, please have a look at the Internet-Draft Recommendations for Secure Use of TLS and DTLS and the companion document Summarizing Current Attacks on TLS and DTLS, which states concerning the BREACH attack:

“We are not aware of mitigations at the protocol level to the latter attack, and so application-level mitigations are needed (see [BREACH]).”

Anyways, configure your server to use AES and Diffie-Hellman key exchange for perfect forward secrecy as recommended.

Certificate or Public Key Pinning

Several times I mentioned certificate pinning already. The core idea is to make a trusted (without quotation marks) certificate for a specific purpose directly accessible to the client software. Suppose you develop an app that needs to communicate with your own server. Then you can embed the server’s certificate directly into the app’s source code. Whenever the app contacts the server, it checks the certificate presented by the server (or a man-in-the-middle) against the one embedded in the source code. If they do not match, your apps stops working and displays a big warning to the user. (Of course, you need to update the source code before the embedded certificate expires.) See the paper Rethinking SSL Development in an Appified World mentioned above for details. Also note that certificate pinning works perfectly well with self-signed certificates, without the need for unwarranted “trust.”

[Added on 2014-04-22] I’d like to clarify one fact which I overlooked when writing this post: Although “certificate pinning” is a popular term, from a security perspective “public key pinning” is typically sufficient. In fact, a certificate is a digitally signed document containing a public key, where the digital signature is meant to provide some assurance that the public key belongs to a certain organization, user, or machine. Now, if pinning is used to embed key material within source code, the digital signature of a “trusted” certificate does not offer added value. Instead, it is sufficient to embed the public key. (Of course, the app itself should be digitally signed to provide assurance of its authenticity.)

Certificate or public key pinning is not restricted to cases where certificates or keys are embedded within the source code. Instead, every client software can consult some storage for pinned certificates or keys to verify whether keys are authentic. Then, the challenge is to populate that storage in a trustworthy fashion. A common approach is to rely on trust-on-first-use (TOFU), which is well-known to users of OpenSSH: With ssh, the pinning storage is implemented as file known_hosts, which contains public keys for servers that have been accepted as trusted by the user previously. With TOFU in general, when the client connects for the first time, it does not know the server’s certificate or public key yet. So the client presents the server’s (or man-in-the-middle’s) public key (or its fingerprint) to the user, who needs to decide whether that key really belongs to the server or not. If the user recognizes that key as authentic, the server’s key is stored as pinned key; otherwise, the connection is aborted.

If you run your own server, e.g., an ownCloud, then you know the correct certificate (containing the public key) and its fingerprint. Otherwise, things may get complicated.

The canonical way to verify a public key or certificate as authentic is to compare the fingerprint of the presented certificate with the “real” fingerprint, which needs to be obtained via some out-of-band method. E.g., for e-mail with GnuPG fingerprints are compared offline at key signing parties or over the phone, some companies distribute fingerprints of CAs and servers in print, some banks provide fingerprints of their online banking servers to customers via snail mail. Quite likely, none of this will be available to you if you try to verify the certificate of a remote server, say, of some News server such as news.gmane.org.

GnuTLS

My current tool of choice to perform certificate pinning for insecure applications is gnutls-cli, a command line tool provided by GnuTLS. For example, to open a TLS connection to news.gmane.org on the NNTPS port 563, you can invoke:

$ gnutls-cli -p 563 news.gmane.org

The response looks as follows:

Processed 141 CA certificate(s).
Resolving 'news.gmane.org'...
Connecting to '80.91.229.13:563'...
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info:
 - subject `C=NO,ST=Some-State,O=Gmane,CN=news.gmane.org', issuer `C=NO,ST=Some-State,O=Gmane,CN=news.gmane.org', RSA key 1024 bits, signed using RSA-SHA1, activated `2011-12-04 06:38:42 UTC', expires `2014-12-03 06:38:42 UTC', SHA-1 fingerprint `c0ec2f016cff4a43c1a7c7834b480b3ac54e90f9'
	Public Key ID:
		d21a01452b5a9b06106946930e64717869ff7ae0
	Public key's random art:
		+--[ RSA 1024]----+
		|=O+.ooo          |
		|+*o+ . .         |
		|= + + o          |
		| . + = o         |
		|  . + + S        |
		|   . . =         |
		|    . +          |
		|     E .         |
		|      .          |
		+-----------------+

- Status: The certificate is NOT trusted. The certificate issuer is unknown.
*** Verifying server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.

Apparently, GnuTLS refuses to connect because the CA (C=NO,ST=Some-State,O=Gmane,CN=news.gmane.org) issuing the certificate is unknown. As I’m interested in certificate pinning, that “trust” issue is not really important to me. However, I’d like to gain evidence that the displayed fingerprint c0ec2f016cff4a43c1a7c7834b480b3ac54e90f9 is actually the correct one (and not one belonging to a forged certificate under an active MITM attack). First, I assume that it is indeed correct and start gnutls-cli with the option --tofu to activate trust-on-first-use:

$ gnutls-cli --tofu -p 563 news.gmane.org

This time, gnutls-cli displays the same information as before but asks whether I trust the certificate. I answer with “y,” and the public key contained in the certificate is recorded in the file ~/.gnutls/known_hosts. (Yes, GnuTLS really pins public keys, not certificates). Now, subsequent connections with option --tofu succeed.

Update on 2014-04-11: If you pin a public key by answering “y,” that key is recorded at the end of ~/.gnutls/known_hosts. If you need to replace a key (which you should expect to happen frequently these days due to the Heartbleed bug in OpenSSL), you must remove the old entry manually from ~/.gnutls/known_hosts: Search for lines containing the server’s name and service and delete all (probably just one) but the last one.

Before dealing with the question whether I actually pinned the correct public key, I’d like to point out something else. The output of a successfully established TLS session indicates what cipher suite was negotiated between gnutls-cli and the server. Here, the output contains:

...
- Description: (TLS1.0)-(RSA)-(AES-128-CBC)-(SHA1)
...

This line implies that no Diffie-Hellman key exchange was performed (in favor of compatibility with broken servers), which can be changed by adding the option --priority=PFS:

...
- Description: (TLS1.0)-(DHE-RSA-1024)-(AES-128-CBC)-(SHA1)
...

To gain some evidence that GnuTLS recorded the correct public key, I use the Tor network and connect to the server from different locations:

$ torify gnutls-cli --tofu --priority=PFS -p 563 news.gmane.org

Tor is an anonymity network, where Internet traffic is re-routed over randomly chosen Tor servers so that it appears to originate from one of these servers. With torify, the subsequent command performs its network connection via the Tor network. Thus, I essentially connect from a different place, and it is less likely that a MITM is able to compromise the paths from different places to the target server news.gmane.org. (Of course, this method does not offer any guarantees: E.g., an attacker located in the target server’s LAN might be able to hijack all traffic directed to the server.)

With Tor, you can control from what country you’d like to connect: Tor offers a so-called control port, by default the port 9051 on the local host, to change configuration options. E.g., to check the certificate from a Tor server located in Norway, instruct Tor to use only exit nodes with country code “no”:

$ telnet localhost 9051
AUTHENTICATE
SETCONF ExitNodes={no}
SIGNAL NEWNYM
QUIT

Then, connect with torify again:

$ torify gnutls-cli --tofu --priority=PFS -p 563 news.gmane.org

In case of a MITM attack (or a new certificate, e.g., to replace an expired one), the following warning is displayed:

Warning: host news.gmane.org is known and it is associated with a different key.
It might be that the server has multiple keys, or an attacker replaced the key to eavesdrop this connection .
Its certificate is valid for news.gmane.org.
Do you trust the received key? (y/N):

If you plan to use GnuTLS for certificate pinning you probably want to record the expiry date displayed by gnutls-cli when you accept a public key. Then you know when to expect a regular certificate change.

Also, you may prefer gnutls-cli to fail when a presented public key does not match the pinned one (instead of asking the above question). For that purpose, I added option --strict-tofu, which is present in GnuTLS since version 3.2.12.

For certificate pinning in situations where the connection starts out in plaintext and switches to TLS via STARTTLS (e.g., SMTP or XMPP), a command like the following can be used:

gnutls-cli --tofu --crlf --starttls -p 25 smtp.example.org

What you need to type then depends on the protocol. E.g., for an encrypted SMTP connection you can type the following commands in the gnutls-cli session; afterwards, you’ll be asked whether you trust the certificate:

EHLO localhost
STARTTLS
<Then press Ctrl-D to enter TLS mode.>

In subsequent posts I’ll explain how I’m really using the above to do something useful.

Conclusions

I motivated this post with the mess of SSL/TLS on three different levels, namely (1) “trust” issues, (2) broken applications that do not check certificates properly, and (3) the choice of insecure cipher suites.

Certificate pinning solves the first two issues. Consequently, certificate pinning is a Good Thing.

The third issue is unrelated to certificate pinning, but at least GnuTLS allows us to choose whatever cipher suite is recommended by the experts (if the server supports it).

Web.de und GMX.net zerstören Vertrauen

Als hätte ich nichts Besseres zu tun!

Es hätte ein so schöner, freier Nachmittag werden können, aber jetzt verbringe ich meine Freizeit damit: United Internet warnt als Betreiber der kostenlosen, deutschen E-Mail-Dienste Web.de und GMX.net Besucherinnen und Besucher, die Werbe-Blocker installiert haben: „Die Sicherheit der Seite wird durch ein Firefox Add-on eingeschränkt.“

Ich werde auf eine „Informationsseite“ weitergeleitet, wo ich lese, dass manipulierte Browser-Erweiterungen wie Adblock Plus unbemerkt Online-Banking-Daten an Kriminelle weitergeben können.

Ich bin fassungslos. Ist das noch legal?

Aber ich bin nicht sprachlos. Richtig ist, dass manipulierte Software Online-Banking-Daten an Kriminelle weitergeben kann. Das kann eine manipulierte Browser-Erweiterung sein, das kann der manipulierte Browser selbst sein, das kann das durch Trojaner manipulierte Betriebssystem sein, das kann das bewusst oder unbewusst mit Sicherheitslücken ausgestattete Betriebssystem selbst sein. Die Liste der Möglichkeiten lässt sich lange fortsetzen und erlaubt nur einen Schluss: Online-Banking ist riskant. Wer über diese Tatsache noch nicht nachgedacht hat, sollte auf Online-Banking verzichten.

Alice benutzt für ihr Online-Banking eine Live-CD, wie ich anderswo beschrieben habe. Sie benötigt dazu keine Werbe-Blocker.

Alice und Bob benötigen aber unbedingt einen Werbe-Blocker, um sich im Web nicht auf Schritt und Klick verfolgen zu lassen. Sie setzen Werbe-Blocker nicht so sehr ein, weil sie Werbung an sich schlecht finden; sie setzen Werbe-Blocker vielmehr ein, um ihre Privatsphäre zu schützen und ihr Recht auf informationelle Selbstbestimmung wahrzunehmen: Typische Web-Werbung sorgt im Hintergrund dafür, dass unsichtbare Werbenetze ausspionieren, welche Web-Seiten Sie wann, wie lange und in welcher Reihenfolge besuchen; wo Sie sind, welche Vorlieben Sie haben, was Sie denken. (Eric Schmidt in 2010 als Google-CEO: „We don’t need you to type at all. We know where you are. We know where you’ve been. We can more or less now what you’re thinking about.“).

Mein allererster Artikel in diesem Blog stellt diese Sicht auf Werbe-Blocker ausführlicher dar. Ich verwende übrigens die freie Software Adblock Edge als Werbe-Blocker.

Dieser Werbe-Blocker hilft nicht nur beim Schutz meiner Privatsphäre, er erhöht darüber hinaus auch die PC-Sicherheit: Über kompromittierte Werbenetze werden seit langem und immer wieder Schadprogramme wie Viren und Trojaner per Drive-by-Download verteilt, etwa bei wetter.com oder aktuell bei YouTube, wovor im letzten Jahr auch das Bundesamt für Sicherheit in der Informationstechnik gewarnt hat. Mit einem Werbe-Blocker gelangen die Inhalte von Werbenetzen nun gar nicht mehr auf meinen Rechner, weder „echte“ Werbung noch eingeschleuste Schadprogramme.

Zurück zu United Internet: Auf web.de und gmx.net handelt mir die Browser-Erweiterung Adblock Edge die eingangs zitierte Warnung ein, die Sicherheit der Seite sei reduziert. Überlegen wir doch mal. Gerade habe ich erläutert, dass diese Erweiterung dafür sorgt, dass mein Browser weniger Inhalte aus mir unbekannten Quellen einbettet. Jede dieser Quellen könnte kompromittiert sein und Schadprogramme auf meinem Rechner installieren. Also ist das Gegenteil der Warnung richtig: Die Erweiterung erhöht die Sicherheit. Dennoch ist die Absicht der Warnung natürlich offensichtlich: Ich soll zu der Annahme verleitet werden, meine Daten würden durch diese „böse“ Browser-Erweiterung an Kriminelle gesendet. Das ist allerdings Quatsch: Auf der „Informationsseite“ geht es um einen im Testlabor manipulierten Werbe-Blocker. Dieser kann natürlich beliebige Daten an beliebige Dritte leiten. Aber ich verwende die offiziell veröffentlichte Erweiterung, und nicht die im Labor manipulierte Version …

Als Schlussfolgerung bleibt wohl nur, dass United Internet mehr Geld mit Werbung verdienen möchte als bisher. Insbesondere möchte man (wer ist „man“?) dort nicht, dass wir uns aus den Saugnäpfen der Datenkraken im Internet befreien. Um uns zurück in deren Saugnäpfe zu treiben, schreckt United Internet nicht einmal vor falschen, irreführenden Warnungen zurück. Das zerstört mein Vertrauen. Erstens bin ich (noch) Kunde bei 1und1, der/die/das ebenfalls zu United Internet gehört. Zweitens habe ich kürzlich meine Frau überredet, ihre transatlantische Yahoo-E-Mail-Adresse zugunsten einer deutschen bei GMX aufzugeben. Diese Empfehlung werde ich nicht wieder aussprechen; ab jetzt werde ich warnen.

In der c’t ist kürzlich ein Testbericht zur Sicherheit verschiedener E-Mail-Anbieter erschienen; einige Aspekte werden hier zusammengefasst. Neben den dort genannten Anbietern erscheint mir mailbox.org einen Test wert. Ich habe mich gerade registriert. 1€ pro Monat finde ich günstig für eine Mailbox bei einem Anbieter, von dem ich hoffe, dass er meine Privatsphäre zu schätzen weiß.

Im Übrigen bin ich der Meinung, dass E-Mail verschlüsselt werden muss.

My Fairphone and I Love Free Software

Some time ago I recommended the crowdfunding campaign to produce the Fairphone. In early January my Fairphone arrived, and I’m still experimenting a lot, but I’d like to share initial ideas on what software I did (not) install. I love free software, and I did not install anything but free software.

I love Free Software!

The Fairphone is special in that it is shipped without Google apps, which is highly unusual for an Android phone and which I consider a great advantage. (If you want to use Google apps, there is a simple install process, though.) I don’t use “cloud” services in general because I believe in the value of privacy of thought and communication; in particular, some data is my data, and I’m not aware of any “cloud” service that deserves my trust to handle my data according to my interests. (Previously, I’ve written about that in German. For deeper discussions in English I suggest Eben Moglen’s article on the tangled web and Richard Stallman on Android and users’ freedom.)

Basically, I’d like to own a phone that doesn’t send my data to third parties and that remains mostly operable while offline. Clearly, as the Fairphone is still a mobile phone, if I insert and activate a SIM card, my location is shared with my phone company, from where it is shared with or leaks to known and unknown third parties. Maybe I should deactivate both SIM cards more often and default to SIP calls via Wi-Fi. However, I’m digressing as trust in the cellular network is not the focus of this posting.

Returning to my choice of software, the first thing I installed was the F-Droid app, FDroid.apk. F-Droid is a replacement for Google’s store that offers free software, and I’ve got the impression that the combination of Fairphone and F-Droid appeals to many people (e.g., see this Fairphone support thread in general or this article for some background information on F-Droid and the task of calendar migration).

I’m using ownCloud on my desktop PC to maintain and synchronize my phone’s contacts and private calendars, and I’m using a second ownCloud instance at work to synchronize a work related calendar. The synchronization itself takes place via CalDAV and CardDAV over HTTPS. As Android does not support CalDAV and CardDAV, additional software is necessary, e.g., CalDAV Sync Adapter or DAVdroid. I installed both for testing, the CalDAV Sync Adapter for the work calendar and DAVdroid for contacts and private calendars. So far, both work perfectly. I love free software.

For e-mail, I installed K-9 Mail. Personally, I don’t trust my phone enough to store encryption keys. If I did, I would probably use APG for OpenPGP encryption. I love free software.

Then, I’m using some apps to provide offline maps, dictionaries, and Wikipedia. I’m quite proud to carry the German Wikipedia in my pocket (3.2GB for the version without images) via Kiwix. Kiwix is not yet available in F-Droid, but you can download the app from the project’s page. Files for Wikipedia in several languages are available. As offline dictionary, I’m using QuickDic. For offline maps and routing, I’m using OsmAnd~, which is based on maps created by OpenStreetMap. I love free software.

In addition, I also built and installed NetworkLocation.apk, which is part of the μg Project to provide a free replacement for Google apps. NetworkLocation.apk in particular makes use of data exported from OpenCellID, which in turn collects position information for GSM base stations, to determine my approximate location based on the signal strengths of surrounding cell towers. As I wrote above, my SIM card operator knows where I am. Via NetworkLocation.apk, I can also know where I am, without GPS and without any Internet connection at all. That’s pretty cool, don’t you agree? Thus, OsmAnd~ shows my approximate position, wherever my phone receives a GSM signal, without GPS and without Internet connection. Of course, that type of positioning requires accurate GSM cell information in OpenCellID, and there are several apps to contribute to that data set. Currently, I’m using Keypad-Mapper 3 (whose primary purpose is to map house numbers for OpenStreetMap) to collect cell information. I love free software.

To support private communication in general, I added the Guardian Project F-Droid Repository to F-Droid. The Guardian Projects develops free software such as Orbot to bring anonymous communication via Tor to Android. For Web surfing, it provides Orweb, for encrypted chat ChatSecure, which implements Off-The-Record (OTR) Messaging. I did not yet try Ostel, but it’s on my list. I love free software.

Of course, there is lots more on my phone, e.g., a terminal emulator, a vastly improved keyboard, and a Debian linux including SSH server and tcpdump. I love free software.

I love Free Software!

Many, many thanks to all you out there who work hard, often as volunteers, to fight for our freedom!

OpenPGP and S/MIME or Trust and “Trust”

OpenPGP and S/MIME are competing standards for e-mail encryption, and I argue that Alice and Bob should go for OpenPGP if they are in doubt what standard to prefer. Essentially, the “trust” model of S/MIME is fundamentally flawed.

I’m using both, OpenPGP and S/MIME, and I wrote a GNU Emacs library for automatic encryption of e-mail when public keys or certificates for all recipients are available. As I use S/MIME and as I even programmed something to simplify S/MIME use, I felt compelled to write this article to clarify that I do not recommend S/MIME—and why.

In this document, I place the word “trust” in quotation marks to indicate a misguiding use of the word. Without quotation marks, I refer to the usual meaning of trust: a personal believe that cannot be enforced. (This excellent video explains trust in 3.5 minutes, although in a different context.)

Common Background of OpenPGP and S/MIME

OpenPGP and S/MIME are both readily available for daily use, e.g., the GnuPG project, which you can currently support via their crowdfunding campaign, provides free software for both of them. Lots of tutorials have been written for that software, and I won’t add another one here. I also won’t argue here why Alice and Bob perceive e-mail encryption as necessity. (I did that previously in German.) Actually, why would you choose not to encrypt your e-mail?

OpenPGP and S/MIME are based on asymmetric or public-key cryptography, a branch of mathematics which does some powerful magic. For asymmetric cryptography everyone needs a so-called key pair consisting of a private and a public key. Intuitively, the public key of Alice can be understood as open safe, which she offers for others to receive private messages. Once Bob has put a message into that safe, he closes the door, and nobody but Alice is able to open the door and read the message. Alice needs her private key, the safe’s opening combination, to access the message. This relationship of open safe and public key on the one hand and opening combination and private key on the other is the essence of asymmetric cryptography.

Now, the fundamental challenge of asymmetric cryptography is the identification of trusted or authentic open safes (i.e., public keys). Assume that Mallory wants to intercept Bob’s messages to Alice. To trick Bob, he creates an open safe (in fact, a key pair) and attaches the name tag “Alice” to that open safe. If Bob sees that safe, he might believe that it belongs to Alice and deposit messages. Of course, Mallory can access those messages, read or modify them, and forward them to Alice’ real safe. Neither Alice nor Bob will notice the difference, and Alice never learns about that fake safe created in her name by Mallory.

Public key infrastructures (PKIs) aim to distribute public keys in such a way that Mallory will be unable to use keys in somebody else’s name. Essentially, PKIs make use of so-called certificates, which are documents containing a public key and a digitally signed statement that the key belongs to a certain person (or organization or machine). In the analogy of open safes, a certificate would be a safe whose name tag is attached via an unforgeable seal. Even without going into details on digital signatures, it should be clear that a PKI shifts the problem of identifying correct public keys into the problem of verifying signatures: Who is able to create unforgeable seals, and how does one verify their authenticity?

The companies, organizations, and individuals creating unforgeable seals are called certificate authorities (CAs), and every CA has its own key pair (or several of them) to create seals. Technically, CAs use their private keys to create seals, while others use the CAs’ public keys to verify the seals’ authenticity. Thus, Alice could ask a CA, say Carol, to attach the name tag “Alice” to Alice’s open safe with Carol’s unforgeable seal. Carol would then check whether Alice really is who she claims to be, before she attaches her seal. If Bob has obtained Carol’s public key, he can verify the authenticity of her seal. If that verification is successful, Bob knows that Carol claims that the safe belongs to Alice. Nothing more, nothing less. Should Bob trust Carol? Maybe Mallory paid, tricked, or forced Carol to claim that his own safe belongs to Alice?

Trust Models

PKIs in the real world follow one of two fundamental trust models, namely anarchy and oligarchy. Maybe neither “anarchy” nor “oligarchy” sound too trustworthy, so let’s start with a hypothetical alternative, democracy. Under democracy, voting is used to determine authorities. Everyone has an equal vote, and those parties receiving most votes are elected as new authorities. It turns out that trust works differently, largely unaffected by majority voting. Even if Carol is unknown to almost everyone, Bob may know her so well that he trusts her to act in certain ways in certain situations, independently of any majority voting. Vice versa, Bob is free not to trust Carol even if everybody around him praises her. Consequently, democracy is not an option for trust.

In an oligarchy, several authorities exist, and you must do as any of them says. This is the “trust” model adopted to secure communication on the Web via SSL/TLS (whenever a Web address begins with https://). There are lots of CAs, whose public keys are embedded as “trust” anchors in every Web browser. The browser “trusts” every of those CAs to sign certificates for every Web address. If you didn’t do so, please take the time to check whom your browser “trusts.” With Firefox, take just six clicks in the menu: Edit / Preferences / Advanced / Certificates / View Certificates / Authorities

For something as fundamental as “trust” anchors, that does not appear to be displayed as prominently as it could be. Whom among that impressive list of authorities do you know, let alone trust? Maybe it helps to check out this lucid visualization of about 650 CAs and their “trust” relationships (a legend is provided by the SSL Observatory).

Nope. That didn’t help, I’m afraid. It gets worse, though.

The bad news is that the “trust” model oligarchy is only as strong as its weakest link. Mallory only needs to pay, bribe, trick, compel, force, or operate a single CA to have his open safe with name tag Alice universally “trusted.” As every CA is “trusted” by every browser to vouch for every name (independently of any prior relationship between certifying and certified parties), the oligarchy fails to provide trust. Pay, bribe, trick, compel, force, or operate. Probably more. That provides a lot of economic, social, legal, and criminal opportunities to choose from.

In fact, you may want to recall some major CA failures demonstrating that different types of Mallory succeed to pay, trick, and compel CAs:

To patch up that broken situation on the Web, several Firefox extensions exist, e.g., HTTPS Everywhere, Certificate Patrol, and Perspectives.

Now for some good news. In an anarchy, you are free to trust. You are free to trust in the natural meaning of the word, as you see reason. Alice does not need to contact or “trust” some Carol if she wants to communicate with Bob in private. She just creates her open safe. Every open safe carries a temper-resistant serial number (a mathematical property, called fingerprint, of the public key), so that Mallory is unable to create a second safe sharing the same serial number. Alice communicates that number to Bob (not via e-mail, of course, which could be intercepted and forged by Mallory, but in person or on the phone). Before Bob places any message in a safe with name tag “Alice”, he verifies whether the safe carries the correct serial number, thus avoiding Mallory’s safe.

Once Bob verified the number, he can even attach his own seal to the name tag “Alice” to demonstrate his trust that the safe really belongs to Alice. Now, if Dave knows Bob and if Dave trusts Bob to attach seals only to the correct safes, he can immediately use Alice’s safe, which is how over time the so-called web of trust emerges.

Monkeysphere is a project to bring anarchy to the Web.

E-Mail with OpenPGP and S/MIME

S/MIME is generally used under the “trust” model oligarchy. If you want to start using S/MIME, you first need a certificate signed by some CA. There are lots of companies selling certificates, some issue them even without payment. Which company do you know? Which one do you trust? Suppose you choose one, for whatever good reasons. Now you want to send an e-mail to me. What makes you think that I place any trust in the CA chosen by you?

In general, I believe the oligarchy to be useful only in the special case of a dictatorship or monopoly. We may be able to trust the same CA. For example, if we work at the same company, we may be reasonably sure about certificates issued by our company’s CA.

Otherwise, we are on our own as far as trust is concerned. Thus, the natural option is to start out in anarchy, and I recommend GnuPG as free software that implements OpenPGP and allows you to build your own web of trust.

Trust me.

Some Pitfalls

At work I’m using GnuPG to encrypt e-mails under both standards, OpenPGP and S/MIME (depending on the recipient). In addition, I use my S/MIME certificate for X.509 authentication with Firefox.

If you need to generate an S/MIME certificate, spend some thought how to do that. Maybe your CA provides a Web form where you generate the certificate in the browser. Clearly, a browser on a networked machine is a pretty unsafe environment to generate keys. If you plan to store your key on a smartcard or e-token, then you may want to generate the key offline via gpgsm or openssl. Without smartcard or e-token, your private key may need to be accessible on a networked machine anyways. In that case, you should make sure that the key is protected by a passphrase. While gpgsm and openssl ask for a passphrase by default, Firefox does not. With Firefox (and Thunderbird), you must set a master password. Otherwise, everyone with access to your profile folder (local admins as well as admins for backups in remote places) can immediately use and steal your private key.

Also, I’d like to point out that some expertise is necessary to use S/MIME based on openssl. As the man pages of openssl’s smime and cms commands document among their BUGS sections, SMIMECapabilities are ignored when encrypting data. Moreover, openssl advertises and defaults to broken encryption algorithms such as RC2, which appears scary to me.

To check out what your S/MIME implementation advertises to others, analyze your own signature. If you sign an e-mail, the signature is contained in an attachment. With Gnus, you can invoke X m (gnus-summary-save-parts) and save the appropriate MIME part (application/pkcs7-signature). Otherwise, save the e-mail and extract its attachments into separate files:

$ munpack <email-file>

One of the extracted files is the signature. Decode that:

$ dumpasn1 <signature-file>

The output contains something like:

...
SEQUENCE {
1640    9:               OBJECT IDENTIFIER
         :                 sMIMECapabilities
...

Immediately afterwards, those encryption algorithms are displayed that should be used by others when sending e-mails to you. I don’t think that you can change that list with openssl, and on Ubuntu 10.04 no AES variant is included. In contrast, S/MIME 3.2 (January 2010) specifies AES-128 as MUST. Not good.

If you use Gnus with S/MIME for e-mails in GNU Emacs, chances are high that you also use openssl. In fact, the subsection on S/MIME in the Message manual only discusses openssl (although gpgsm is supported via EasyPG as well). If, after all that you’ve read here, you are interested in S/MIME with Gnus and gpgsm, I suggest my library ExtendSMIME.

Alice, Bob und der geöffnete Tresor: Ein Plädoyer für E-Mail-Verschlüsselung mit GnuPG

Einleitung

Kennen Sie Alice und Bob?

Im Folgenden stelle ich die beiden und ihre Widersacher, Eve und Mallory, zunächst vor. Wenn Sie es eilig haben, können Sie auch direkt im nächsten Abschnitt weiterlesen, wo es mit E-Mail-Verschlüsselung zur Sache geht.

Alice und Bob sind Personen wie du und ich. Beinahe jedenfalls. Sie sind berühmt, mindestens B-Promis in der Wissenschaft. Sie probieren seit langem immer wieder neue kryptographische Techniken, Verschlüsselungswerkzeuge und Anonymisierungsdienste aus, wie in zahlreichen wissenschaftlichen Publikationen beschrieben wird.

Alice und Bob stehen stellvertretend für alle möglichen Kommunikationspartner: Freunde, Verwandte, Bekannte, Kollegen, Geschäftspartner, Rat suchende und Rat gebende (beruflich, ethisch, familiär, finanziell, juristisch, medizinisch, politisch, privat, religiös …). Sie schätzen persönliche Gespräche sowohl unter vier Augen als auch in größeren Runden, und sie sind sich dabei bewusst, welchen Gesprächspartnern sie wann was und was nicht anvertrauen. Alice und Bob halten die Möglichkeit persönlicher Gespräche mit selbstgewähltem Zuhörerkreis für ein nicht verhandelbares, unveräußerliches Grundrecht.

Alice und Bob nehmen an, sie hätten ein Recht auf private, vertrauliche Kommunikation und Gedanken- und Meinungsfreiheit unter der Unschuldsvermutung. Wie genau Alice und Bob zu dieser früher selbstverständlichen und heute vielleicht naïv oder irrwitzig anmutenden Annahme gekommen sind, spielt hier keine Rolle. Wichtig ist aber, dass Alice und Bob wissen, dass sie ihre Rechte aktiv wahrnehmen müssen, ohne Hilfe durch Dritte erwarten zu können. Während Alice und Bob früher allgemein als paranoide Spinner oder subversive Elemente wahrgenommen wurden, werden ihre Bemühungen um den Schutz persönlicher Kommunikation seit der von Edward Snowden ins Rollen gebrachten Überwachungs- und Spionageaffäre eher verstanden.

Heute weiß jedes Kind, dass jede elektronische Kommunikation ausspioniert, abgehört und überwacht wird. Bis vor Kurzem hätten wir dies nur in totalitären oder faschistischen Gesellschaften für möglich gehalten. Heute ist weltweit politische, juristische und technische Gegenwehr erforderlich. Und ethische Bildung.

Die Herausforderung ist um so größer, als unser Leben mit elektronischer Kommunikation verschmilzt. Unsere PCs, Tablets, Smartphones, Spielekonsolen, Fernseher, Armbanduhren, Brillen, Autos, Stromzähler, E-Books und was-weiß-ich werden zu Augen, Ohren, Positions- und Gesinnungsmeldern für und gegen uns und andere. Eben Moglen hat das resultierende verworrene Netz besser beschrieben, als ich es kann. In seiner vierteiligen Vortragsreihe diskutiert er die Zukunft nach Snowden ausführlich. Hervorheben möchte ich den von ihm betonten ökologischen Aspekt der Privatsphäre.

Ökologische Herausforderungen können nur durch koordiniertes Handeln vieler Akteure überwunden werden, im Großen wie im Kleinen. Ähnlich ist es mit Privatsphäre. Vordergründig hat jede Einzelne die Wahl, ihr E-Mail-Konto (oder ihr Fotoalbum oder ihr Tagebuch) bei einer Datenkrake zu eröffnen oder auch nicht. Sie unterschreibt dazu eine in der Regel ungelesene und unverständliche Datenschatzvereinbarung, die der Datenkrake weitestgehende Rechte an persönlichen Daten einräumt. Die Datenschatzvereinbarung betrifft jedoch nicht nur die Einzelne. In dem Moment, wo Sie sich für die Datenkrake entscheiden, sind auch Ihre Gesprächspartner gezwungen, persönliche Nachrichten, die für Sie gedacht sind, der Datenkrake anzuvertrauen, ohne die Datenschatzvereinbarung überhaupt zu kennen. Anstatt Ihre Gesprächspartner der Datenkrake in die Saugnäpfe zu treiben, könnten Sie sich allerdings auch entscheiden, für an Sie adressierte Nachrichten einen heimischen Briefkasten oder Tresor aufzustellen, zu dem nur Sie den Schlüssel besitzen.

Seit Alice’ und Bobs ersten Experimenten mit Verschlüsselungstechniken sind die verfügbaren Werkzeuge stetig verbessert worden. Das Aufstellen eines heimischen Tresors durch Verschlüsselung ist heute so einfach wie nie zuvor. Verschlüsselung ist so einfach, dass es keinen guten Grund mehr gibt, private Kommunikation nicht zu verschlüsseln. Alice und Bob schützen sich durch Verschlüsselungstechniken vor Angreifern, die typischerweise Eve (von engl. eavesdropper, Lauscherin) und Mallory (von engl. malicious attacker, hinterhältiger Angreifer) heißen.

Eve und Mallory halten Grundrechte und Menschenwürde nicht für besonders wichtig, jedenfalls solange es um Rechte und Würde anderer geht. Sie versuchen, so viel Kommunikation wie möglich zu belauschen, um die gewonnenen Erkenntnisse für unterschiedlichste Zwecke einzusetzen. So ist Eve die neugierige Bekannte, Freundin, Verwandte oder Kollegin, die ihre Nase in alles hineinsteckt, was sie nichts angeht. Früher war sie auf herumliegende geöffnete Briefe oder „zufällig“ mitgehörte Gespräche angewiesen. Heute arbeitet sie für den Internet- oder E-Mail-Provider von Bob oder im Rechenzentrum von Alice’ sozialem Netzwerk oder bei einem in- oder ausländischen Nachrichtendienst. In jedem Fall kommen heute alle E-Mails, Telefonate und sonstige Nachrichten als offene Postkarten bei ihr vorbei. Da kann sie einfach nicht widerstehen …

Mallory ist schlimmer als Eve. Er ist nicht nur neugierig, sondern auch bösartig. Er manipuliert Telefone, Computer, Datenleitungen, Software, Protokolle und Nachrichten, um Informationen zu sammeln und um andere in die Irre zu führen. Mallory könnte der Ex-Freund von Alice sein, der ihr von Herzen alles Schlechte wünscht und unbedingt verhindern will, dass sie mit diesem Nerd Bob glücklich wird. Dann verschickt Mallory E-Mails mit gefälschtem Absender an Alice, sagen wir im Namen von Alice’ Freundin Carol. „Carol“ erkundigt sich dort beiläufig, seit wann Alice denn nicht mehr mit Bob zusammen sei und was sie von seiner gut aussehenden neuen Freundin halte, mit der sie ihn kürzlich eng umschlungen gesehen habe …

Andere Mallorys sind gewöhnliche oder ungewöhnliche Kriminelle, die mit Online-Banking- oder Bundes-Trojanern in die Rechner von Alice und Bob einbrechen wollen. Weitere Mallorys sind mit praktisch unbeschränkten finanziellen Mitteln ausgestattete Nachrichtendienste, die sich das Unrecht herausnehmen, weltweit jegliche Kommunikation in ihre Rechenzentren umzuleiten und dort unter dem Vorwand der Terrorabwehr für Kontrolle, Unterdrückung, Abschreckung, Erpressung, Inlands-, Auslands- und Industriespionage auszuwerten.

Alice und Bob können heute sicher sein, dass ihre elektronische Kommunikation als Kopie in von Eve und Mallory kontrollierten Rechnern landet. Außerdem können sie sicher sein, dass sie von ihren eigenen, Spionage betreibenden Regierungen weder Schutz noch Hilfe erwarten dürfen. In dieser Ausgangssituation sollten Alice und Bob nicht hoffen, sich wirksam vor jeder Eve und jedem Mallory schützen zu können. Alice und Bob sorgen aber dafür, dass sie nicht jede ihrer Nachrichten jeder Eve und jedem Mallory auf dem Silbertablett servieren. Dazu werden sie selbst aktiv, informieren sich und setzen verschiedene Maßnahmen zur Informationssicherheit ein, von denen im Folgenden die E-Mail-Verschlüsselung als Tresor für persönliche Nachrichten thematisiert wird.


E-Mail-Verschlüsselung

Da Alice und Bob nicht möchten, dass Eve ihre E-Mails lesen und Mallory sie beliebig fälschen kann, müssen sie diese verschlüsseln und durch sogenannte digitale Unterschriften gegen Manipulationen sichern. Aus dem Text einer E-Mail wird dann eine unverständliche, zufällig aussehende Zeichenfolge, mit der Eve und Mallory nichts anfangen können.

Haben Sie keine Angst: Verschlüsseln ist nicht so kompliziert, wie oft behauptet wird. Die im Zusammenhang mit Verschlüsselung verwendeten Begriffe mögen ungewohnt sein, kompliziert ist das aber nicht.

Im folgenden Abschnitt erkläre ich E-Mail-Verschlüsselung zunächst durch die Analogie eines geöffneten Tresors. Diese Erklärung endet mit der Aufforderung, eine E-Mail anhand einer Anleitung mit Bildschirmfotos zu verschlüsseln. Nachdem Sie das gemacht haben, möchten Sie vielleicht mehr Details wissen, denen sich der Rest des Textes widmet.


Der geöffnete Tresor

Wenn Alice vertrauliche Nachrichten empfangen möchte, muss sie einen geöffneten Tresor bereitstellen. Das ist alles.

Bob kann seine Nachricht dann in den Tresor von Alice legen. Wenn er den Treser schließt, schnappt das Schloss zu, und niemand außer Alice – weder Eve noch Mallory noch Bob selbst – kann auf die Nachricht zugreifen. Nur Alice, die die öffnende Zahlenkombination (oder den öffnenden Schlüssel) zum Tresor besitzt, ist jetzt noch in der Lage, an Bobs Nachricht zu gelangen und diese zu lesen.

So einfach ist das. Alice benötigt nur einen Tresor, zu dem niemand außer ihr die öffnende Kombination besitzt.

Im Rahmen der E-Mail-Verschlüsselung werden der Tresor und die öffnende Zahlenkombination durch ein sogenanntes Schlüsselpaar verkörpert. So ein Schlüsselpaar besteht aus zwei Schlüsseln, einem öffentlichen und einem geheimen (oder privaten) Schlüssel. Der Tresor entspricht dem öffentlichen Schlüssel. Entsprechend verschlüsselt Bob seine Nachrichten an Alice mit ihrem öffentlichen Schlüssel. Die den Tresor öffnende Zahlenkombination entspricht dem geheimen Schlüssel, mit dem Alice die an sie verschlüsselten Nachrichten entschlüsselt. Wie die Begriffe „geheim“ und „öffentlich“ schon andeuten, muss Alice gut auf ihren geheimen Schlüssel aufpassen, so dass dieser nie in fremde Hände gerät, während sie ihren öffentlichen Schlüssel weitergibt.

Am Computer werden Tresor und öffnende Zahlenkombination durch Zahlen dargestellt, und die Nachricht im geschlossenen Tresor ist unverständlicher Kauderwelsch. Wie diese Zahlen genau aussehen, ist Thema moderner Magie, der sogenannten asymmetrischen (genauer der hybriden) Verschlüsselung, deren Details in zahlreichen Lehrbüchern dargestellt werden. Alice und Bob erstellen und verwenden die notwendigen Zahlen mit geeigneter Software; Bob macht das, ohne diese Magie zu verstehen. (Alice und Bob können auch nicht erklären, wie die Magie eines Fernsehers funktioniert, sie verwenden ihn trotzdem.)

GnuPG (GNU Privacy Guard, gpg, deutsch etwa „Privatsphäre-Wächter“) ist bewährte freie Software, die diese Magie nutzbar macht. Mit GnuPG stellt Alice ihren persönlichen, an ihre E-Mail-Adresse gebundenen Tresor mit öffnender Zahlenkombination her. Dann erzählt sie Familie, Freunden und Bekannten, dass diese ihre Nachrichten von nun an in ihren Tresor legen sollen. Dafür müssen auch diese GnuPG verwenden.

Das ist die zentrale Herausforderung.

Alice muss einen Tresor aufstellen, und ihre Gesprächspartner müssen den Willen aufbringen, den Tresor zu benutzen (und eigene Tresore für die an sie adressierten E-Mails aufstellen).

Eine Anleitung mit Bildschirmfotos zur Nutzung von GnuPG mit dem E-Mail-Programm Thunderbird und der GnuPG-Erweiterung Enigmail finden Sie bei „Verbraucher sicher online“. Sie werden dort schrittweise von der Installation über die Erzeugung eines Schlüsselpaares und den Austausch öffentlicher Schlüssel bis zu Ver- und Entschlüsselung geleitet. Probieren Sie das unbedingt aus. Verschlüsseln ist nicht so kompliziert, wie oft behauptet wird. Für erste Tests mit verschlüsselten Nachrichten bietet sich der freundliche E-Mail-Roboter Adele an.

Wichtiger als die Lektüre des Rests dieses Textes wäre jetzt, dass Sie ein erstes Schlüsselpaar erstellen und sich eine verschlüsselte E-Mail von Adele schicken lassen, die Ihnen garantiert antwortet.

Ich warte hier so lange.

Einige Details

Alice und Bob setzen mit geöffnetem Tresor und öffnender Zahlenkombination sogenannte asymmetrische Verschlüsselungsverfahren ein, die auch als Public-Key-Verfahren bekannt sind. Nach heutigem Kenntnisstand sind die zugrunde liegenden Verschlüsselungstechniken selbst gegenüber Geheimdiensten wie der NSA sicher. (Mallory würde eher versuchen, einen Trojaner in Bobs Rechner einzuschleusen. Dieser Trojaner fängt dann die E-Mails im Klartext ab, nachdem Bob sie zum Lesen entschlüsselt hat oder noch bevor er sie nach dem Schreiben verschlüsselt hat.)

Alice und Bob benutzen die freie Software GnuPG, die dem Internet-Standard OpenPGP zur E-Mail-Verschlüsselung folgt. Sie befinden sich damit in guter Gesellschaft namhafter Sicherheitsexperten wie Bruce Schneier. (Im Unternehmenskontext wird oftmals auf S/MIME anstelle von OpenPGP gesetzt. Für Privatanwender ist das nicht zu empfehlen, weil (a) die Einrichtung und sichere Erstellung eines Schlüsselpaares deutlich komplizierter ist und (b) sie gezwungen sind, in der Regel nicht vertrauenswürdigen Zertifizierungsstellen zu vertrauen. Ferner halten Alice und Bob De-Mail für Quatsch, und auch das Sommermärchen 2013 von mehr Sicherheit durch Umstellung auf verschlüsselten E-Mail-Versand bei deutschen Providern ersetzt keine eigene E-Mail-Verschlüsselung.)

Wie oben beschrieben benötigen Alice und Bob zunächst beide jeweils ein Schlüsselpaar, bestehend aus einem öffentlichen und einem geheimen Schlüssel. Diese Schlüsselpaare erstellen sie auf ihren eigenen Rechnern und händigen sich gegenseitig ihre öffentlichen Schlüssel aus. Sämtliche Schlüssel (eigene und fremde) legen sie in ihrem sogenannten Schlüsselbund ihrer Software ab. Dann verschlüsselt Bob E-Mails an Alice mit ihrem öffentlichen Schlüssel; sie entschlüsselt diese mit ihrem geheimen Schlüssel. Umgekehrt verschlüsselt Alice E-Mails an Bob mit seinem öffentlichen Schlüssel; er entschlüsselt mit seinem geheimen Schlüssel.

Wenn Bob seinen geheimen Schlüssel verliert (z. B. weil seine Festplatte den Geist aufgibt und er kein Backup besitzt oder weil er die im Rahmen der Schlüsselerzeugung gewählte Passphrase vergessen hat), sind die verschlüsselten Daten verloren. Vermutlich könnte nicht einmal die NSA ihm weiterhelfen.

Falls Sie sich wundern: Wenn Bob eine E-Mail an Alice verschlüsselt, kann er den Text selbst nicht mehr lesen, weil er Alice’ geheimen Schlüssel nicht besitzt (er kann Alice’ geöffneten Tresor schließen, kennt aber die öffnende Kombination nicht). Daher verschlüsselt er E-Mails immer auch mit seinem eigenen öffentlichen Schlüssel an sich selbst. Der dadurch entstehende Tresor besitzt dann zwei Türen: eine für Alice’ geheime Kombination und eine für seine eigene.

Bevor verschlüsselt werden kann, müssen also öffentliche Schlüssel ausgetauscht und im Schlüsselbund abgelegt werden. Dies kann auf verschiedene Arten geschehen: Persönlich z. B. per USB-Stick, per E-Mail, durch Veröffentlichung auf einem Web-Server oder durch Veröffentlichung auf einem Key-Server. Eine Herausforderung besteht noch darin sicherzustellen, dass ein öffentlicher Schlüssel dem „richtigen“ Empfänger gehört. Andernfalls könnte Bob seine Nachrichten in einen Tresor legen, der zwar mit „Alice“ beschriftet ist, der aber von ihrem Ex Mallory aufgestellt worden ist …

Ob Mallory durch so einen gefälschten Tresor wirklich an die Nachrichten von Bob kommen würde, hängt von einigen Details ab. Stellen Sie sich folgendes Szenario vor: Mallory legt sich eine E-Mail-Adresse in Alice’ Namen zu. Das ist in der Regel einfach. Sagen wir, er wählt alice@example.com. Dann erstellt er auf seinem Rechner ein Schlüsselpaar zu dieser E-Mail-Adresse und schreibt Bob eine E-Mail mit Absender alice@example.com. Ob er diese mit Bobs öffentlichem Schlüssel verschlüsselt und ob er sie mit seinem geheimen Schlüssel signiert, spielt keine große Rolle; vermutlich macht er beides, weil er hofft, das sähe vertrauenerweckender aus. Er schreibt: „Lieber Bob, ich habe mir eine neue E-Mail-Adresse zugelegt, die ich nur für verschlüsselte E-Mails nutzen möchte. Dazu habe ich ein GnuPG-Schlüsselpaar erstellt. Füge den im Anhang enthaltenen öffentlichen Schlüssel doch bitte deinem Schlüsselbund hinzu. LG Alice.“ Wenn Bob diesen Schlüssel verwendet, legt er seine E-Mails in einen Tresor von Mallory. Mallory kann sie natürlich entschlüsseln und den Text an die echte E-Mail-Adresse von Alice weiterleiten (zumindest mit zu „Bob“ gefälschter Absenderadresse, eventuell auch weiteren gefälschten Details). Alice erfährt dabei nie, dass es die Adresse alice@example.com überhaupt gibt, und weder Alice noch Bob merken, dass Mallory sie in der Rolle eines sogenannten Man-in-the-middle hintergeht.

Damit Alice und Bob nicht Opfer so eines Man-in-the-middle-Angriffs werden, sondern sicher sind, dass sie die richtigen Tresore verwenden, vergleichen sie sogenannte Schlüssel-Fingerabdrücke, die sie sich separat mitteilen. Der Fingerabdruck eines Schlüssels ist eine Zeichenkette wie 7482 02DB 2697 708B 9C0C 4FA4 7D5C 06FE A142 FD84, die den Schlüssel eindeutig identifiziert, etwa so wie eine fälschungssichere Seriennummer einen Tresor identifizieren würde. Mit dem in obiger Anleitung beschriebenen Enigmail kann der Fingerabdruck eines Schlüssels durch die Menüfolge „OpenPGP“ / „Schlüssel verwalten …“ / Rechtsklick auf E-Mail-Adresse und „Schlüsseleigenschaften“ angezeigt werden. Wenn Alice und Bob ihre öffentlichen Schlüssel nicht persönlich ausgetauscht haben, teilen sie sich die Fingerabdrücke ihrer öffentlichen Schlüssel mit (nicht per E-Mail, sondern z. B. per Telefon) und vergleichen diese mit den Fingerabdrücken im Schlüsselbund.

Wie Erzeugung, Veröffentlichung und Verwendung von GnuPG-Schlüsseln im Detail funktionieren, können Sie im „GNU-Handbuch zum Schutze der Privatsphäre“ oder auch bei „Gpg4win für Einsteiger“ nachlesen, das Gpg4win behandelt, eine kinderleicht einzusetzende, freie GnuPG-Variante für ein unfreies, aber verbreitetes Betriebssystem. Umfassende deutschsprachige Darstellungen mit vielfältigen technischen Details finden Sie zudem bei Hauke Laging und im Raven Wiki.


Software

Alice und Bob benötigen ein E-Mail-Programm, das einfache Unterstützung für OpenPGP mitbringt; unter anderem verweist das GnuPG-Projekt auf Enigmail in Kombination mit dem freien E-Mail-Programm Thunderbird. Diese Kombination haben Sie bereits ausprobiert, als Sie der oben genannten Anleitung bei „Verbraucher sicher online“ gefolgt sind, oder? Falls Sie das nicht getan haben, sollten Sie das nachholen. Andernfalls lesen Sie diesen Artikel vermutlich mit wenig Gewinn.

Bob musste sich umgewöhnen, weil er E-Mails zuvor im Web-Browser gelesen hat, was für verschlüsselte E-Mails wenig geeignet ist. (Es gibt GnuPG-Browser-Erweiterungen wie WebPG für den Firefox. Ein E-Mail-Programm wird dadurch nach Bobs Meinung aber nicht ersetzt.)

Bob hat sich für Thunderbird entschieden, wo er beim ersten Start einfach seine bisherige E-Mail-Adresse angegeben hat; Thunderbird ruft die E-Mails direkt von seinem E-Mail-Provider ab bzw. sendet neue E-Mails über diesen zum Empfänger. Um Thunderbird das Verschlüsseln mit GnuPG beizubringen, hat er (neben GnuPG oder gpg4win) die Thunderbird-Erweiterung Enigmail installiert (im Thunderbird über die Menü- und Befehlsfolge „Extras“ / „Add-ons“ / Suchfeld: „Enigmail“ / „Installieren“). Die Installation dieser Software ist Teil der mehrfach angesprochenen Anleitung.

Alice und Bob sind sich im Klaren, dass Ver- und Entschlüsselung unterwegs nur eingeschränkt möglich sein können. Sie benötigen dazu Zugriff auf ihren Schlüsselbund und geeignete Software – mal eben im Internet-Café geht das nicht. So schlimm ist das aber auch wieder nicht, weil für beide das Eingeben ihres E-Mail-Passwortes an einem öffentlich zugänglichen Rechner eh nicht in Frage kommt: Wer weiß schon, welcher Mallory dort die Kontrolle ausübt.

Auch für Smartphones gibt es E-Mail-Programme mit OpenPGP”=Unterstützung. Wer seine verschlüsselten E-Mails normalerweise am PC liest und schreibt, sollte allerdings überlegen, ob der geheime Schlüssel auf dem Smartphone ebenso sicher ist wie auf dem PC: Das Smartphone geht leichter verloren, und oftmals mangelt es an Updates, die kritische Sicherheitslücken schließen. Alice und Bob übertragen ihre am PC erzeugten Schlüssel jedenfalls nicht auf Telefone; für auf Smartcards gespeicherte Schlüssel stellt sich diese Frage noch nicht einmal. Wer allerdings E-Mail bevorzugt über das Smartphone abwickelt, erhöht natürlich auch hier die Sicherheit durch den Einsatz von OpenPGP. Für Android kommt K-9 Mail mit APG in Frage. Beide gibt’s bei F-Droid und im Play Store.


Digitale Signaturen

Oben habe ich kurz erwähnt, dass Alice und Bob ihre Nachrichten nicht nur verschlüsseln, sondern auch digital unterschreiben. Eine digitale Unterschrift oder Signatur dient dem Nachweis, dass eine Nachricht zum einen wirklich vom vorgeblichen Absender stammt, und nicht von Mallory, der sich als dieser ausgibt, und zum anderen auf dem Weg von Mallory nicht verändert wurde. Ob Alice und Bob zusätzlich zur Verschlüsselung auch noch signieren oder ob sie auf die Signatur verzichten, können sie von Nachricht zu Nachricht entscheiden; sie können auch unverschlüsselte Nachrichten signieren und dadurch anzeigen, dass sie GnuPG verwenden und offen für verschlüsselte E-Mails sind. Im E-Mail-Programm werden Signaturen auf Knopfdruck oder automatisiert per Einstellung erzeugt. In jedem Fall wird der geheime Schlüssel benutzt, um eine digitale Signatur zu erstellen. Mit Hilfe des zugehörigen öffentlichen Schlüssels kann geprüft werden, ob die Signatur echt ist. (Da Mallory den geheimen Schlüssel von Alice nicht kennt, kann er keine Signaturen in ihrem Namen erzeugen.)

Nebenbei sei darauf hingewiesen, dass Alice und Bob meistens eine ungenutzte Signaturkarte mit sich herumtragen, nämlich ihren Personalausweis. Dieser erlaubt es, digitale Signaturen (unabhängig von E-Mail) zu erstellen. Insofern ist es für jede/n Deutschen sowieso sinnvoll, sich mit den Grundlagen asymmetrischer Kryptographie zu beschäftigen. Leider hat der Gesetzgeber es versäumt, dem Ausweis auch eine Verschlüsselungsfunktion mitzugeben. Der Ausweis führt daher nur zu mehr Kontrolle durch digitale Signaturen ohne die Freiheit der Verschlüsselung.

Alice und Bob verwenden nach einiger Eingewöhnungszeit mit GnuPG übrigens eine OpenPGP-Smartcard als sicheren Schlüsselspeicher. Einige Details dazu habe ich anderswo beschrieben. Dieser Schlüsselspeicher ist immun gegen Trojanerschützt vor dem Diebstahl des Schlüssels durch Trojaner, lässt sich mit Lesegerät auch in den Urlaub mitnehmen, um überall E-Mails entschlüsseln zu können, und wäre sinnvollerweise direkt im Personalausweis enthalten.


Zu guter Letzt

Es gibt für Alice und Bob noch viel zu lernen. So habe ich das Signieren bzw. Zertifizieren von Schlüsseln und das übergeordnete Thema Web of Trust gar nicht angesprochen. Schauen Sie sich mit ausreichend Zeit die „Einführung“ von Hauke Laging an.

Außerdem habe ich einen wichtigen Aspekt bisher nicht betont: Wenn Alice und Bob GnuPG zum Schutz ihrer E-Mails verwenden, können Eve und Mallory die Nachrichteninhalte weder lesen noch unbemerkt verändern. Eve und Mallory können aber immer noch sehen, wann, wo und unter welchem Betreff Alice und Bob verschlüsselte E-Mails versenden und abrufen; die sogenannten Verbindungs- oder Verkehrsdaten werden von der Verschlüsselung nicht geschützt. Evtl. möchten Alice und Bob aber gar nicht, dass überhaupt jemand von ihrer Kommunikation weiß.

Warum auch?

Dann müssen Alice und Bob weitergehende Maßnahmen ergreifen, die auch die Verkehrsdaten schützen. Sie können dazu Remailer verwenden, die E-Mails mehrfach verschlüsselt über Zwischenstationen weiterleiten und dabei identifizierende Daten entfernen.

Zudem behalten Alice und Bob die vielversprechenden Projekte Dark Mail und Pond im Auge. Dark Mail entwickelt ein alternatives E-Mail-Protokoll, bei dem Verschlüsselung eingebaut sein wird, während Pond die Ziele von Off-The-Record-Kommunikation anstrebt. Off-The-Record (abgekürzt mit „OTR“) bezeichnet die natürliche, nicht aufgezeichnete, vertrauliche Kommunikation unter vier Augen, die z. B. dann stattfindet, wenn Alice und Bob sich auf der Parkbank unterhalten: Erstens können sie sicherstellen, dass sie nicht von Eve belauscht werden. Zweitens wissen sie, dass sie nicht versehentlich mit einem verkleideten Mallory sprechen, der sich als einer von ihnen ausgibt. Drittens können sie hinterher alles abstreiten, was sie zuvor gesagt haben. Viertens bleiben keine Spuren ihres Gesprächs zurück, was technisch in etwa durch Perfect Forward Secrecy angenähert werden kann.

Während es für Internet-Chat zahlreiche OTR-Chat-Anwendungen gibt, verletzt E-Mail-Verschlüsselung die Eigenschaft Perfect Forward Secrecy, und bei Verwendung digitaler Signaturen ist auch Abstreitbarkeit nicht gegeben. Um hier Abhilfe zu schaffen, zielt Pond auf den vertraulichen Austausch von Nachrichten – einschließlich der Verkehrsdaten! – mit Perfect Forward Secrecy, erfordert dazu aber separate Pond-Server und setzt auf dem Anonymisierungsnetzwerk Tor auf. Alice und Bob werden das ausprobieren.

Im Übrigen bin ich der Meinung, dass Sie einen geöffneten Tresor aufstellen sollten. Ich empfehle dazu die Anleitung zur E-Mail-Verschlüsselung bei „Verbraucher sicher online“ sowie den freundlichen E-Mail-Roboter Adele.

Das hatte ich bereits erwähnt, oder?

Informationelle Selbstbestimmung trotz Überwachungs- und Spionageaffäre

Meine Web-Seite zur informationellen Selbstbestimmung im Internet bedarf dringend der Überarbeitung. Bisher gehe ich dort auf die Snowden-Enthüllungen nicht ein. Meine ursprüngliche Motivation, mich mit Techniken für Privatsphäre und informationelle Selbstbestimmung im Internet zu beschäftigen, geht zurück auf die Einführung der Vorratsdatenspeicherung in der EU. Nun sehen wir weit mehr als Vorratsdatenspeicherung. Weltweit.

Emotionen angesichts anlassloser Spionage und politischer Untätig- und Hilflosigkeit könnten einen guten neuen Startpunkt liefern. Zum Glück bin ich zufällig auf den herausragenden Beitrag „Die gelähmte Wut“ von Meike Lobo gestoßen. Lesen Sie das. Erkennen Sie sich wieder? Was fühlen Sie?

Ich bin weder wütend, noch fühle ich mich hilflos. Ich empfinde Verachtung und Abscheu, in erster Linie für Politiker, die glauben, der Zweck heilige jedes Mittel, in zweiter Linie für Spitzel, denen Menschenwürde unbekannt ist oder die sie Ausländern (die wir alle bekanntlich fast überall sind) nicht zugestehen. In beiden Linien geht es um Menschen. Die einen gehören abgewählt, die anderen verurteilt. Statt „verurteilt“ wäre bei ausländischen Spitzeln „ausgewiesen“ ein guter Anfang; stattdessen gibt es neben bekannten Standorten auch noch Neubauten.

Also zurück zu „abgewählt“. Neuwahlen stehen bevor.

Politik und ethische Erwägungen beiseite. Ich empfinde auch Faszination. Wie funktioniert Überwachung aus technischer Sicht? Wer wendet welche Techniken wo an? Wie kann ich mich wehren?

Diese Faszination kann auch in Abscheu umschlagen, je nach Detailtiefe und Kontext. Sehen Sie sich diese Bilder an. Faszinierend, oder?

Pollen, https://commons.wikimedia.org/wiki/File:Misc_pollen.jpgMilbe, https://commons.wikimedia.org/wiki/File:Rust_Mite,_Aceria_anthocoptes.jpg

 

Das erste zeigt Pollen, das andere eine Milbe. Manche Menschen bemerken sie nicht einmal, andere regieren allergisch. Wütend werden wenige. Allergiker suchen nach Gegenmitteln oder Vermeidungsstrategien. Ich bin Spionage-Allergiker.

Was mich antreibt, ist die Vorstellung, dass meine Gedanken und meine Meinungsbildungsprozesse frei und privat sein dürfen. Ich befinde mich da in höchstrichterlicher Gesellschaft (auch amerikanischer), die diese Freiheit und Privatsphäre als notwendige Voraussetzung für Selbstverwirklichung und aktive demokratische Teilhabe sieht. Ich will selbst entscheiden, wem ich welche meiner Gedanken wann mitteile. So einfach ist das. Und so komplex. Das fängt bei meinen aktuellen Vorlieben und Meinungen an und geht über Recherche, Lektüre und womöglich vertrauliche Kommunikation bis zur „Veröffentlichung“, sowohl online als auch offline.

Online und offline verschmelzen. Eben Moglen hat dies plastisch mit dem „verworrenen Web“ beschrieben, in das wir unser Offline-Leben immer weiter einweben. Lesen Sie das (oder meine Übersetzung). Smartphones, Brillen und Uhren, Fernseher und Spielekonsolen und was-weiß-ich werden zu Augen, Ohren und Positionsmeldern für uns und andere, im Web werden wir auf Schritt und Klick verfolgt, protokolliert und vorhergesagt, beim Lesen berichten E-Book-Reader, wer was wie lange liest, kommentiert, überspringt oder abbricht. Unternehmen sammeln und verkaufen die zugehörigen Daten unter unverständlichen Datenschatzbedingungen und sind gezwungen, sie diversen (Geheim-) Diensten zur Verfügung zu stellen. Moglen schlägt technische und ökologische Gegenmaßnahmen vor, wie Sie meiner Empfehlung eingangs des Absatzes folgend gelesen haben, oder?

Über den im Heimatland legalisierten Zugriff auf Unternehmensdaten hinaus wollen Geheimdienste alles. Wie im vergangenen Jahrtausend beschrieben und im September 2013 präzisiert wurde, kopieren sie nahezu sämtliche digitale Kommunikation (Telefon, Mobilfunk, Internet) und analysieren diese, sie zwingen Hersteller und Anbieter von Soft- und Hardware sowie Internet-Diensten, Hintertüren einzubauen, um Verschlüsselung auszuhebeln und unabhängigen Datenzugriff zu erlangen, sie sorgen bei der Entwicklung von Verschlüsselungsstandards dafür, dass sicher aussehende Verfahren eingeführt werden, die von den eigenen Experten problemlos gebrochen werden können.

Die meisten Unternehmen ziehen mit und hintergehen ihre Kunden. Eine rühmliche Ausnahme ist Lavabit, ein US-Unternehmen für sichere E-Mail-Dienste, das von seinem Gründer Ladar Levison geschlossen wurde, weil er den Überwachungsauflagen nicht nachkommen wollte. Er darf sich nach US-Recht nicht äußern, spekuliert aber über die Zwänge, private Schlüssel seiner Server weitergeben zu müssen oder Hintertüren einbauen zu müssen. Auf der Web-Seite seiner Firma kommt er zu dem Schluss: “[…] I would _strongly_ recommend against anyone trusting their private data to a company with physical ties to the United States.”

Das sieht übel aus.

Hatte ich nicht geschrieben, dass ich mich nicht hilflos fühle? Das liegt daran, dass ich glaube, nicht persönlich zur Jagd ausgeschrieben zu sein, sondern mich als Fisch unter vielen vom Schleppnetz bedroht sehe. Selbst wenn ich mich irre, sind Sie vielleicht ein Fisch, für den Hoffnung besteht. :-)

Ich gehe davon aus, dass die NSA Verschlüsselungsverfahren wie AES und RSA nicht gebrochen hat und daher für die Verwendung anderer Standards z. B. auf Basis elliptischer Kurven wirbt und die Hinterlegung von geheimen Schlüsseln sowie den Einbau von Hintertüren erzwingt; auch der Verzicht auf Perfect Forward Secrecy in Apple- und Microsoft-Browsern ist vor diesem Hintergrund weniger erstaunlich. Snowden behauptet, dass wir uns auf die Wirksamkeit von Verschlüsselungsverfahren verlassen können, und Bruce Schneier hält dies für richtig. Ein Problem ist allerdings, dass wir (noch) nicht wissen, welche Verschlüsselungsverfahren die NSA (noch) nicht gebrochen hat.

Wie gehe ich vor?

Erstens meide ich die Cloud. Es ist unsinnig und technisch unnötig, private Daten unkontrolliert Dritten zu überlassen. Um im obigen Bild zu bleiben, werfe ich mich nicht sehenden Auges ins Schleppnetz. Die Web-Seite PRISM-Break listet zahlreiche Alternativen zu beliebten Datenkraken auf.

Zweitens setze ich, wie Bruce Schneier, auf kryptographische Sicherheitsmaßnahmen. Ich kann nicht verhindern, dass meine Internet-Kommunikation ins Schleppnetz gerät. Ich möchte es den Spitzeln aber wenigstens so schwer wie möglich – wenn nicht sogar unmöglich – machen zu verstehen, was sie da in ihrem Netz haben. Ich anonymisiere mein Surf-Verhalten mit Tor und verschlüssele (interessierte Empfänger vorausgesetzt) E-Mails mit GnuPG. Dies und mehr ist Thema meiner Web-Seite, die ich nach diesem klärenden Selbstgespräch dringend überarbeiten muss.