TextSecure bald ohne SMS/MMS Verschlüsselung

Mit Version 2.6.0 erscheint die letzte TextSecure Version, welche noch das verschlüsseln von SMS/MMS erlaubt. Ab Version 2.7.0 fällt diese Option weg, alle Nachrichten werden dann ausschließlich als “TextSecure-Nachrichten” über TextSecure-Server geschickt (Vgl. Blogpost). Die Fähigkeit unverschlüsselte SMS/MMS zu versenden und TextSecure damit als standard Nachrichtenapp zu nutzen soll erhalten bleiben.

Als Gründe für diesen Schritt werden unter anderem die fehlenden Möglichkeiten SMS/MMS Verschlüsselung auf dem IPhone umzusetzen, Usabilityprobleme, welche mit der Verschlüsselung von SMS/MMS einhergingen sowie die bei SMS/MMS Versandt anfallenden Metadaten angeführt.

Auch von Googles Cloud Messaging (GCM) soll sich TextSecure zumindest teilweise lösen. Anscheinend gab es mit GCM Probleme beim zustellen von Nachrichten. In Zukunft wird Googles Dienst wohl nur noch für die Benachrichtigung darüber, dass es neue Nachrichten gibt genutzt werden. Eventuell wird aufgrund dieser Entwicklung auch weiter an alternativen Lösungen, ohne Google gearbeitet.

Signal 2.0 – mit private messaging

Open Whispersystems haben die Signal 2.0 App für IOS veröffentlicht. Damit ist die Signal App nicht mehr nur mit RedPhone, welches ende-zu-ende verschlüsselte Telefonie unter Android erlaubt kompatibel, sondern auch mit dem TextSecure Messenger. Die Verschlüsselung von TextSecure gilt als fortschrittlich und wurde unter anderem von Edward Snowden empfohlen.
Zudem ist die App kostenlos und hat eine schicke und unkomplizierte Oberfläche, bleibt zu hoffen, dass sich die Verbreitung, nachdem sie jetzt für die beiden wichtigsten mobil Plattformen verfügbar ist, erhöht.

[Update 03.03.15] Mit “TextSecure-Browser” ist übrigens noch ein Browser Plugin in der Entwicklung, mit welchem TextSecure in Zukunft auch bequem vom Desktop Rechner aus genutzt werden kann.

Außerdem hatte ich vergessen zu erwähnen, Signal ist unter der GPL3 lizensiert, der Quellcode ist auf Github verfügbar.

TextSecure – Account löschen

Es kommt hin und wieder vor, das Menschen nicht mehr auf dem TextSecure Server(n) registriert sein möchten, weil die App deinstalliert wurde oder die (offline) SMS-Verschlüsselung genutzt werden soll.

Ist die App deinstalliert, aber die Nummer noch auf dem Sever registriert, führt dies dazu, das Nachrichten von anderen TextSecure Nutzer_innen, die “TextSecure-Nachrichten” nutzen, auf dem TextSecure Server landen und nicht mehr zur / zum jeweiligen Adressat_in gesendet werden können, weil die App sie nicht mehr abruft.

Wird TextSecure nicht deinstalliert, besteht nach der Deregistrierung (zumindest im Moment noch) die Möglichkeit wieder über verschlüsselte SMS zu kommunizieren.

Am einfachsten gelingt die Löschung der eigenen Nummer indem die Option “TextSecure-Nachrichten” unter “Einstellungen“, durch entfernen des Hakens, deaktiviert wird.

Ist die App schon deinstalliert kann die Seite “Unregister from TextSecure” genutzt werden. Hier kann die Nummer per SMS oder Anruf vom TextSecure Server gelöscht werden.

Hinweis: ChatSecure – Jabber/XMPP Client für Android mit Dateiversand

Glückwunsch an die Entwickler_innen vom Guardian Project, sie haben mit ChatSecure den ersten mir bekannten XMPP/Jabber Client für Android unter einer Open Source Lizenz herausgebracht, der Datei/Fotoversand unterstützt.

Tatsächlich war es das Fehlen der letzteren Funktion, was viele Whatsapp Nutzer_innen, welche ich von den Vorzügen selbstinstallierter XMPP Server (bzw. ‘vertrauenwürdigen’, dezentralen, …) und OTR Verschlüsselung überzeugen wollte, davon abhielt, auch nur eine XMPP Client App auf ihrem Android Gerät zu installieren.

ChatSecure kann selbstverständlich noch einiges mehr, als nur Dateien zu versenden, neben OTR Verschlüsselung, einer einfachen Möglichkeit sich über Orbot/einen Proxy zu verbinden, Verschlüsselung der lokalen Daten, unterstützt die App auch Gruppen Chats und hat noch einige weitere schicke Featues.

Die App gibt es bereits im PlayStore und als apk auf der Homepage des Projektes, und im F-Droid Repository.

Hinweis: Deaktiviert Javascript im TorBrowserBundle!

Berichten zufolge wurde nicht nur der Betreiber von Tor Freedom Hosting festgenommen, welcher große Teile der Tor hidden services hostete (u.a. wohl TorMail) und eine große Anzahl von hidden services ist nicht mehr erreichbar, sondern es wurden angeblich  seit einigen Tagen (?) auch Javascript Angriffe auf das TorBrowserBundle auf diversen Tor hidden services installiert.
Die Angriffe gehen wohl vom FBI aus, welches es auf die Vertriebsstrukturen von Kinderpornografie abgesehen hat, dies ist laut Heise.de zumindest der Grund für die Festnahme von Eric Eoin Marques.

Die Entscheidung der Tor Entwickler_innen Javascript im TorBrowserBundle standardmäßig zu aktivieren fällt ihnen offenbar gerade auf die Füße. Auch wenn die Intention durch leichtere Handhabung mehr Nutzer_innen für das BrowserBundle zu gewinnen sicherlich auch nicht ganz unsinnig war.

Betroffen sind laut ersten Analysen nur Windows Nutzer_innen, Ziel des Angriffs ist scheinbar die Aufhebung der Anonymität von TorBrowserBundle Nutzer_innen mittels eines Cookies (Vgl. http://www.twitlonger.com/show/n_1rlo0uu , http://pastebin.mozilla.org/2777139 )

Insofern NoScript im BrowserBundle installiert ist, kann Javascript leicht seitenabhängig kontrolliert werden (Youtube Tutorial). Die wichtigste Einstellung sollte zunächst sein Scripte allgemein zu verbieten! Danach kann Javascript auf ‘vertrauenswürdigen’ Seiten wieder aktiviert werden.

Momentan scheinen wie gesagt nur Tor hidden services die zum Vertrieb von Kinderpornos genutzt wurden betroffen zu sein, was durchaus auch sein positives hat, allerdings zeigt der Angriff die generelle Angreifbarkeit der Anonymität im Tor Netzwerk. Dies zeigt insbesondere nach Snowdens Enthüllungen, dass es um Techniken der Überwachung zu trotzen schlecht steht.

Update [05.08.13] Auf dem Blog des TorProject gab es eine weitere Stellungnahme zu der Attacke, dabei wurde klargestellt, dass die aktuellen TorBrowserBundles nicht von der ausgenutzen Sicherheitslücke betroffen sind (Vgl. security announcement).

Die Owncloud 5 Encryption App

Die Ankündigung von Frank Karlitscheck auf der Owncloud Announcement Maillinglist, dass die neue Encryption App in Owncloud 5 fertig für den produktiven Einsatz ist, habe ich zum Anlass genommen die App auszuprobieren.
Wie gewohnt kann Encryption App (0.4) von Administrator_innen unter Apps aktiviert werden. Danach werden die Daten der Nutzer_innen beim nächsten Einloggen mit deren Log-in Passwort (AES-128) verschlüsselt (werden die Daten mit anderen Nutzer_innen oder über einen Link geteilt haben diese selbstverständlich auch Zugriff, das funktioniert mit entsprechend verschlüsselten file-keys, welche für jede Datei erstellt werden) , d.h. es sollte Wert auf vernünftige Passwörter gelegt werden.
Die Dateien sind dann einzeln verschlüsselt, die Dateinamen bleiben unverschlüsselt. Der Zugriff mit SyncClient und Android App waren kein Problem.
Wichtig zu wissen ist, dass es sich (wie in diesem Artikel beschrieben) um eine serverseitige Verschlüsselung handelt, d.h. die Serveradministrator_innen bzw. Personen die die Kontrolle über den Server haben, können potenziell auf die unverschlüsselten Daten zugreifen, was den Nutzen der Encryption App doch etwas fragwürdig erscheinen lässt. Zumindest scheint die Verschlüsselung des private Key mit den Passwörtern der Nutzer_innen einen gewissen Schutz im Falle von Datendiebstahl zu bieten, allerdings bin ich auch kein_e Verschlüssselungsexpert_in. Ansonsten wird im oben genannten Artikel darauf verwiesen, dass die Verschlüsselung bei der Nutzung der ‘external storage app’ einen Schutz für die Daten bietet, welche damit beispielsweise bei Dropbox hochgeladen werden. Außerdem wird auf die Möglichkeit verwiesen in die Verschlüsselungsarchitektur zu einem späteren Zeitpunkt auch clientseitige Verschlüsselung zu integrieren, bleibt zu hoffen, dass dies tatsächlich irgendwann passiert.
Auf jeden Fall ist es gut zu sehen, das die Verschlüsselung in Owncloud 5 Fortschritte macht!

Android – verschlüsselt telefonieren mit RedPhone

Nachdem Twitter im Januar diesen Jahres “TextSecure“, eine Software die es erlaubt SMS zu verschlüsseln, unter einer GPL Lizenz veröffentlicht hat, folgt jetzt der Quellcode der Software “RedPhone“, welche verschlüsselte VoIP Telefonate zwischen Android Telefonen erlaubt. Beide Programme wurden ursprünglich von der Firma Whisper Systems entwickelt,welche von Twitter aufgekauft wurde.

RedPhone verschlüsselt die Telefonate mit SRTP. Die Daten laufen verschlüsselt über RedPhone Server, welche auch für die Initiierung von Telefonaten notwendig sind. Da es sich um VoIP handelt ist eine Datenverbindung notwendig, was aber mittlerweile nur noch wenige Nutzer_innen abschrecken sollte. Nähere Informationen zur Architektur und Verschlüsselung gibt es im Github Wiki des Projekts.

Kurzinfo: Owncloud 4 released

Nach vier monatiger Entwicklungszeit ist Owncloud 4 fertig. Es gibt zahlreiche Verbesserungen gegenüber der Vorgängerversion. Sicherlich sind die Möglichkeit die eigenen Dateien zu verschlüsseln und die Versionierung zwei der wichtigsten Neuerungen, jedoch bei weitem nicht die einzigen. Mehr Infos zum Release gibt es auf blog.karlitschek.de.

GnuPG-Verschlüsselung mit Nautilus funktioniert wieder

Die GnuPG-Plugins für Nautilus und Gedit (seahorse-plugins) sind mit Ubuntu 11.10 aus den Paketquellen verschwunden. (siehe dieser Artikel). Jetzt gibt es mit Ubuntu 12.04 zumindest wieder ein GnuPG-Plugin für Nautilus. Das zu installierende Paket heißt

seahorse-nautilus

Nach der Installation muss Nautilus neu gestartet werden, das erledigt der Befehl

nautilus -q

im Terminal, alternativ hilft auch ab- und wieder anmelden.

Danach sollten bei einem Rechtsklick auf eine Datei oder einen Ordner die Optionen “Verschlüsseln …” und “Signieren” vorhanden sein.

crypto.cat – die Verschlüsselung sicher tanzen

Über crypto.cat – eine WebApp für verschlüsselte (Gruppen-)Chats – habe ich bereits vor einiger Zeit berichtet. Heute habe ich gelesen, dass sich Entwickler_innen auf dem Wall Street Journal Data Transparency Hackathon eine nette Funktion für die in Entwicklung befindliche craypto.cat Android App CryptocatBot ausgedacht haben. Die Zufallszahlen welche crypto.cat für die Verschlüsselung benötigt (für jede Sitzung werden neue Keys erstellt) werden hier nicht (wie bei der WebApp) durch möglichst wahlloses tippen auf der Tastatur erzeugt sondern durch tanzen / Bewegung.

Das ist meiner Meinung nach mal eine echt schicke und sinnvolle Einsatzmöglichkeit für die in (so gut wie?) allen Smartphones vorhandenen Bewegungssensoren.

Anmerkung: Im letzten Artikel über crypto.cat war ich nicht auf die Lizenz eingegangen unter welcher der Quellcode steht, das möchte ich bei dieser Gelegenheit nachholen. Crypto.cat ist unter der AGPL3 lizensiert (vorher war es eine CC BY-NC-SA 3.0), der Quellcode ist auf Github verfügbar.