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? 😉