Sichere elektronische Briefe für jedermann - Kullo

[SimonW]

Hallo Leute,

ich trage seit Jahren die Idee im Kopf rum, ein sicheres und leicht zu bedienendes Nachrichtensystem zu entwickeln, das E-Mail ersetzen kann. Es soll komplett frei (wie Freiheit) sein, damit jeder eigene Client- und Serversoftware entwickeln kann.

Hauptmerkmale:
- Ende-zu-Ende-Verschlüsselung
- dezentral
- sicher gegen Vorratsdatenspeicherung

Falls sich jemand für das Thema interessiert, könnt ihr euch hier über die Projektidee informieren und mich auch gerne persönlich kontaktieren:
http://kullo.org/
https://twitter.com/kulloproject
https://www.facebook.com/kulloproject
Weitere Projektdetails werden dort auch veröffentlicht, also folgen kann sich lohnen!

Das ganze will ich ab Oktober Vollzeit entwickeln, da ich mit meinem Mathe-Bachelor durch bin.

Was haltet ihr davon?

Grüße, Simon

[MisterD123]

Ich bin dafür du gibst nutzern auch die möglichkeit, nicht nur eine spam-blacklist aufzubauen, sondern umgekehrt eine trust-whitelist benutzen zu können. Leute könnten ihre signatur-verfikation öffenltich zum download anbieten sodass privatpersonen wenn sie mit jemandem in email-verkehr eintreten möchten sich die dann runterladen und lokal in den client installieren könnten, alle signaturen die nicht installiert sind werden automatisch geblockt. Das ist natürlich unbrauchbar für öffentliche email-adressen an die jeder schreiben dürfen soll, aber für privat-adressen fände ich das durchaus interessant.

[SimonW]

Ich bin dafür du gibst nutzern auch die möglichkeit, nicht nur eine spam-blacklist aufzubauen, sondern umgekehrt eine trust-whitelist benutzen zu können. Leute könnten ihre signatur-verfikation öffenltich zum download anbieten sodass privatpersonen wenn sie mit jemandem in email-verkehr eintreten möchten sich die dann runterladen und lokal in den client installieren könnten, alle signaturen die nicht installiert sind werden automatisch geblockt. Das ist natürlich unbrauchbar für öffentliche email-adressen an die jeder schreiben dürfen soll, aber für privat-adressen fände ich das durchaus interessant.

Meinst du nicht, da würde eine Verbreitung des Systems behindern? Meiner Meinung nach muss es möglich sein, den eigenen Eltern innerhalb von 5 Minuten am Telefon zu erklären was sie tun müssen um alles zu registrieren.

Aber ich denke Massenmailversand wird massiv teurer, wenn man Hardwarekosten der Sendermaschienen bedenkt. Wenn man jede Nachricht für jeden Empfänger mit RSA o.ä. verschlüsseln muss und vorher den Empfängerschlüssel abholen muss ist das im Vergleich zur E-Mail sehr viel Aufwand. Und da die Klickrate bei Spam-Mails nicht sehr hoch sein dürfte, muss der Versand einer SPAM-Nachricht billig sein.

[MisterD123]

meinst du wirklich das system ist für eltern geeignet? ich würde meiner mutter nicht zutrauen, nen privaten key sicher aufzubewahren ohne ihn zu verlieren. Das schließt meinem empfinden nach das system für jegliche technisch unversierten nutzer sowieso schon aus. Was meinst du warum fast niemand verschlüsselung benutzt? wenn man den schlüssel verliert sind alle daten weg, ganz einfach. Solang man nur temporäre nachrichten verschickt ist das nicht so wild, die kann man im zweifelsfall nochmal schicken, aber so ne signatur muss trotzdem neu verteilt werden. Und wenn du anderer leute signaturen überprüfen willst brauchst du ihre öffentlichen verifizierer sowieso lokal installiert, da kann man sie auch gleich für ne whitelist mitbenutzen.

Und selbst wenn, wie gesagt die whitelist sollte optional sein, öffentliche adressen, zB service-adressen von irgendwelchen geschäften oder sowas, können whitelists eh nicht benutzen.

[SimonW]

Um das Problem mit der Schlüsselverwaltung zu lösen würde ich die Schlüssel mit dem Passwort verschlüsselt beim Mail-Anbieter lagern.

Das ist möglich, da man 2 Passworte hat.
- Eintipppasswort des Users
- Serverpasswort zum Login beim Anbieter

Bevor sich ein Client beim Mail-Anbieter einloggt, hasht er aus dem Eintipppasswort das Serverpasswort. So kennt der Mail-Anbieter das Eintipppasswort nicht.

[mmi1991]

Wie willst du Man-In-The-Middle unterbinden? Authentifizierung?
Dann brauchst du wieder eine zentrale Serverinstanz (oder auch mehrere), denen man vertraut…

[SimonW]

Wie willst du Man-In-The-Middle unterbinden? Authentifizierung?
Dann brauchst du wieder eine zentrale Serverinstanz (oder auch mehrere), denen man vertraut…

Ich will auf HTTP-Verbindungen aufsetzen und öffentliche Schlüssel per HTTPS abholen. Dafür würden die Clients eine Auswahl an Stammzertifikaten mitbringen, die sich zum Beispiel am Firefox orientieren könnte.

[AlexPi11]

Klingt interessant, aber an manchen Stellen bin ich mir nicht so sicher ob ich das Konzept verstanden habe.

Code: Alles auswählen

(1) does not have to rely on the security of his internet connection,
(2) is protected from censorship,
(3) can be sure that his own messaging provider can not read his messages,
(4) is protected against data gathering by telecommunication companies and network providers,
(5) can authenticate the origin of an incoming message.

1: Welche Sicherheit? Bzw. was stellt Kullo jetzt trotz nicht vorhandener sicherer inet Verbindung sicher? Sicherheit ist immer so ein weiter Begriff.
2,3,4: Das sollte mit asynchroner Verschlüsselung ja gut machbar sein. Also hier geht es ja erstmal nur um die Inhalte zu schützen. Oder soll hier (bezogen auf 2) schon sowas wie Steganographie mitschwingen, falls z.B. der ISP auffälligen Traffic einfach nicht weiterleitet?

Code: Alles auswählen

(a) End-to-end encryption: On the way from the sender to the receiver, nobody is able to read the message. Unencrypted messaging is not possible – I call this a feature.
(b) Decentralization: Everyone in the internet can set up his own messaging server for personal use, company messaging or as a service provider.
(c) Receiver-only envelope: Letters in the paper world have a key feature that all digital communications miss: the ability to send a letter without a sender name on it. Let's get that option back! No inbox provider needs to know who is writing messages to me.
(d) Signature inside: After opening the digital envelope, it is possible to check the sender's signature. Required signatures make it easy to blackist junk senders.
(e) Opening confirmations: Confirmations which certify that a message was delivered, decrypted and the signature was verified successfully. 

Zu b: Also um einen eigenen eMail Server aufzusetzen gibts es ja schon einige (open source) Lösungen. Oder gibts es hier Besonderheiten, die man noch designen und implementieren müsste? Ist das dann noch kompatibel mit den üblichen email providern wie z.B. gmx? Also: Muss ich mir einen Anbieter suchen, der deine Serverimplementation laufen hat (oder im Zweifel setzte ich selber einen auf); oder ist das nur optional mit dem eigenen Server(n)?

Zu c: Ich glaube die Senderadresse an sich sollte kein großes Problem darstellen. Interessanter wird es dann aber, wenn man auch die Route der eMail verschleiert werden soll. Da wären wir schon bei Mixnetzwerken, wie z.B. Mixmaster.

Ich persönlich habe mich zu Anfang erst gefragt, warum nicht einfach Thunderbird + Enigmail? (+ eventuell Mixmaster oder Tor). Für decentralization gibts schon offene Serverimplementationen (gehe ich mal schwer von aus). Dann bliebe "nur" noch Receiver-only envelope. Da hab ich keine Ahnung von den Protokollen (SMTP) um einzuschätzen, ob das zum Beispiel nicht einfach per AddOn für Thunderbird möglich wäre.
Vielleicht kannst du nochmal kurz schildern was Kullo hier anders machen würde oder was es zusätzlich noch ermöglicht.

[AlexPi11]

Um das Problem mit der Schlüsselverwaltung zu lösen würde ich die Schlüssel mit dem Passwort verschlüsselt beim Mail-Anbieter lagern.

Das ist möglich, da man 2 Passworte hat.
- Eintipppasswort des Users
- Serverpasswort zum Login beim Anbieter

Bevor sich ein Client beim Mail-Anbieter einloggt, hasht er aus dem Eintipppasswort das Serverpasswort. So kennt der Mail-Anbieter das Eintipppasswort nicht.

Hmmm. Also ohne ein eigenes Schlüsselpaar zu erstellen und zu verwalten wird es denke ich nicht gehen. Das zu vereinfachen ist bestimmt ein wichtiger Schritt. Aber es wäre schön, wenn ich z.B. einfach meinen vorhandenen openPGP Schlüssel benutzen könnte. Das ist dann auch schon eingermaßen verbreitet und ausgereift.

[SimonW]

Hi AlexPi11,

zu (1): es geht einfach darum, dass man Nachrichten in unverschlüsselten Netzen nicht lesen kann. Die halbe Nation beklagt sich, wenn Google E-Mail-Nachrichten aus unverschlüsselten WLANs mitschneidet, aber dass das jeder genau so selbst machen könnte, stört niemanden.

(2) hast Recht, ist ziemlich offen formuliert. Es bezieht sich hauptsächlich auf Praktiken wie beispielsweise in China, wo Paketverkehr nach einzelnen Worten durchsucht und geblockt wird.

(b): Das Nachrichtensystem wird von Grund neu auf konzipiert und hat nichts mehr mit E-Mail zu tun. Entsprechend braucht man eigene Serversoftware und Provider, die den Postfach-Service anbieten. Alternativ kann man selbst sein eigener Provider sein - wie man möchte. Eine Serversoftware für kleine Benutzerzahlen werde ich vermutlich selbst als Open Source veröffentlichen.

(c): Bei einer E-Mail kann man ja als Absender sowieso jede beliebige Adresse eintragen, was meiner Meinung nach fatal genug ist. Der eigentliche Punkt ist aber, dass eine Kullo-Nachricht bis auf den Empfänger alles weitere verschlüsselt. Bei PGP ist soweit ich weiß der gesamte Header inkl. Betreff unverschlüsselt.

Zu Thunderbird+Enigmail+Mixmaster+Tor:
Kennst du viele Menschen (die nicht an der TU studieren), die mit solchen Systemen umgehen können und den Nerv haben, sich damit auseinanderzusetzen? Ich finde das ja auch immer einfach einzurichten aber stand dann meistens vor dem Problem, dass ich einem potentiellen Kontaktpartner nicht erklären konnte, wie er in 3 Minuten zu aller Software und allen Einstellungen kommt.
Meine Vision ist ein System, das vom Benutzer nichts weiter verlangt als seinen Provider, seinen Benutzernamen und ein Passwort.

Ich finde es wichtiger ein fast perfektes System zu haben, dass 80 % der Internetnutzer handhaben können, als ein absolut perfektes System, mit dem nur 5 % der Internetnutzer umgehen können.

Zeitweise habe ich tatsächlich dazu tendiert, PGP als Krypto-Grundlage zu verwenden, aber ich denke dass ein hierarchisches Sicherheitssystem einfacher zu handhaben ist.

Grüße,

Simon

[morgoth]

Zeitweise habe ich tatsächlich dazu tendiert, PGP als Krypto-Grundlage zu verwenden, aber ich denke dass ein hierarchisches Sicherheitssystem einfacher zu handhaben ist.

Also S/MIME?

Ich fände das projekt interessant, seh allerdings zwei große Probleme.
1. sollte so ein System auf bestehenden Standards aufbauen (sprich e-mail etc.) andernfalls wird es niemand benutzen (außer ein paar nerds).
2. versuchst du mal schnell das PKI problem zu lösen, dass die letzten 20 jahre existiert. Hört sich für mich etwas utopisch an

[SimonW]

Also S/MIME?

S/MIME ist ja speziell für E-Mail-Verschlüsselung entwickelt worden und daher für mein Projekt zu starr.

Ein Problem ist zum Beispiel, dass die symmetrische und asymmetrische Verschlüsselung als Black-Box in einem Schritt passiert. Ich will das gerne getrennt haben, so dass man beim Versand vom Nachrichten an viele Empfänger den Aufbau der Nachricht inkl. der symmetrischen Verschlüsselung nur einmal vornehmen muss. Danach wird der selbe Symmetrische Schlüssel speziell für jeden Empfänger asymmetrisch verschlüsselt.

Ich sehe auch keine Notwendigkeit darin, öffentliche Schlüssel zu signieren, wie es bei X.509 für S/MIME getan wird. Wenn man den öffentlichen Schlüssel über eine HTTPS-Verbindung abholen kann, ist die Unversehrtheit implizit durch den Provider sichergestellt.

Daher werde ich wohl mit OpenSSL-Funktionen arbeiten. Momentan teste ich verschiedene Formate zum Speichern öffentlicher RSA-Schlüssel. Einen verbreiteten Standard scheint es nicht zu geben. Deswegen will ich nun PEM-Dateien aus OpenSSL in lesbare XML-Dateien umwandeln.

Grüße,

Simon

[morgoth]

Ein Problem ist zum Beispiel, dass die symmetrische und asymmetrische Verschlüsselung als Black-Box in einem Schritt passiert.

Was ist an der Black-Box so schlimm?

Ich will das gerne getrennt haben, so dass man beim Versand vom Nachrichten an viele Empfänger den Aufbau der Nachricht inkl. der symmetrischen Verschlüsselung nur einmal vornehmen muss. Danach wird der selbe Symmetrische Schlüssel speziell für jeden Empfänger asymmetrisch verschlüsselt.

Genau das macht PGP

Ich sehe auch keine Notwendigkeit darin, öffentliche Schlüssel zu signieren, wie es bei X.509 für S/MIME getan wird. Wenn man den öffentlichen Schlüssel über eine HTTPS-Verbindung abholen kann, ist die Unversehrtheit implizit durch den Provider sichergestellt.

Es geht bei der Signatur eines Schlüssel in einem X.509 Zertifikat nicht in erster Linie um die Unversehrtheit sondern um darum ob ich diesem Schlüssel vertrauen kann oder nicht. Wenn du sozusagen nur eine CA hast die die Schlüssel verteilt macht es natürlich keinen Unterschied ob ich sie nur per SSL für den Transport sichere oder Signiere. Aber sobald du mehrere Stellen haben möchtest von denen du Schlüssel beziehen kannst wirst du um eine Signatur der Schlüssel nicht herum kommen wenn du Vertrauen in die Schlüssel herstellen möchtest.

grüße