Bluetooth-Kopfhörer-Verbindung

Ich hatte lange das Problem, dass kurz nachdem Bluetooth-Verbindungsaufbau von meinem Arch Linux (Thinkpad x220) die Verbindung wieder beendet wurde.

Die Lösung:

# Verbindung beenden (falls noch nicht geschehen), dann:
pactl load-module module-bluetooth-discover

Via Ubuntu Forums

Dauerhaft aktivieren sollte man vielleicht diese Zeilen in /etc/pulse/default.pa

.ifexists module-bluetooth-policy.so
load-module module-bluetooth-policy
.endif

.ifexists module-bluetooth-discover.so
load-module module-bluetooth-discover
.endif

Konflikt mit libutf8proc: /usr/lib/libutf8proc.so.2

Ich habe mich entschlossen, die ab und zu auftretenden Probleme mit Arch Linux zu dokumentieren — für mich selbst hauptsächlich. Bei der hohen Update-Frequenz und den Rolling-Updates treten halt anders als bei Ubuntu oder Debian häufiger mal Hindernisse auf. Auf gehts:

Bei einem System-Update mit sudo pacman -Syu tritt gerade das Problem auf, dass das Update nicht durchläuft wegen eines Konflikts:

Fehler: Konnte den Vorgang nicht durchführen (In Konflikt stehende Dateien)
libutf8proc: /usr/lib/libutf8proc.so.2 existiert im Dateisystem

Die Lösung ist auf archlinux.org beschrieben. Einfach überschreiben:

sudo pacman -Syu --overwrite usr/lib/libutf8proc.so.2

Das wars.

Mein Gesicht im Internet

Rene
Seit Jahren achte ich darauf, dass mein Gesicht nicht im Internet zu finden ist — nicht auf Fotos jedenfalls.

Manch einer fragt sich, warum ich das tue. Ob ich mich vielleicht für wichtiger als andere halte? Nein, natürlich bin ich nicht wichtiger als andere. Es ist auch keine neue Marotte von mir oder eine Mode — ich handhabe Fotos und Videos von mir seit Jahren so.

Vielmehr befürchte ich, dass mein Gesicht missbraucht werden kann, beispielsweise bei CatFishing. Außerdem: Wenn es einmal zu einem GAU gekommen ist, ist es sehr schwer und teuer bis unmöglich, wieder Herr der Lage zu werden.

Ich habe einfach mal eine Liste zusammengestellt mit Informationen, die hoffentlich meinen Standpunkt erklären helfen:

Ich hoffe daher auf Verständnis, dass ich unter keinen Umständen mein Gesicht auf Fotos oder Videos im Internet oder Intranet sehen möchte.

How to unlock a dm-crypt-encrypted second harddisk with a static key

Let’s assume you have a device that boots from an encrypted SSD and also has a encrypted spinning disk for storage. Further let’s assume that you unlock the system disk and the spinning disk with a dedicated password each boot.

At least that’s my current situation. I have grown tired of entering two 20+ chars password each time my notebook boots so I have decided to unlock the spinning disk using a static key from the encrypted system disk. That’s certainly not the holy grail of IT security but anyway. Security and ease of use must go hand in hand in my opinion.

Also note: Do the following steps on your own risk.

Let’s go: Save the password as the static key (NOTE: do not do this if you encrypt a NEW disk or partition. Instead, generate a much more secure (ie. longer) static key as described in the Arch wiki — the following mini how-to is just for easy “retrofitting” existing encrypted disks with static key unlocking).

sudo touch /etc/luks_static_key
sudo chown root:root /etc/luks_static_key
sudo chmod 0400 /etc/luks_static_key
sudo $EDITOR /etc/luks_static_key # enter the password and save

Change the encrypted disk’s entry in /etc/crypttab like so (your line might vary a bit) from

name_of_dmcrypt_device UUID=the_uuid none luks

to
name_of_dmcrypt_device UUID=the_uuid /etc/luks_static_key

For the last step you will need to give the name of the encrypted partition. Find out what the name is using lsblk. The output might look like this:
NAME              MAJ:MIN RM SIZE    RO   TYPE  MOUNTPOINT
sda               8:0     0  931,5G  0    disk
|--sda1           8:1     0  931,5G  0    part
   |--crypt_dev 254:4     0  931,5G  0    crypt /mnt/crypt_dev

The encrypted partition in this case is /dev/sda1. Now use cryptsetup to make the static key file known:
cryptsetup luksAddKey /dev/sda1 /etc/luks_static_key # enter the password of the device

Boom. During the next boot sequence you should only be asked for the system disk password. The spinning disk will be unlocked using the static key file from the system disk.

Did this mini how-to help you in any way or do you have suggestions? Leave a comment.

Sichere E-Mail-Kommunikation in Zeiten von NSA- und GCHQ-Überwachung

In den letzten Wochen ist mir eine gewisse Unsicherheit aufgefallen, was E-Mail-Kommunikation angeht. Die Regel — zumindest bis vor ein paar Monaten — war es, dass der Transportweg von E-Mails nicht durchgängig verschlüsselt gewesen ist und Geheimdienste leichtes Spiel hatten und noch immer weitgehend haben, E-Mail-Kommunikation umfassend abzuhören und Nutzerprofile zu erstellen. Das gleiche gilt übrigens für Kriminelle, wobei die Grenze zwischen beiden Gruppen mittlerweise unklar ist:

  • Kollegen, Dienstleister, befreundete Unternehmen und Unternehmer drücken sich nicht mehr klar in E-Mails aus oder verzichten eher mal darauf, eine E-Mail zu schreiben.
  • Der Steuerberater schickt vertrauliche Informationen nicht mehr einfach so per E-Mail, was an sich schon mal gut ist und Medienkompetenz ausstrahlt.
  • Hotelrechnungen lässt man sich inzwischen ungern per Mail zustellen, weil man nicht weiß, wie sicher der Transportweg ist — und Hotelrechnungen dürften mit einiger Sicherheit zu den interessanteren Informationen für Geheimdienste zählen.

Was kann man tun, um der Unsicherheit entgegenzuwirken?

Grundsätzlich halte ich nichts von den politischen Bestrebungen, ein “deutsches” oder “europäisches” Mailserver-Kommunikationsnetz aufzuziehen, das “einheimische” oder gar “deutsche” Verschlüsselungsalgorithmen verwendet. Ich denke, in der IT-Branche ist es Konsens, dass diese Forderungen a) Unsinn sind und gegen den freien Geist des Internets verstoßen und b) die Forderung nach Entwicklung “eigener” Verschlüsselungsalgorithmen kaum umsetzbar (weil sehr teuer und langwierig) ist und es bereits sichere Algorithmen und Protokolle gibt, beispielsweise AES und TLS 1.2.

Man muss die vorhandenen sicheren Systeme und Programme nur mal einsetzen, richtig und konsequent.

Praktische Lösungen

Seit Jahrzehnten gibt es PGP (und die freie Umsetzung GPG). Das Programm verschlüsselt den Inhalt von E-Mails. Vorteile:

  • Die Software ist jahrelang im Einsatz und gilt als sicher
  • Ist verfügbar für alle Systeme
  • Freie Open-Source-Software

Es gibt aber auch Nachteile:

  • Das dem System zugrunde liegende Public-Key-Konzept ist zwar eigentlich einfach, aber für Laien dennoch nicht auf Anhieb verständlich
  • Die Benutzerfreundlichkeit von PGP/GPG-Programmen ist oft nicht besonders hoch, daher hat das System bislang keine hohe Verbreitung gefunden.
  • Metadaten wie Absender, Empfänger und Betreff werden nicht verschlüsselt. Das ermöglicht Abhörern noch immer, umfassende Kommunikationsprofile zu erstellen.

Die Gegenargumente möchte ich nicht als Grund verstanden wissen, auf PGP/GPG zu verzichten.

PGP/GPG sollte man sicherlich verwenden, insbesondere wenn es um Geheimnisträger wie Rechtsanwälte, Journalisten und Steuerberater geht.

Wichtiger finde ich dennoch, nicht nur den Inhalt von E-Mails zu verschlüsseln, sondern den Transportweg an sich. Der ist in drei Teile gegliedert:

  1. Der Weg vom Rechner des Absenders zu seinem Mailserver
  2. Der Weg vom Mailserver des Absenders zum Mailserver des Empfängers
  3. Der Weg vom Mailserver des Empfängers zum Rechner des Empfängers.

Bislang konnte man auf dem Weg zwischen Mailserver und Empfänger schon recht gut einstellen, ob und wie verschlüsselt wird. Zwischen Mailservern hingegen hat das mal geklappt und mal nicht. Empfänger und Absender haben in der Regel nicht erfahren, ob die Kommunikation verschlüsselt war oder nicht — das war quasi ein Glücksspiel. Mit dem Unterschied, dass man hinterher nicht erfahren hat, ob man gewonnen oder verloren hatte.

Die Situation verbessert sich langsam, zumindest in Deutschland — immerhin:

Mittlerweile gibt es deutsche Unternehmen, die explizit sichere Maildienste anbieten (ohne Gewähr oder Anspruch auf Vollständigkeit):

Besonderheit bei mailbox.org: Der Dienst wird von Heinlein Support GmbH betrieben. Das Unternehmen ist lange am Markt und genießt in der IT-Branche einen exzellenten Ruf (ich bekomme übrigens kein Geld für diese Empfehlung und auch keine sonstigen direkten Vorteile).

Angeboten wird neben Dateisynchronisierung die Möglichkeit, abgestuft auf die Art und Weise Einfluss zu nehmen, wie Mailserver untereinander kommunizieren dürfen (“egal”, “verschlüsselt”, “nachvollziehbar verschlüsselt”, “verschlüsselte Kommunikation nur mit bekannt sicheren Mailservern”, bei mailbox.org genannt “aus”, “encrypt”, “verify”, “secure”).

Erzwingt man Verschlüsselung und stößt der mailbox.org-Mailserver auf eine Gegenstelle, die die Sicherheitsanforderungen nicht erfüllt, schlägt die Kommunikation fehl und man bekommt eine Meldung darüber. Das ist so gewollt und stellt sicher, dass Daten nur verschlüsselt übertragen werden. Würde das jeder Mensch und jeder Mailserver so machen, hätten Geheimdienste und Kriminelle es sehr schwer, a) den Inhalt der Daten abzuhören und b) Kommunikationsprofile zu erstellen.

Ich empfehle daher allen meinen Kollegen, Geschäftspartnern und -freunden, sich einen sicheren Mail-Dienstleister zu suchen, zu nutzen, und ein hohes Datenschutzniveau einzustellen.

Schließlich wollen wir alle die Vorteile der E-Mail-Kommunikation weiterhin nutzen und uns nicht aus Angst vor Geheimdiensten und Kriminellen zurückziehen.

Weiterhin empfehle ich den Einsatz von PGP/GPG, mein öffentlicher Schüssel ist auf sks-keyservers.net zu finden.

Ich bin gerne kostenlos dabei behilflich, Euch/Ihnen bei der Einrichtung von PGP/GPG zu helfen, schließlich habe ich selbst Interesse daran, sicher zu kommunizieren.

PS: Was ist mit DE-Mail?

Es gibt dort bislang keine durchgehende Verschlüsselung. Kriminelle werden es mit DE-Mail sicherlich viel schwerer haben als im “freien Netz”, aber Geheimdienste hätten technisch noch immer eine Möglichkeit, auf den Inhalt und die Metadaten  zuzugreifen. Außerdem halte ich es für aussichtslos und Unsinn, mit nationalen Insellösungen globale Probleme lösen zu wollen.