Keybase.io

Mit Keybase.io ist eine neue Idee in die Welt der Kryptographie getreten, die ich ganz spannend finde. Um zu erklären warum, muss ich allerdings etwas ausholen:

In der sogenannten PublicKey (oder asymetrischen)-Kryptographie (die wohl populärste Form der Verschlüsselung) wird mit speziellen mathematischen Verfahren ein Schlüsselpaar erstellt. Einen Schlüssel behält man für sich, einen macht man öffentlich. Wenn ich jemandem eine verschlüsselte Nachricht schicken will, nehme ich dessen öffentlichen Schlüssel, um die Nachricht zu verschlüsseln. Nur mit dem privaten Schlüssel kann derjenige dann die Nachricht wieder entschlüsseln. Dieses Verfahren gilt in den meisten Varianten sogar in Zeiten der NSA-GCHQ-Enthüllungen noch als relativ sicher und wird auch von Edward Snowden empfohlen.

Bei der PublicKey-Verschlüsselung gibt es aber nach wie vor ein Problem, das noch nicht befriedigend gelöst wurde. Wie kann ich sicher stellen, dass der PublicKey, den ich verwende, wirklich auch zu der Person gehört, der ich die Nachricht schicken will? Es kann ja durchaus sein, dass mir jemand einen falschen Key gegeben oder irgendwie untergejubelt hat. Derjenige könnte sich dann zwischen mich und meinen Gesprächspartner begeben und unsere Kommunikation abhören, oder gar faken. Die so genannte Man-In-The-Middle-Attack.

Für dieses Problem gibt es bislang, – sagen wir – zweieinhalb Lösungen:

  1. Zertifikate. Eine Institution, der aus irgendwelchen Gründen getraut werden kann, überprüft einmal meine Identität und zertifiziert meinen Public Key. Das Zertifikat kann dann von anderen zusammen mit meinem PublicKey heruntergeladen werden und bestätigt meinem Gegenüber, dass die zertifizierende Stelle der Meinung ist, dass mein Key zu mir (z.B. meiner E-Mailadresse) gehört. Dieses Verfahren wird beispielsweise bei TLS/SSL und für E-Mailverschlüsselung mit S/MIME verwendet. Problem: wieso sollte ich der zertifizierenden Instanz trauen? Und selbst wenn ich das täte, befindet sich auf deren Servern ein großer sicherheitsrelevanter Schatz, der Begehrlichkeiten bei Hackern und Geheimdiensten weckt und deswegen leicht mal komprommitiert werden kann. (Dass das nicht nur ein theoretisches Problem ist, zeigt der Fall DigiNotar) Hinzu kommt, dass man wegen des zentralisierten Identifizierungs-Aufwandes fast nirgends solche Zertifikate umsonst bekommt.

  2. Web of Trust. KeyServer sind spezielle Server, die die PublicKeys mit der Verknüpfung zur E-Mailadresse hosten, die auch untereinander Daten austauschen und von überall her verfügbar sind. Dort kann erstmal jeder alles eintragen, allerdings gibt es das Feature, dass andere Nutzer, die bereits glauben, dass ich ich bin, meine Identität mit ihrem Key „signieren“ können. Wenn ich mir also unsicher bin, ob eine Identität echt ist, kann ich dort auch nachgucken, wer den Key signiert hat. Und wenn ich mir auch bei den Signierern unsicher bin, kann ich nachgucken, wer wiederum deren Key signiert hat und so weiter. Das Web of Trust kann sehr tief sein. Irgendwann, so die Theorie, stoße ich auf genug Namen und Signaturen, denen ich vertraue. Das Verfahren wird zum Beispiel bei PGP/GPG angewendet. Problem: funktioniert nur bei Leuten, die schon viele Kontakte im Hackerumfeld haben. Außerdem ist das Nachvollziehen der Vertraubarkeit eines Keys, wenn man es denn ernst nimmt, wirklich sehr aufwändig und je weniger Leute man kennt, desto aufwändiger ist es. Für Neueinsteiger somit eigentlich unmöglich. In der Praxis dürften sich die meisten (auch die Kryptonerds) mit ein paar wenigen, ihnen unbekannten und ungeprüften Signaturen zufrieden geben, was dann aber ebenfalls wenig sicher ist.

  3. Hosting/Kryptopartys Dieser Punkt gilt nur so halb, weil er eher Ergänzungen enthält: Man kann seinen Key natürlich auch (ergänzend zum Keyserver) auf seinem eigenen Webserver hosten, was ein gewisser Identitätsnachweis ist, denn nicht jeder hat ja Schreibzugriff auf meinem Server. Problem: So ein Webserver lässt sich aber schnell mal hacken. Echte Kryptonerds würden dem Key also nicht sehr weit trauen. Aber als Ergänzung ist das schon mal nicht schlecht. Dann gibt es Krypto- oder Keysigning-Partys. Da kommen dann meistens ein paar Nerds aus der Umgebung zusammen und dann wird sich gegenseitig der Ausweis gezeigt und der Key ausgetauscht und gegenseitig signiert. Problem: Der sicherheitsrelevante Mehrwert, dass Random-Nerd X, bestätigt, dass Random-Nerd Y einen Ausweis hat, in dem ein Name steht, der mit einem Datenbankeintrag auf einem Keyserver identisch ist, erschließt sich mir nicht wirklich.

Das Problem also ist, dass keines der oben genannten Verfahren wirklich gut ist. Es ist vermutlich bei genügend Aufwand (zeitlich, geldlich und sozial), gut genug für die Kryptonerds. Aber keines der Verfahren ist einerseits einfach und gleichzeitig sicher, um für normale Menschen nutzbar zu sein. Vermutlich liegt das in der Natur der Sache. Denn am Ende führt das Trustproblem zu der entscheidenden, eigentlich philosophischen Frage: Was ist Identität? Und wer kann sie wie garantieren? Sind wir vielleicht alle nur die Wahnvorstellungen in den Träumen eines höheren … ach, lassen wir das.

Bisher wurde Identität gerne über den Staat garantiert. Der stellt uns unseren Ausweis aus, der per Lichtbild und über ein paar physiognomischen Merkmale mit unserem physischen Körper verknüpft ist. Diese Vorstellung, dass Identität vor allem ein Link zwischen E-Mail und Wetware sei, spiegelt sich auch in der Idee der Keysigningpartys wieder. Ausweis – Gesicht – E-Mail – Key. So einfach ist das!

Ich finde das antiquiert. Entgegen der geheimen Hoffnung einiger Nerds interessieren sich die meisten Leute da draußen nämlich gar nicht für ihren Körper. Leute, die mir schreiben, wollen ihre verschlüsselte Mail nicht an den Fleischklumpen mit Bluthochdruck und Bad-Hair-Day vor meinem Computer schicken, sondern an die netzkulturelle Verschaltungseinheit, die neulich den lustigen Tweet über die NSA abgelassen hat, oder den Text über Tinder. Kurz: sie wollen gar nicht mit Michael Seemann sprechen, sondern mit mspro.

Eine zeitgemäße Antwort auf das Trustproblem muss also die Frage beantworten: Wie kann ich meinen PublicKey glaubhaft an meine Onlineidentität knüpfen (die längst viel mehr als eine E-Mailadresse ist)?

Und hier gibt Keybase.io eine wie ich finde überzeugende Antwort. Ich gebe dem Dienst meinen Twitteraccount-Namen, darauf generiert er mithilfe meines PrivateKeys einen Tweet. Den Tweet kann ich dann Twittern und Keybase zur Verifikation auffordern. Keybase schaut in meinem TwitterAccount nach, findet den Tweet und sieht somit als bewiesen an, dass ich tatsächlich Zugriff auf den entsprechenden Twitteraccount habe. Damit ist mein PublicKey mit meinem Twitteraccount verknüpft. Wenn jetzt also jemand nicht Michael Seemann, sondern „dem Typen, der sich auf Twitter mspro nennt“ eine verschlüsselte Nachricht senden will, kann er dazu auf Keybase.io nachschauen, wie sein Key ist.

Der Dienst befindet sich in der Alpha-Phase, man kommt derzeit nur mit Invite rein (hab grade keine mehr), aber er sorgt nichtsdestotrotz bereits für einige Diskussionen in der Szene. Ich will deswegen kurz auf ein paar Kritikpunkte eingehen.

Erste Kritik: Man kann dort seinen PrivateKey hochladen!!11einself

Keybase.io will mehr sein, als nur eine Erweiterung des Keyserverkonzeptes, sondern auch ein benutzbarer Krypto-Client im Web. Deswegen kann man all die Sachen, die man so mit Kryptographie machen kann, auch direkt auf der Website tun. Vorausgesetzt, man lädt nicht nur seinen PublicKey, sondern auch seinen PrivateKey hoch. Vielen Sicherheitsexperten geht alleine bei der Vorstellung die Hutschnur. Der PrivateKey habe gefälligst auf dem eigenen Rechner zu verbleiben, alles andere gefährde die Sicherheit.

Das ist zwar richtig, aber ich habe drei Punkte anzumerken:

  1. Man muss den PrivateKey nicht hochladen, um den Dienst zu nutzen. Das ist nur eine Option. Man kann sich auch einen Client direkt auf dem eigenen Rechner installieren, so dass der PrivateKey lokal verbeibt. Der Client funktioniert auf Node.js-Basis und über Kommandozeile. Ich finde ihn sehr brauchbar, weswegen ich keine Veranlassung gesehen habe, meinen PrivateKey hoch zu laden. Von den 23 Kontakten, die ich bereits auf Keybase.io habe, ist mir keiner bekannt, der seinen PrivateKey hochgeladen hat. Warum auch?

  2. Der PrivateKey wird wiederum verschlüsselt hochgeladen und abgelegt. Selbst, wenn der Server gehackt wird, kommt der PrivateKey nicht abhanden. Zugriff hat also nur Keybase selbst. Und Keybase kann mit dem Key auch nicht so viel anfangen, so lange sie nicht im Besitz der Passphrase sind. Natürlich geht man dennoch ein unverhältnismäßiges Risiko ein, wenn man den Key hochlädt, insbesondere da der Dienst noch in der alpha ist. Ich würde also niemanden raten, das zu tun, wenn es nicht umbedingt nötig ist.

  3. Bei der Einschätzung wie sinnvoll es ist, eine solche Option überhaupt anzubieten, fände ich ein bisschen mehr Zurückhaltung wünschenswert. Wenn man sich die Zahlen anschaut, wie wenig Leute Krypto nutzen, finde ich es erstmal nachvollziehbar, dass keybase.io mit einem Webclient (man bedenke, dass weit über 60% der Leute ihre Mails im Browser nutzen (hab ich irgendwo gelesen finde die Quelle nicht wieder)), diesen Kreis vergrößern will. Und ob es den Kryptonerds passt oder nicht: Ein Newbie, der Krypto mit hochgeladenem Key nutzt, hat einen Sicherheitsgewinn gegenüber seinem vorherigen Ich, der kein Krypto nutzt.

Zweite Kritik: So einen Twitteraccount kann man doch auch hacken!!

Das ist richtig. Aber es ist ja nicht die einzige Schnittstelle, die Keybase.io anbietet. Man kann ebenfalls seinen Github-Account, sowie seine Websites dort approofen. Ich habe zwei Websites, Twitter und Github. Es kann sein, dass jemand meine Website knackt, es kann sein, dass jemand beide Websites knackt. Aber beide Websites, meinen Twitter- und meinen Github-Account? Das ist schon ziemlich unwahrscheinlich. Auch: es werden mit Sicherheit mehr und mehr Dienste nachgeschoben und mit jedem hinzukommenden Dienst, wird es schwieriger werden, Identitäten zu fälschen.

Und selbst wenn das jemand schaffen würde und könnte meinen Key austauschen; Ich habe 23 Tracker bei Keybase.io, die allesamt darüber informiert würden, wenn sich mein PublicKey ändert. (Ich bin mir gerade nicht sicher, ob das Tracken nicht auch ein Keysigning mit einschließt. Wenn nicht, würde mich interessieren, warum nicht.)

Dritte Kritik: Der momentane lokale Keybase.io-Client basiert teils [auf unsignierten Node.js-Paketen].16

Ja, genau genommen ist damit eine Unsicherheit in der Vertrauens-Kette, die am besten vom Chip bis zur Applikation gehen sollte, drin. Sagen wir so: ich bin Mac-Nutzer und damit ist es in in den Augen vieler Kryptonerds fast egal, mit welcher Software ich was verschlüssele, weil meinem Betriebssystem, da es nicht Open Source ist, eh nicht zu trauen ist. Kann man dann ja auch gleich sein lassen. Lass ich aber nicht, denn ich denke, dass ich mit Krypto alle mal ein Mehr an Sicherheit erreiche, als ohne. Im übrigen halte ich das Sicherheitsversprechen durch Open Source zumindest zum Teil für übertrieben, wenn ich mir angucke wie oft immer wieder jahrelange Backdoors und eklatante Sicherheitslücken in Open Source Software gefunden werden. (allein in den letzten Wochen mit GOTOFAIL (ja, Apple, ja trotzdem, Open Source) und HEARTBLEED)

Hinzu kommt, dass wir es bei keybase.io nun mal immer noch mit einer Alpha zu tun haben. Ich hoffe sehr, dass zukünftige Clients gar nicht mehr auf Node.js basieren werden, sondern nativ laufen. Aber mal sehen.

Vierte Kritik: Die halten sich nicht an Keyserverstandards und überhaupt ist das dezentrale, offene Keyserverkonzept eh viel besser.

Keybase.io hat jedenfalls eine API, über die man ebenfalls sehr offen mit dem Server sprechen kann. Ich sehe kein Hindernis, Keybase.io nicht so weit es eben geht, mit Keyservern sprechen zu lassen, sofern das sinnvoll ist. Ich sehe auch keine Hürde, die Daten irgendwo zu spiegeln und falls sie den Code open sourcen (was ich für unwahrscheinlich halte, aber nicht ausschließen würde), vielleicht eine eigene Instanz aufzusetzen.

Zudem heißt eine Nutzung von Keybase eben nicht, dass man seinen Key von den Keyservern revoken soll. Es ist eben ein zusätzlicher Kanal, so wie das selber Hosten. Ich finde da nichts schlimmes dran, das mal auszuprobieren.

Fazit: Auch wenn Keybase.io lange nicht fehlerfrei und ohne Makel ist, finde ich, dass es genau den richtigen Ansatz forciert. Identität wird heute in erster Linie mit OnlineProfilen hergestellt, nicht durch Gesicht und Ausweis. Keybase.io schließt diese Lücke. Und so lange man nur seinen PublicKey dort ablegt, geht davon auch keine Gefahr aus und man kann ein bisschen rumspielen.

Ich finde die Kritik an keybase übertrieben, würde mir aber wünschen, dass sie vorsichtiger auftreten. Wenn man einen Kryptodienst in der Alpha fährt, sollte man überall Warnschilder anbringen, dass man das nicht für relevantes verwenden sollte. Insbesondere dann, wenn es um echte PrivateKeys geht. Vielleicht wäre es auch strategisch sinnvoller, die Webclientgeschichte erstmal ganz wegzulassen, damit die Kryptonerds den Dienst nicht wegen der Option kaputt reden. Newbies wird der Dienst in der Alphaphase eh nicht anziehen. Und wenn man erstmal Traktion hat und die Sicherheit einigermaßen hinkommt, kann man das ja immer noch wieder einführen.

Interessant ist der Dienst auch aus Post-Privacy-Aspekten heraus. Wenn ich meinen PublicKey mit meinen Onlineidentitäten verknüpfe, kommt es plötzlich auf die in den Online-Identitäten abrufbaren Daten an, wie gut mich diese identifizieren.

Mein Github-Account ist leer (ich hab schon sehr lange nichts vorzeigbares mehr programmiert). Im Grunde könnte ich ihn weglassen, denn niemand kennt mich über meinen Aktivitäten auf Github. Mein Twitteraccount hingegen hat mein Leben der letzten sieben Jahre gespeichert und ist damit ziemlich „identitätsschwer“.

Am Ende sind Identitäten nichts weiter als Anknüpfungspunkte. Je mehr Daten über mich an eine Onlineidentität gebunden sind, desto mehr Kommunikationsanlässe gibt es und desto mehr „Identität“ strahlt ein Profil aus. Post-Privacy – im Sinne von: viele Daten über mich zugänglich machen – schafft so ein Mehr an Kryptosicherheit. Wer hätte das gedacht? 😉


Warum man bei Tinder nicht anonym ist

Disclosure: Beim schreiben des Artikels wurde mir etwas unwohl. Gebe ich vielleicht potentiellen Stalkern noch nützliche Tipps, um Menschen zu terrorisieren? Auch wenn das nicht auszuschließen ist, glaube ich, dass der Aufklärungsaspekt wichtiger ist. Die Dinge, die ich hier erzähle sind keine Rocket Science, Menschen mit der kriminellen Energie werden diese Tricks mit Sicherheit auch drauf haben. Davon sollte man jedenfalls eh ausgehen. Deswegen halte ich es für sinnvoller das hier zu publizieren, um Leuten ein falsches Gefühl von Anonymität zu nehmen.

Tinder hat das Konzept Online Dating um eine wirklich gute Idee bereichert. Man loggt sich einfach per Facebook ein, kann basierend auf den Facebookdaten (Name, Fotos, Likes, Infos) sein Profil feintunen und sofort loslegen. Die App nutzt die eigene Location und schlägt potentielle Partner_innen mit Bild in der Nähe vor und sagt, wie weit sie entfernt sind. Ist man interessiert swiped man das vorgeschlagene Profil nach rechts („like“), wenn man nicht überzeugt ist nach links („nope“). Wenn man es genauer wissen will, tippt man drauf, schaut sich die Detailinformationen an (weitere Bilder, Profiltext, gemeinsame Bekannte und gemeinsame Facebook-Likes). Auf diese Weise kann man binnen weniger Minuten zig individuelle hot-or-not Entscheidungen treffen.

Ziel ist es natürlich, dass man Matches erziehlt. Also eine/r der potentiellen Partner_innen, die man geliked hat, hat einen ebenfalls geliked. Erst wenn ein solcher Match zustande kommt, kann man Messages austauschen.

Kommen wir zu der Anonymitätsfrage: Wenn man sein Profil anlegt, kann man die Fotos aussuchen. Einige nehmen dann Fotos, auf denen sie schwer zu identifizieren sind. Bei der Namenswahl schlägt Tinder standardmäßig den Vornamen vor. Man kann den aber beliebig ändern. Jedenfalls bekommt man ein gewisses Gefühl von Kontrolle vermittelt, wie anonym oder identifizierbar man sich dort darstellen will. Dieses Gefühl ist aber ein Trugschluss.

Dazu ein paar Beispiele:

Szenario 1: Ich finde eine Frau, mit der ich einen gemeinsamen Bekannten habe. Wenn dem so ist und der gemeinsame Bekannte ebenfalls Tinder nutzt, wird er mir unter ihrem Profil angezeigt. Das kommt nicht ständig, aber ab und an doch vor. (Ein wirklich sinnvolles Feature. Wenn es gemeinsame Bekannte gibt, ist die Hürde für den Kontakt gefühlt niedriger). Sagen wir außerdem, sie ist mit ihrem Vornamen „Klaudia“ bei Tinder angemeldet (die meisten nutzen ihren Vornamen weil das auch so voreingestellt ist) und der gemeinsame Bekannte heißt „Peter Grünschnabel“. Jetzt kann ich dank Facebook Graph Search folgende Query formulieren:

Peter Grünschnabel's friends named "Klaudia"

Es wird nicht lange dauern, bis ich sie in den Kontakten von Peter gefunden habe. Und anhand der Bilder (die alle von Facebook kommen), kann ich sie auch dann noch identifizieren, wenn Peter 50 Klaudias kennt.

Wer jetzt aber glaubt: Gut, dann ändere ich einfach meinen Profilnamen und bin wieder anonym, den muss ich enttäuschen.

Szenario 2: Das selbe Szenario, allerdings hat Klaudia ihren Profilnamen in „Seestern“ umbenannt. Gut, „brute force“ kann man jetzt einfach alle Kontakte von Peter durch klicken bis man vielleicht eines der Fotos wiedererkennt. Die Chancen dafür sind hoch, die Arbeit aber auch. Einfacher ist es, wenn man noch ein paar Zusatzinfos verbaut.

Zum Beispiel weiß ich ja, dass die Person weiblich ist (1. Eingrenzung) und in Berlin wohnt (2. Eingrenzung). Da bleiben immer noch ne Menge übrig. Aber Tinder gibt mir weitere Hinweise. Wenn ich zum Beispiel Facebook-Likes mit der Person gemeinsam habe, werden die mir ebenfalls im Profil angezeigt (Kommt sehr häufig vor). Sagen wir, wir liken beide die Page von ZEIT Online. Meine Query würde also lauten:

Peter Grünschnabel's female friends who like ZEIT ONLINE and live in Berlin, Germany

Das ist schon ziemlich eindeutig.

Szenario 3: Gut, dass man eine/n gemeinsamen Bekannte/n hat, ist zwar nicht selten, aber dennoch kommt es nicht andauernd vor. Eher normal ist es aber, wenn man gemeinsame Interessen, ausgedrückt durch Facebook-Likes hat. Meine Beobachtung ist, dass ich mit über 50% der Leute mindestens einen Like, öfters auch mal zwei und mehr Likes gemeinsam habe.

Wenn man also einen Namen hat (Klaudia) und einen gemeinsamen Like, sagen wir Zeit Online, kann man folgende Query formulieren:

Women named "Klaudia" who like Zeit Online and who live in Berlin, Germany

Die Wahrscheinlichkeit ist nicht gering, dass man die Nutzerin schnell findet.

Szenario 4: Gut, höchste Schwierigkeitsstufe: Klaudia hat keinen richtigen Namen angegeben („Seestern“) und wir haben keine gemeinsamen Bekannten. Aber! Wir haben ein paar gemeinsame Likes. (Dieser Fall kommt sehr häufig vor)

Hier erfährt man die Macht der verknüpften Daten. Ein einzelner Like kann die Suche nicht sinnvoll eingrenzen, aber zwei machen die Sache schon spannend:

Women who like Zeit Online and who like Spreeblick and who live in Berlin, Germany

Ziemlich sicher wird man die Person finden. Noch konkreter wird es, wenn man 3 Likes verwendet und natürlich je nieschenhafter die gelikedten Pages sind (Spreeblick matched enger als Spiegel Online).

Fazit: Auf Tinder ist man nicht anonym. Nicht jeder kann einen sofort identifizieren, aber sehr viele können. Vor allem hat man keinerlei sinnvolle Kontrolle, wer das kann und wer nicht.

Ich schreibe das nicht, weil ich das jetzt total schlimm finde und deswegen raten würde, Tinder nicht zu nutzen. Auf Tinder ist man Post-Privacy. Ich bin bekannt, als einer dessen Apologeten. Aber für mich gehört bei Post-Privacy umbedingt dazu, dass den Leuten das auch bewusst ist. Die Post-Privacy Bewegung ist keine Bewegung, die die Leute nackt machen will, sondern auf ihre Nacktheit aufmerksam machen will.

Was ebenfalls mit Post-Privacy einhergeht, ist aber auch eine gewisses Maß an sozialer Kontrolle. Dass man Menschen vor allem anhand gemeinsamer Bekannter sehr gut denaonymisieren kann, geht einher mit dem Umstand, dass so ein gemeinsamer Bekannter auch disziplinierend wirkt. So gleicht sich die Stalkinggefahr vielleicht wieder etwas aus.

Ein Tipp: Wer Tinder anonym nutzen will, sollte sich ein Fake-Facebookprofil nur für Tinder anlegen. Man verzichtet so aber natürlich wie immer auf den Mehrwert der Informationen, die das Matching erleichtern. Wie immer ein Trade Off.

Ich finde das Tinder-Konzept jedenfalls nach wie vor toll und werde es auch weiterhin nutzen.

Auch: Facebook Graph Search ist das Big Data der kleinen Leute.