heise-news: @@

Wie schätzen die erfahren Verschlüsseler dieses Angebot ein?
Wer Erfahrungen mit anderen Lösungen, der kann natürlich besonders gut den Wert dieses Angebot einschätzen – daher meine Frage.

Die bisherige kostenlose PGP-Alternative GnuPG ist ja nicht so ganz einfach zu installieren, dieses Angebot nun aber wohl betont einfach zu handhaben – das wird auf jeden Fall versprochen.

fk6

(...) Vertrauen...

Wenn ich jemandem blind vertrauen muß, dann kann ich ihm auch gleich unverschlüsselte Mails schicken.

Vielleicht wird der Code nicht von jedem verstanden werden, aber er wird mit Sicherheit den ein oder anderen zu einer weiteren Diskussion veranlassen.

fk6Mir bitte die Tüte mit den kleinen Kieseln
fk6rechts auf das "Quote-Zeichen" klicken

fk6

Richtig, der CA muß man Vertrauen schenken. Das ist aber der Vorteil gegenüber der PKI bei GPG/PGP: dort kann ich nicht per se einer CA das Vertrauen schenken, sondern bin gezwungen jeden Key selbst zu verifizieren. Aber das hattest du ja bereits geschrieben und das ist auch meine Kritik an der PKI von GPG/PGP. Die schlechte Nutzbarkeit für normale Anwender ist der Grund, warum es sich nicht besser verbreitet.

Was ist der Grund, daß sich S/MIME nicht verbreitet hat? Aus meiner Sicht folgende Punkte: es ist noch zu neu (ebenso wie PGP/MIME), es ist daher noch nicht in allen wichtigen MUAs integriert, drittens ist nicht ganz einfach an ein von einer CA signiertes Schlüsselpaar zu kommen (weil den meisten Leuten die Info fehlt, wo man sowas (kostenlos) bekommen kann) und viertens - imho der wichtigste Punkt - weil den meisten Leuten einfach das Bewußtsein dafür fehlt, daß Signieren oder Verschlüssel von Mails einen Sinn auch für Privatleute besitzt. Meistens wird man mit dem Argument "ich habe nichts zu verbergen" konfrontiert und das war es dann auch.

Noch ein Punkt: wenn ich niemandem vertrauen würde... dann würde ich auch nicht zu dem System von Ciphire greifen. Mir fehlt die Zeit die Review komplett durchzulesen, aber jedesmal wenn eine Mail verschlüsselt werden soll, telefoniert der Ciphire-Client nachhause und holt sich den public key der Empfänger. Es ist für Ciphire ein einfaches damit ein Kommunikationsprofil von mir anzulegen (auch wenn es den Inhalt nicht kennt) und ich bin mir sicher, sollte sich Ciphire verbreiten, werden gewisse Stellen Begehrlichkeiten an diesen Daten entwickeln. Und sollte der Ciphire-Service mal unavailable sein... kann ich keine Mails schicken? Naaja..

Was aus mehreren Beiträgen – besonders der Erfahrungen von rhstz – ersichtlich:
Die bisherigen Verschlüsselungstechniken finden nur zögerlich Anwendung, weil vielen die Handhabung zu kompliziert.

Wenn Ciphire diese wesentlich vereinfacht, dann ist das wohl – objektiv betrachtet – ein großer Fortschritt im Sinne breiterer Verschlüsselungsanwendung.

Rantanplan
Pardon, aber man kann es mit dem „Verbraucherschutz“ auch übertreiben. d.h. ihn ad absurdum führen: „…an der Nadel hängen (bei Ciphire)…“; oder der mögliche Mißbrauch Dritter bei der Verbreitung des Programms.

Möglichkeiten über Möglichkeiten, jenseits nicht allzu großer Wahrscheinlichkeit - das ist wirklich zu arg!
(Und schade angesichts Deiner sonst so kenntnisreichen Beiträge!)

„…zwei Baustellen, die mucken können…“
Ja, vielleicht – geht morgen die Welt unter oder auch nicht.
Nein, im Ernst: Ob und was da muckt, das läßt sich nach der praktischen Feuertaufe sagen – Baustelle hin, Baustelle her.
Bei einigen Anwendern hat das Produkt diese schon bestanden, die sonstigen theoretischen Überlegungen hier legen auch ein Ausprobieren nahe.

Womit die wesentlich Aufgabe dieses Threads schon erfüllt, der weitere Gedankenaustausch weiterhin willkommen!

Hot Mac

Wie bei GPG, wo ein Riesenproblem erst durch nen externen Audit kam, nix Open Source sondern Audit, die wir auch machen werden, glaube ich nicht, dass uns public source viel bringen wird, leider, deswegen finden wir es auch nicht so nuetzlich. Das es da Fanaten gibt ok, aber bringen tuts trotzdem nicht so viel:(

S/MIME ist in alle MUAs implementiert bis auf Eudora, nur halt zum teil unterschiedlich, ein nettes Problem was bei PGP auch vorkommen kann, man nehme die IDEA Diskussion:)

Dsa mit Traffic Analysis und Kommunikationsprofil stimmt leider auch nicht. Wir haben nen Cache von 3 Tagen, fuer positive wie negative Anfragen. Benuetze TOR und niemand wird das sehen, wir werden bald 3rd party proxies anbieten dann koennen wir auch nix mehr sehen, aber selbst im Moment ist das nicht wirklich moeglich da ticket-based system.

Zu SMIME, weil die Applikation fehlt, der Aufwand fuer den Nutzer zu gross ist, meine Mum weiss nicht was ein Schluesselpaar ist und hat auch kein Interesse das zu lernen und weil man bei SMIME auch eine zentrale Instanz braucht der man vertrauen kann. Und das ist nun mal nicht gegeben, ausser man muss dieser zentralen Instanz nicht vertrauen, wie bei uns:)

Im Bezug auf die Argumente nix zu verbergen, ja kriegen wir auch manchmal wir daber weniger, das mit Spiegel Online ab 1.1. wird jeder abgehoert tut sein uebriges, wobei man es den Leuten ja auch ganz einfach verstaendlich machen kann mit den Postkarten. Aber keiner hat Lust dafuer FUnktionalitaet einzubuessen, das ist ein Problem, das selbe gilt fuer neues lernen wie Schluesselpaar etc oder bei jedme key irgendwas machen zu muessen.

fk6

Pseudemys
Dazu sage ich nur zwei Dinge: a) fk6 versteht die Einwände sehr wohl und geht argumentativ auch darauf ein. Im Review werden diese Punkte sehr wohl auch behandelt, da sie - anders als du meinst - keine irrelevanten Phantastereien sind, sondern die Basis eines vertrauenswürdigen Systems darstellen. Und b) wenn dir nichts mehr einfällt, wirst du persönlich.

RantanplanDas finde ich noch das treffendste Argument. Die "zweite Baustelle" finde ich zu vernachlässigen, denn mehrere Baustellen hast du letztlich schon jetzt. Neben Mail.app, das als Hülle ja eigentlich mehrere Programme beherbergt, nicht zu letzt das Adressbuch und vor allem das Schlüsselbund, welches vermutlich ohnehin das schwächste Glied in der Kette darstellt.

Aber schon an der Diskussion um JAP zeigt sich, wo der Hase längs hüpft. Vermutlich also dürfte Ciphire ein ebenso beliebtes Ziel für verschiedene Seiten darstellen - kein so schöner Gedanke .

fk6

Meine Mami weiß, was ein Schlüsselpaar ist - sie hat auch ein eigenes.

Wie dem auch sei, so wollte ich Dir nicht an den Karren fahren, aber die Sache mit dem "Vertrauen", wem auch immer man vertrauen will, läßt sich nicht so einfach unter den Tisch diskutieren.

Wem man Vertrauen schenken möchte, das bleibt jedem selbst überlassen.

Ich glaube, zum momentanen Zeitpunkt Sympathiebekundungen laut werden zu lassen, wem man nun eher vertrauen will, erscheint doch etwas grotesk.

fk6

"S/MIME ist in alle MUAs implementiert bis auf Eudora"

Dann sieht es ja inzwischen besser aus als ich dachte.

"ein nettes Problem was bei PGP auch vorkommen kann, man nehme die IDEA Diskussion:)"

Oh ja, das war auch einer der Gründe, warum ich mich vor einiger Zeit von GPG getrennt habe. Und das, obwohl ich einen Key habe, der von der c't bei einer ihrer Kryptokampagnen gegengezeichnet wurde. Daß das GPGMail-Plugin ständig zickt war dann für mich das KO-Kriterium.

"Dsa mit Traffic Analysis und Kommunikationsprofil stimmt leider auch nicht. Wir haben nen Cache von 3 Tagen, fuer positive wie negative Anfragen. Benuetze TOR und niemand wird das sehen, wir werden bald 3rd party proxies anbieten dann koennen wir auch nix mehr sehen, aber selbst im Moment ist das nicht wirklich moeglich da ticket-based system."

Schön zu hören, aber ich persönlich habe bei zentralistischen Systemen ein Vertrauensproblem

"Zu SMIME, weil die Applikation fehlt, der Aufwand fuer den Nutzer zu gross ist, meine Mum weiss nicht was ein Schluesselpaar ist und hat auch kein Interesse das zu lernen und weil man bei SMIME auch eine zentrale Instanz braucht der man vertrauen kann."

Inwiefern das neue System tatsächlich einfacher und problemloser handhaben läßt als S/MIME in Apple Mail, wird sich noch zeigen müssen. Die Schlüsselbesorgung kritisiere ich auch, da könnte sich Apple, besonders für die zahlenden .mac-Abonnenten, wirklich mal etwas einfallen lassen (z.B. ein kostenloses, einfach zu generierendes Schlüsselpaar). In der Benutzung selbst kann ich mir kaum etwas problemloseres als S/MIME in Apple Mail vorstellen.

PS: Ja, ich weiß, ich reite immer auf Apple Mail herum, aber wir sind halt nun mal alle Macanwender hier und ein großer Teil davon benutzt Apple Mail

Rantanplan
Zu: Da mußt gerade Du aber ganz still sein, denn das hast Du in einer wenig schönen Art vor kurzem (allerdings einmalig, möge es dabei bleiben!) praktiziert.
Ansonsten darf man ja sehr vorwiegend den Kenntnisreichtum Deiner Beiträge genießen – vielen Dank dafür!
(Leider bin jetzt schon wieder persönlich geworden.)

Alle
Prinzipiell:
Etwaige mögliche Nachteile eines Unternehmens (die man natürlich im Auge behalten sollte) sollten nicht den Blick auf den aber in jedem Falle nicht möglichen, weil tatsächlichen Vorteil einer Sache verstellen - den sollte man vor allem würdigen (und dann das andere auch; es gibt schließlich wichtige und weniger wichtige Dinge).

Bei der Diskussion um den nächsten Autokauf könnte natürlich jemand die Möglichkeit einwerfen, daß man doch mit so einem Auto auch zu Tode kommen könnte, nicht…?
Und er hätte damit ja sogar recht – aaabeer…!

Ist jetzt klarer geworden, was ich meine?

Pseudemys

Glasklar, Pseudemys, glasklar...;-)

An Alle

Immer lässig bleiben.

Pseudemys, gerade bei Verschlüsselung kommt es auf dem Stand der Dinge entsprechende Sicherheit an, sonst kann man es gleich lassen. Bei aller Usebillety, die wohl jeder sucht, sollte man Vor- und Nachteile auch von allen Seiten betrachten. Ein kompromittierbares System nutzt niemandem etwas. Oder eines, welches mich bei mangelnder Erreichbarkeit nicht mehr mailen lässt. Oder eines, was die versprochene Diskretion nicht halten kann. Oder oder. Je mehr Leute sich dazu Gedanken machen und kritisch nachfragen, desto besser. Und je mehr zufrieden stellende Antworten es gibt, desto vertrauenswürdiger. Du brauchst doch aber eine Grundlage, auf Grund derer du dich entscheiden kannst. Wenn dir das bisher geschriebene reicht, ist´s doch o.k. Ich gucke mir das noch ein wenig an, interessiert, aber kritisch .

Pseudemys

Passender wäre der Vergleich: du kaufst dir ein Auto, kannst damit aber nur an den Tankstellen dieser einen Firma auftanken.

Bei Ciphire sieht es m.W. so aus:

1. Schlüssel/Zertifikate bekommst du nur von ihnen
2. Bei jedem Mailversand wird der öff. Schlüssel des Empfängers von einem zentralen Server dieses einen Betreibers geholt
2a. Die Signierung/Verschlüsselung ist nur benutzbar, wenn der Service dieses Anbieters online ist

Bei S/MIME(*) so:

1. Schlüssel/Zertifikate bekommst du von jeder CA die dir genehm ist
2. eine weitere Kommunikation mit der CA oder einer anderen zentralen Stelle tritt nicht auf

(*) S/MIME habe ich als Beispiel genommen, weil es ohne zusätzliche Installation bereits in Apple Mail vorhanden ist und ohne Expertenwissen benutzbar ist (wie gesagt: die Schlüsselbeschaffung ist schlecht gelöst, aber das macht man einmal (plus Renewal jedes Jahr o.ä.)).

Mal schauen ob ich das mit dem quoten hinbekomme:)

Ties-Malte

Darum haben wir was gebaut was wir nicht effizient kompromitieren. 1+1 zusammenzaehlen und dann versteht ihr. Sonst haetten wir das nie hingesetzt. Wir wissen wie oft an bestimmte Stellen anfragen kommen deswegen die Papers etc, unser System kann man so nicht kompromitieren. Da wir es nicht koennen koennen es andere so auch nicht. Sie koennen uns natuerlich DDOSen oder vom Netz nehmen, aber das sind dann ganz andere Groessenordnungen.

Der Client funktioniert nicht mehr richtig wenn es uns nicht gibt. Er wird zwar alles incoming decrypten koennen aber spaetestens nach 3 Tagen, solange ist der normale Cache eingeschaltet, wird es keine encrypted emails mehr geben.

Anders als durch eine zentrale Instanz ist das aber auch schwer zu regeln. Wir werden aber das Redundanz Problem noch anders angehen, nur eines nach dem anderen:)

Hot Macnunja, du vertraust sehr sehr vielen Dingen und wir machen die Welt sicher nicht unsicherer. Du vertraust zb DNS und Mac, das zb der Mail-Client keinen Mist baut etc.
der Punkt ist, das mit dem Vertrauen ist ein valider Punkt nur wenn du closed source software den ganzen tag benuetzt die zentrale Systeme nutzt, dann machen wir es sicher nicht schlimmer:)

Rantanplan:Einfach mal ausprobieren dann wirst du sehen, vor allem wenn du ab und zu vielleicht auch mit armen Nicht-Mac Usern kommunizieren musst die vielleicht keine so perfekte S/MIME Implementation haben:)

Nein siehe Cache.

nunja ich weiss noch immer nicht wo du meine smime key das erste mal herbekommst.

puh:)

fk6

zu dem wir koennen alles sehen, hat hier jemand was nuetzliches geschrieben:



und entgegen den behauptungen gibt es schon einige fans ovn uns, wir schreiben nicht unter falschen namen auf die foren, wie man hier bei mir auch gesehen hat, wir sind transparent und offen und wir wissen, dass wir leider auf der webpage noch nicht genuegend info ueber uns haben, dann wuerde man uns verstehen, nicht lieben, aber zumindestens verstehen:)

fk6

fk6
Akzeptiert. Ich werde es mir sicher irgendwann mal ansehen

Verstehe, das ist der clientseitige 3-Tage-Cache. Ok, das verringert das Problem, daß man plötzlich keine Mails verschicken könnte, weil euer(e) Server offline sind.

Die werden in der Mail (in der Signatur) mitgeschickt. Wenn mir jemand eine (S/MIME-)signierte Mail zuschickt, dann landet dessen Zertifikat mit seinem öffentlichen Key in meinem Schlüsselbund. Ohne mein Zutun. Das hat schon manchen zu der Frage "Hey, was machen die ganzen Zertifikate in meinem Schlüsselbund" veranlaßt, weil die Zertifikate auch dann gesammelt werden, wenn man selbst kein S/MIME benutzt.

Wollte ich dir also eine verschlüsselte Mail schicken, müßtest du mir erstmal eine beliebige, aber signierte Mail von dir schicken. Danach erscheint, wenn ich eine Mail an dich adressiere, in Apple Mail automatisch das Knöpfchen zum Verschlüsseln.

Oder noch anders ausgedrückt: es ist eine initiale Mail mit Signatur vom Empfänger nötig, damit ich ihm etwas verschlüsselt schicken kann. Ich denke aber, daß das keine allzu große Einschränkung ist, kann man dafür aber auf eine zentrale Key-Datenbank verzichten (die andererseits natürlich auch Vorteile hat, z.B. beim Revoke).

Ein ganz herzliches Danke, daß du dir hier so große Mühe gibst, euer System zu erläutern. Ich weiß es zu schätzen, auch wenn ich nicht immer deiner Meinung bin

Dem schließe ich mich gerne an.

Ich finde das Web of trust ganz schlüssig. Wie weit ich anderer Leute Schlüssel traue bzw. anderer Leute Fähigkeit, Schlüssel erst nach gründlicher Prüfung zu authentifizieren, entscheide ich für mich allein.
Ich traue einem nicht selbst überprüften gpg-key weniger als einem von Verisign o.ä. signierten. Aber einem geprüften gpg-key traue ich mehr als einem s/mime key.
Rantanplan: Das Problem besteht ja doch darin, die Echtheit der e-mail-Adresse des Empfängers/Absenders zu prüfen. Aber bei fremden Absendern/Empfängern sagt mir das s/mime Zertifikat ohne weitere Recherche nur, dass die E-mail von dem E-mail-Account stammt, von dem sie vorgibt zu stammen. Was nun, wenn die natürliche/juristische Person hinter dem Account nicht die ist, die ich erwarte? Wie gesagt, mein Client sagt mir dazu nichts, wenn ich die erste signierte e-mail erhalte. Wenn ich die akzeptiere, bin ich im schlimmsten Fall schon reingefallen.
Ob das Problem bei Ciphire auch besteht, weiß ich nicht, muss ich erst mal noch ansehen. Vielen Dank an fk6!! A propos, war der Empfang hier oK?
Wenn das Interface zu GPG besser wird (Entwickler: unterstützt das Projekt!!!), können mehr damit umgehen.
Siehe dazu PGP, Kostenfrage oben schon abgewickelt, aber Key-Verwaltung gut gelöst.

Ach, eins noch: PGP/GPG verstehen sich auf mehrere E-Mail-Adressen pro Keypaar. Wenn ich meinen E-Mail-Account wechsle, bleibt der Schlüssel mein,. Und ich kann veröffentlichen, dass die alte Adresse nicht mehr gilt. Geht sowas bei Ciphire auch?

Ralf Vogt
Ich bin ja kein Kryptographie-Experte, aber.... die X.509-PKI geht immer davon aus, daß es eine per se vertrauenswürdige Stelle gibt (bzw. deren mehrere), die CA. Du kannst zwar wie bei PGP/GPG auch einen Schlüssel selbst erstellen und ihn gegenzeichnen, aber dann wird dir dein Mail-Programm sagen, daß es den damit unterzeichneten Schlüssel für nicht vertrauenswürdig hält (weil es kein Schlüssel einer der CAs ist).

Bei PGP/GPG mußt du die Vertrauenswürdigkeit selbst prüfen, also entweder den Hash vergleichen oder du kennst (=vertraust) jemanden, der den öff. Schlüssel gegengezeichnet hat. Bei einem "gültigen" X.509-Zertifikat ist derjenige der gegengezeichnet hat immer eine der - dem Mail-Programm - bekannten CAs. Wenn also eine (bekannte) CA das Zertifikat gegengezeichnet hat, dessen öffentlicher Schlüssel noch nicht expired ist, dann ist der Schlüssel vertrauenswürdig (per definitionem).

Der Client sagt dir, daß er die Echtheit nicht überprüfen kann, wenn die Signatur nicht mit dem öffentlichen Schlüssel der ausstellenden CA geprüft werden kann. Eine Signatur fälschen kann man (im Rahmen der Sicherheit eines kryptographischen Algorithmus) nicht, denn dazu benötigst du den privaten Schlüssel der CA, bekannt ist natürlich nur der dazu komplementäre öffentliche. Insofern müßtest du, um den Empfänger zu übertölpeln, eigentlich zuerst seinen Datensatz an öffentlichen CA-Schlüsseln kompromittieren, bevor du ihm die Fake-Mail schickst.

Ralf Vogt
Wenn fk6 morgen noch mal kommt, kann er das sicher besser beantworten. Ich vermute aus dem was ich gelesen habe, daß es in dieser Hinsicht ähnlich wie X.509/S/MIME ist: du hast einen privaten Key und für jede Mail-Adresse ein signiertes Zertifikat mit dem öffentlichen Schlüssel.

Das ist etwas, wo meinem Verständnis nach bei Ciphire im Vorteil ist, da jeder Client sich die öffentlichen Keys aus einer zentralen Datenbank besorgt. Ein Revoke ist spätestens nach der Lebensdauer des Caches überall durchgesetzt. Bei X.509 gibt es Revoke-Listen, aber es ist niemand gezwungen die aktuell zu halten... oder so ähnlich, damit habe ich mich nie näher beschäftigt

Nachtrag:

Es sollte "meinem Verständnis nach Ciphire im Vorteil ist" heißen.

Und zum Revoke: ohne zentrale Key-Datenbank, auf die jeder Client gezwungen ist zuzugreifen, ist ein Revoke immer eine unsichere Sache. Deswegen haben Zertifikate ein Verfallsdatum - häufig nach einem Jahr - und danach benutzt kein Client ohne Murren das Zertifikat noch.

Rantanplan:
Nur mal um ein wenig den paranoiden raushaengen zu lassen, bei smime gibt es keine garantie, dass der schluessel den du bekommst auch wirklich von der anderen seite ist, den muesstest du genauso verifizieren. Da ich wenn ich deinen Mailverkehr hijacke oder als CA, beliebig Certs fuer dich erstellen kann. Und wenn ich einmal eines hab in deinem Namen, dann gehts ganz einfach dich immer zu Man-in-the-middlen. Man tausche bei deinen outgoing signatur und smime key aus. Du wirst das nie feststellen. Ausser du kommunizierst mit der anderen person out of bounds und tust fingerprints checken.

Bei uns kann es pro email address nur einen key geben, das ist garantiert, bzw es wuerde auffallen.

Ralf Vogt: Ja hier kann man wenigstens diskutieren:)
Das mit dem Web of Trust funktioniert natuerlich bei closed user Gruppen. Meiner Meinung nach auch ziemlich gut, aber das muessen halt alles Leute sein die sich auskennen. Uns fehlt natuerlich komplett der Cypherpunk appeal, wir sind so sexy wie acrobat reader fuer die. Aber fuer die die nur nach ner Loesung gesucht haben sind wir das tool:)

Problem ist, dass das web of trust sehr unbefriedigend skaliert, was ich meine ist, es skaliert fast linear, wenn ich jemandem neuen was schicken will, dann nuetzt mir mein existing web of trust leider meistens sehr wenig, und das ist halt bei offenen gruppen wie zb wenn eine bank das einsetzen wuerde nervig. ich persoenlich finde das ding witzig und auch das ganze research darum mit, mean shortest distance etc, aber leider fuer den normal user total uninteressant. sind nur wir den das interessiert.

ein wichtiger unterschied ist, das wir nicht identitaeten zertifizieren, sondern email addresses, genauer, dass du zu dem zeitpunkt wo wir dir eine email geschickt haben, diese auch empfangen konntest. nix mehr. gpg ist da anders, das sieht eher aus wie identitaet, und zwar wenn gewollt und richtig gemacht real-life identity. dann muss man aber auf die kesigning parties und muss leider eigentlich dann auch die ausweise auf echtheit ueberpruefen. was leider nicht geht, bzw die meisten nicht koennen. es ist relativ einfach so nen ausweiss von irgendwo zu faelschen vor allem wenn es um US drivers licenses geht, was die amis ja die ganze zeit machen um an alkohol zu kommen, das sub21 problem bei denen:) wir machen fuer jede email addresse ein neues zertifikat.

wir machen nur message security nicht identity proof.
das ist ein geschaeft, so aehnlich wie dt. signaturgesetz von dem wir uns fernhalten:)

fk6

Rantanplan:
das problem bei den lieben CRLs ist auch wie sie ueber die zeit hin wachsen, ein totales design disaster bei smime:( frag mal die die versuchen solche grossen PKIs zu fahren, vor allem muss man die dann ja untereinander abgleichen. die reinste freude...

fk6

fk6
Da gebe ich dir recht, aber aus meiner Sicht ist es ein Nachteil der sich zwingend aus der Designentscheidung ergibt, daß es keine zentrale Key-Datenbank gibt. Wenn eine zentrale Key-DB da ist, kann ich natürlich jederzeit nachprüfen, ob ein Key zurückgezogen wurde oder nicht. Nur habe ich dann den Nachteil einer zentralen DB.

fk6
Hm. Also das Zertifikat das in der Signatur in meiner Mail an dich enthalten ist, wurde von der CA mit deren privatem Key gegengezeichnet. Wenn mein MUA mit dem bekannten öffentlichen Schlüssel dieser CA die Signatur bestätigen kann, dann ist das Zertifikat per definition in Ordnung und wurde nicht gefälscht. Der einzige Knackpunkt den ich hier sehe ist der Satz an öffentlichen CA-Keys, derer sich dein MUA bedient: wenn der gefälscht ist, dann weden auch gefälschte Zertifkate als korrekt akzeptiert. Aber dazu brauchst du lokalen Zugriff auf den Empfänger-Rechner.

Oder habe ich einen Denkfehler drin?

Danke, fk6. Also hatte ich es soweit richtig verstanden.
Zentrale Server gibt es bei PGP/GPG auch, was natürlich in der Identitätsfrage nicht hilft.
GPG arbeitet übrigens an der S/MIME-Integration (Development Branch 1.9)

Ich rechne irgendwie damit, dass eine Software, die es bequem macht, bei den Usern gut ankommt, die nicht so paranoid sind wie ich. Und die damit das ganze System korrumpieren könnten. Und die, die paranoid genug sind, müssen sich ziemlich quälen. Dazwischen bleibt die große Zielgruppe für Ciphire und Kollegen…

Hilfe... eine Editierfunktion bitte

Also, nochmal langsam. Ich habe ein Zertifikat, das von der CA mit deren privatem Key signiert wurde. Das schicke ich beim Signieren einer Mail automatisch mit, der Empfänger besitzt die öffentlichen Schlüssel der CAs und kann nun die Signatur meines Zertifikates prüfen (und danach, wenn es weiß, daß mein Zert ok ist, kann es die Mail-Signatur prüfen). Um ein selbst generiertes Zertifikat echt erscheinen zu lassen, benötigt man den privaten Key der CA (den man höchstwahrscheinlich nicht hat) oder man muß dem Empfänger einen gefaketen öffentlichen Schlüssel unterschieben. Beides geht also nicht einfach dadurch, daß ich ein X.509 erstelle und selbst signiere, sondern da muß ich Zugriff auf den Rechner des Empfängers haben und den Satz der öffentlichen CA-Keys austauschen.

Rantanplan
Alles was ich brauche ist eine gewisse Zeit acess auf deinen Mail Verkehr, nur incoming. Ich gehe zu Thwate oder irgendjemandem anderen, mache mir ein kostenloses persoenliches Cert, hoffe mal dass die mir ne Challenge mail zuschicken(weiss nicht ob die das machen, wenn nein, ist es bescheuert). So da ich deinen Mailverkehr sehe fange ich diese Challenge Mail ab, sie erreicht dich nie und selbst wenn bist du verwirrt, siehst es als phishing scam an oder sonst was. Ich beantworte die challenge mail und verifiziere somit der CA gegenueber, dass ich Mails da erhalten kann.

Jetzt habe ich ein Cert fuer dich was valid ist.
Und du hast auch ein Cert fuer dich was valid ist.

Du schickst ne Mail an Bob.
Ich intercepte die mail und strippe sig und cert und fake alles mit meinem eigenen fuer dich erstellten cert.

Bob merkt das nie auch wenn er an dich replied und du auch nicht, weil wenn Bobs Mail bei mir vorbeikommt ich alles austausche und aus die Maus...

fk6

Ralf Vogt

Rein aus Interesse: benutzt du oder hast du mal S/MIME mit Apple Mail benutzt?

Falls nicht, dann probiere Ciphire, aber auch S/MIME aus. Mir würde aus dem Stand wenig einfallen, was man an der S/MIME-Integration von Mail noch verbessern könnte. Ich hätte gerne lieber eine Erweiterung des Schlüsselbundes, damit man dem sagen kann, daß X.509-Zerts in einem extra Schlüsselbund landen.

Du meinst damit, dass die User die das Web of Trust nicht verstehen und richtig benuetzen, es auch nicht benuetzen sollten. Ich gebe dir recht, vor allem weil es einen falsches Gefuehl der Sicherheit bringt. Das ist immer das schlimmste.

fk6

fk6
Achso, Identitätsklau, jetzt hab ich's Ja klar, wenn du meine Mails abfangen kannst, dann hast du schon einen Schritt gemacht. Allerdings - wie ihr auch - garantiert das System nur, daß du zu einer bestimmten Zeit Zugriff auf den Mailaccount hattest und keine Identität.

Das siehst du dem Zertifikat übrigens an, da es namenlos ist und nur die Mailadresse trägt. Erst wenn du dich mit Ausweis mehreren Leuten gegenüber legitimierst (nennt sich bei Thawte lustigerweise auch Web of Trust), wird mit dem Zertifikat auch deine Identität bestätigt. An so eines kommst du aber nicht durch Abfangen der Challenge-Mail, da Thawte die Zertifikate nicht per Mail verschickt, sondern du mußt dich einloggen und es herunterladen.

Was du also gewonnen hast ist ein Zertifikat das von Thawte gegengezeichnet wurde und auf meine Mailadresse ausgestellt ist. Wie sich ein MUA verhält, wenn er nun ein weiteres Zertifkat für die gleiche Adresse bekommt weiß ich nicht, aber nehmen wir mal an, daß er nix sagt. Dann könnte der Empfänger der Meinung sein, er würde mit mir mailen, richtig. Aber nur solange er sich das Zertifikat nie ansieht, denn dan würde er sehen, daß dort nicht mein Name drin steht.

Ok, nächster Schritt: Ausweise fälschen und bei Thawte die Identität bestätigen lassen, dann ist es nicht mehr unterscheidbar. Ok, das sind die Nachteile der nicht-zentralen PKI

Btw: ist euer System eigentlich gegen eine man-in-the-middle-Attacke beim Abfragen des Keys aus der DB sicher? Ich vermute schon, denn sonst könnte man auch jeden Schabernack damit treiben.

da ist es leider egal was du benuetzt zentral oder dezentral das problem bleibt immer, weswegen wir ne klare loesung vorgezogen haben und das nicht machen.

unterschied bei uns ist, dass es nicht moeglich ist zwei zertifikate zu selben zeit bei uns auf der infra zu haben, das geht nicht, das kann von aussen auch nachgeprueft werden. es gibt gegen uns attacken, aber es sind viel weniger als gegen die heute existierenden system. und wenn man dann den user als fehlerquelle noch eliminiert, wie wir das haben, dann hilft das hoffentlich auch nochmal.


fk6

fk6
Ok, das ist ein Vorteil der Notwendigkeit, daß der Empfänger-Key immer (vom 3-Tage-Cache mal abgesehen) von euer DB bezogen werden muß. Das ist eine von euch bewußt getroffene Design-Entscheidung, die - wie man sieht - Vorteile hat, aber eben auch Nachteile. Das wollte ich völlig wertfrei damit sagen.

Nachteile, die mir gerade so in den Sinn kommen:

- irgendein Datenaustausch zu euch findet beim Mailversenden immer an (ja, ich weiß, Cache), man muß Vertrauen haben, daß da nichts vertrauliches verschickt wird (wenn man schon paranoid ist )

- nach drei Tagen ohne Zugriff auf eure DB kann der Client keine verschlüsselte Mail mehr verschicken. Gibt er das eigentlich irgendwie bekannt?

- man ist abhängig von eurem Geschäftsmodell. Private Anwender müssen nichts bezahlen, klar, sonst würden die das System nie akzeptieren, aber ob das im Erfolgsfall auch so bleiben wird?

- man kann nicht einfach eine andere CA wählen, wenn einem die Preise oder das Geschäftsmodell nicht passen. Solange man Ciphire benutzt, ist man an euch gebunden.

fk6

Ach meinerseits vielen Dank für Deine ausführliche Stellungnahme, sowie auch natürlich an alle anderen Beteiligten, die ja mit ihren Beiträgen so eine erhellende (wenn auch nicht einfach zu verfolgende) Diskussion überhaupt erst ermöglichen.

Gerne gerne, hier noch ein paar Bemerkungen war ja noch nicht zu ende...;)

ich gebe dir hier recht, fuer total paranoide die uns nicht kennen und uns nicht vertrauen ist das nicht das richtige. die leute die am liebsten ihren eigenen tcp/ip stack schreiben damit sie wissen was aufm netzwerk passiert, fuer die sind wir nicht das richtige. wir sind zwar auch fuer die sicher, doch fuehlt sich das nicht richtig fuer die an und wird das auch nie. ich persoenlich wuerde in bestimmten faellen auch lieber stift und paper nehmen und one-timepad per hand machen, doch nehme ich dann lieber das flugzeug und treffe mich mit den leuten. und dann geht man mit denen spazieren, aber diese security requirements hat doch quasi keiner, ausser er redet sie sich ein, was auch ok ist:) jedem sein hobby;) wir wollten nur was in die welt stellen, was mum&dad benuetzen koennen. wenn es jemand besser kann, bitte her damit:)
es wird wohl schon davor schreien, wenn es unsere infra nichterreicht und es einen lookup machen muss, zb weil du nix fuer den recipient im cache hast, dann schreit es und fraegt was es tun soll, kann infra nicht erreichen weiss nicht und was nun. kan man relativ einfach ausprobieren, man blocke 3888,80,443 und gebe keinen proxy an, dann schreit es:) und wie es schreit;)

im erfolgsfall wird das 100% so bleiben, da bin ich jederzeit bereit einen Eid drauf zu leisten, das meine ich ernst. aber das wird keiner akzeptieren. hey ich hab ne idee. ne witzige idee. muss ich mit den RAs abklaeren:)

hat spass gemacht hier, gab wenigstens sachdiskussion und nicht religionskriege:)

btw wir sehen fuer smime, pgp und uns ideale einsatzfelder, jedem das seine....:)

Auch ich muss hier was beitragen: Eine Schritt-für-Schritt Anleitung wie man sich bei Thawte ein Zertifikat holt und das dann auch in OS X benutzt findet sich bei ApfelWiki:
<br>
<br>http://apfelwiki.de/wiki/Main/E-Mail-ZertifikateInMailVerwenden