Health-Daten in die iCloud synchronisieren

Die Gesundheitsdaten welche unter iOS gespeichert werden, können über die Health-App angeschaut werden. Möchte man die Daten von einem iOS-Gerät zu einem anderem iOS transferieren, so funktionierte dies bis iOS 11 nur über ein verschlüsseltes iTunes-Backup. Dieses musste von einem Gerät zum anderen Gerät transferiert werden.

Health-Synchronisierung in den iOS-Einstellungen

Seit iOS 11 können die Gesundheitsdaten über die iCloud synchronisiert werden. Dafür muss das Ganze in den Einstellungen unter Apple ID (bzw. Name) -> iCloud aktiviert werden. Damit stehen die Gesundheitsdaten auf allen iOS-Geräten mit der gleichen Apple ID zur Verfügung. Standardmäßig ist die Option aufgrund der sensiblen Daten deaktiviert. Laut einem Support-Dokument von Apple werden die Daten bei der Synchronisierung über iCloud verschlüsselt:

Für die Übertragung zwischen iCloud und Ihrem Gerät sowie für die Speicherung in iCloud werden die Daten verschlüsselt.

Auf der Infoseite zu Health gibt es ähnliche Informationen:

Mit iCloud werden alle deine Gesundheitsdaten auf allen deinen Geräten automatisch aktualisiert und dabei verschlüsselt übertragen und in iCloud abgelegt.

Wie genau die Verschlüsselung funktioniert und ob es sich um eine Ende-zu-Ende-Verschlüsselung handelt, geht daraus leider nicht hervor.

Let’s Encrypt unter Ubuntu und Nginx einrichten

Vor einigen Tagen habe ich damit begonnen alle von mir betriebenen Webseiten auf TLS umzustellen. Dabei nutzte ich Zertifikate der Zertifizierungsstelle Let’s Encrypt. Let’s Encrypt ging dabei im letzten Jahr in Betrieb und liefert kostenlose Zertifikate für TLS. Die CA wird dabei unter anderem von der EFF und Mozilla unterstützt. Im Gegensatz zu anderen Lösungen ist der Prozess bei Let’s Encrypt hochgradig automatisiert, so das die Einrichtung schnell von statten geht.

Der offizielle Client hört dabei auf den Namen Certbot (früher Let’s Encrypt Client) und implementiert das ACME-Protokoll (Automated Certificate Management Environment) über welches der Prozess abgewickelt wird. Neben dem offiziellen Client gibt es viele weitere Clients welche das ACME-Protokoll implementieren. Um Let’s Encrypt unter Ubuntu zu nutzen, muss im ersten Schritt der Client installiert werden:

apt-get install letsencrypt

Nachdem der Client installiert wurde, kann mit der Erzeugung der Zertifikate begonnen werden. Im Gegensatz zu Apache wird unter Nginx die automatische Einrichtung nicht unterstützt. Aus diesem Grund werden nur die Zertifikate mit dem Client erzeugt. Dies geschieht mit dem Befehl:

letsencrypt certonly

Damit wird der interaktive Modus gestartet in welchem das Zertifikat erzeugt werden kann. Zuerst wird nach einer Mailadresse gefragt, mit welcher das Recovery in Notfällen möglich ist. Anschließend müssen die allgemeinen Geschäftsbedingungen akzeptiert werden. Nun wird nach den Domains gefragt, für welche ein Zertifikat erstellt werden soll. Hier kann man mehrere Domains per Komma bzw. Leerzeichen getrennt angeben – allerdings scheint dies in der aktuellen Version nicht zu funktionieren. Stattdessen wird nur für die erste angegebene Domain ein Zertifikat erzeugt. Standardmäßig benötigt Certbot während der Generierung der Zertifikate Zugriff auf den Port 80. Hintergrund für dieses Verhalten ist das der Client kurz einen Webserver aufsetzt um die Kommunikation mit der CA durchzuführen.

Abgelegt werden die erzeugten Zertifikate dabei im Ordner /etc/letsencrypt/. In diesem Ordner liegen neben den Stammzertifikaten auch die eigentlichen Zertifikate für die einzelnen Domains. Nun kann dieses Zertifikat in Nginx eingebunden werden. Dazu muss die Konfigurationsdatei der jeweiligen Seite (z.B. /etc/nginx/sites-available/example) geöffnet werden. Im ersten Schritt wurde dazu in der Konfiguration eine Weiterleitung eingerichtet:

server {
        listen 80;
        listen [::]:80;

        server_name .example.org;

        return 301 https://$host$request_uri$is_args$args;
}

Diese Weiterleitung sorgt dafür das eine Verbindung über unverschlüsseltes HTTP automatisch auf die verschlüsselte Variante umgeleitet wird. Weiter geht es mit der Konfiguration der verschlüsselten Verbindung:

server {
        listen   443 ssl;
        listen [::]:443 ssl;

        ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/example.org/privkey.pem;

        ...

Jedes erzeugte Zertifikat von Let’s Encrypt ist 90 Tage lang gültig, so das ein automatischer Prozess eingerichtet werden sollte um die Zertifikate automatisch zu erneuern. Mit dem Befehl:

letsencrypt renew --agree-tos

kann dabei der Erneuerungsprozess angestoßen werden. Möchte man das ganze ohne Risiko testen, so sollte der Parameter –dry-run angefügt werden.

letsencrypt renew --agree-tos --dry-run

Bei der Erneuerung der Zertifikate kann es nun vorkommen das man den Nginx-Server vorher beenden muss. Das ganze kann man in ein Skript gießen:

#!/bin/sh
service nginx stop
letsencrypt renew --agree-tos
service nginx start

Dieses Skript kann man nun zum Beispiel einmal in der Nacht per Cronjob ausführen. Der Client überprüft dabei ob eine Erneuerung notwendig ist und führt diese dann automatisch durch.

Certificate pinning im Browser

Beim sogenannten Certificate pinning werden Zertifikate, welche für die Verschlüsselung von Webseiten und anderen Diensten genutzt werden, lokal gespeichert. Dies hat den Vorteil, das dass Zertifikat nicht einfach unbemerkt durch ein anderes Zertifikat ausgetauscht werden kann und erschwert damit das abhören von SSL/TLS-Verbindungen.

Certificate Patrol
Preis: Kostenlos

Leider ist diese Funktionalität in den gängigen Browsern nicht vorhanden. Mit dem Firefox-AddOn Certificate Patrol kann man ein solches Certificate pinning im Browser nachrüsten. Zertifikate müssen dabei einmalig akzeptiert werden – anschließend wird man informiert, wenn sich das Zertifikat ändert. Damit ist es für einen Angreifer wesentlich schwieriger geworden, dem Nutzer falsche Zertifikate unterzuschieben.

Selbstsigniertes Zertifikat erstellen und bei Nginx einbinden

Für verschlüsselte HTTP Verbindungen benötigt man ein Zertifikat. Dieses kann man sich von einer Zertifizierungsstelle (Certificate Authority, CA) ausstellen lassen. Der Haken an der Sache ist das dies Geld kostet (CACert und StartCom mal außen vor gelassen). Eine Alternative hierzu wäre es das Zertifikat selbst zu erstellen. Bei Diensten die man nur für einen kleinen Nutzerkreis z.B. für die Familie hostet, ist es auch vertretbar die Zertifikatswarnung im Browser über sich ergehen zu lassen. Für die Zertifikate wird ein Ordner erstellt und in diesen gewechselt:

mkdir /etc/nginx/ssl
cd /etc/nginx/ssl

Nun werden das Zertifikat und der Certificate Signing Request erstellt:

openssl genrsa -out example.key 2048
openssl req -new -key example.key -out example.csr

Bei der Erstellung des Certificate Signing Request müssen einige Daten angegeben werden:

Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Mecklenburg-Vorpommern
Locality Name (eg, city) []:Neubrandenburg 
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example Inc
Organizational Unit Name (eg, section) []:Skunk works
Common Name (e.g. server FQDN or YOUR name) []:example.org
Email Address []:webmaster@example.org

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Nun muss das Zertifikat noch signiert werden, bevor wir es verwenden können:

openssl x509 -req -days 730 -in example.csr -signkey example.key -out example.crt

In diesem Fall ist das Zertifikat 730 Tage, also zwei Jahre gültig. Da die Signierung nun abgeschlossen ist, kann das Zertifikat in Nginx eingebunden werden. Dazu öffnen wir die Datei “/etc/nginx/sites-available/example”, wobei “example” hier natürlich für die entsprechende Konfigurationsdatei steht. Dort sollte die SSL Konfiguration vorgenommen werden:

server {
        listen 443 ssl;

        root /var/www/example/root;
        index index.html index.htm;
 
        server_name .example.org;

        ssl_certificate /etc/nginx/ssl/example.crt;
        ssl_certificate_key /etc/nginx/ssl/example.key;
}

Nach dem Aktualisieren der Konfiguration mittels:

service nginx restart

ist die verschlüsselte Verbindung für die eingerichtete Seite aktiv und kann genutzt werden.

Weitere Informationen gibt es unter:
http://nginx.org/en/docs/http/configuring_https_servers.html

Outbank wieder benutzbar

Vor einigen Tagen kam die Version 2.0 der Anwendung Outbank heraus. Dabei handelt es sich um eine Banking Software für Mac OS X und iOS. Allerdings hatte sich in die Version ein schwerer Fehler eingeschlichen. So wurde das Passwort welches zu lokalen Verschlüsselung der Daten benutzt wird, im Klartext in die “system.log” geschrieben, was dann im Beispiel so aussieht:

Jan 17 09:17:03 delphi.localdomain OutBank[537]: Open Store:Core Data key:123456->abcdefghijklmnopqrstuvwxyzABCDEF

Neben diesem Problemen hatte die erste Version dank iCloud Synchronisierung auch mit Problemen wie doppelten Umsätzen und ähnlichem zu kämpfen. Problematisch an dem Fehler im Log ist auch das Mac OS X von Zeit zu Zeit das ganze archiviert und es so dazu kommen kann, das dieses Passwort an mehreren Stellen zu finden ist. Das gleiche trifft auch auf die Kombination mit Backupsystemen wie Time Machine zu. Um nach dem Update auf Outbank die entsprechenden Logeinträge zu entfernen wird von “stoeger it” folgende Zeile empfohlen welche man im Terminal ausführen sollte:

sudo -i -- 'cd /var/log && grep -vE "OutBank\[" system.log > system.log.clean && mv system.log.clean system.log && if [[ -f system.log.0.bz2 ]]; then for a in system.log.*.bz2; do bunzip2 $a && grep -vE "OutBank\[" ${a%.*} > ${a%.*}.clean && mv ${a%.*}.clean ${a%.*} && bzip2 ${a%.*} ; done; fi; rm -f /var/log/asl/*.asl'

Witzig sind in diesem Zusammenhang Aussagen von Tobias Stöger aus der Zeitschrift SFT (Spiele | Filme | Technik) wo er auf die Frage ob Outbank sicher ist unter anderem wie folgt antwortet:

Der Artikel bezog sich mal wieder auf das unsichere Android-OS. […] Hinzu kommen noch unsere Sicherheitsmaßnahmen, wie automatische Passwortsperre oder verschlüsselte Datenbank.

Das war dann wohl ein Fall von pauschaler Aussage zum falschen Zeitpunkt. Natürlich stellt sich die Frage warum (wenn auch nur für Debugzwecke) Passwörter überhaupt im Klartext gespeichert werden. Auch war keine Auskunft zu erhalten ob die neue Version von Outbank die Bereinigung der Dateien selber vornimmt. Zur Sicherheit sollte man dies also auf alle Fälle manuell nachholen und anschließend das entsprechende Passwort ändern.

Weitere Informationen gibt es unter:
http://www.outbank.de/outbank-os-x-mac-sicherheitshinweis-zu-version-2-0-0/
http://www.heise.de/mac-and-i/meldung/Outbank-2-mit-Passwort-Leck-1786837.html