Neues Datenleak 01/2019: Adressen prüfen oder nicht?

[uname]

Man sollte auf jeden Fall die im Moment als 100% geltende Lösung suchen.

Daher sind unverschlüsselte E-Mail so erfolgreich. Die 100%-Lösung wurde auch da noch nicht gefunden.

@Meillo @MSfree
Zu EC-Karten habe ich folgendes gefunden. Der Standard ist scheinbar von 2011:
https://www.emvco.com/terms-of-use/?u=/ ... 923900.pdf

[MSfree]

Daher sind unverschlüsselte E-Mail so erfolgreich.

Unverschlüsselt Email ist so erfolgreich, weil es funktioniert.

Wenn du einen sinnvollen Vorschlag machen kannst, wie man Email einfach verschlüsseln kann, dann nur raus damit. Transportverschlüsselung gibt es bereits flächendeckend. Und für End-to-End brauchst du immer eine Public-Private-Key Infrastuktur und die wird von einer deutlichen Mehrheit, die weit über 90% liegt, als kompliziert empfunden, hat sich daher auch nie durchsetzen können. Ich selbst nutze auch keine Mail-Verschlüsselung, ich habe das nie eingerichtet, weil es schlicht sinnlos ist. Da kann man sich auch gleich komplett von Email verabschieden. Ich kenne keinen einzigen, dem ich verschlüsselte Mails schicken könnte und mir werden auch nur unverschlüsselte Mails geschickt, nach einem öffentlichen Schlüssel zwecks Mailverschlüsselung hat mich auch nich nie jemand gefragt. Folglich wird das nichts.

Auch hier, es könnte so einfach sein. Seit mehr als einem Jahrzehnt wird über die Killeranwendung des E-Personalausweises gesucht. Als Speicher für private Keys wäre der geradezu ideal und supereinfach in der Anwendung (NFC läßt grüßen) und vor allem, jeder hat so eine Plastikkarte.

Aber will man wirklich eine staatlich kontrollierte Infrastruktur?

[uname]

Bei E-Mail könnte man verschlüsselte Dateianhänge verwenden. Ob die Personalausweise per NFC mit Android und iOS funktionieren weiß ich nicht. Nur da der Anwender Smartphones als unsicher ansieht ist der Sicherheitsvorteil aus Anwendersicht auch eher gering. Und einen Leser für den Ausweis-PC will niemand kaufen oder rumschleppen. Keine 100% Sicherheit und daher bleibt alles beim alten.

[MSfree]

Ob die Personalausweise per NFC mit Android und iOS funktionieren weiß ich nicht

Mit einer entsprechend programmierten App(clication) wäre das kein Problem.

Ich sehe in einer Public-Private-Key Infrastruktur aber noch ganz andere Probleme. Im Grunde genommen sind diese Keys auch nicht mehr wert als Paßwörter, nur daß sie in einer Datei stecken und länger als Paßwörter sind. Daraus ergibt sich aber die selbe Problematik mit den Keys wie bei Paßwörtern, Ist der private Key erst kompromitiert, mußt du ihn ändern, mit allen damit verbundenen Konsequenzen:

So mußt du z.B. alle auf deinem Rechner bzw. Server befindlichen verschlüsselten Mails mit dem alten Key entschlüsseln und entweder mit dem neuen Key wieder verschlüsseln oder unverschlüsselt abspeichern.

Du müßtest beim E-Perso den neuen Key eintragen lassen, weil man ja nicht selbst auf den Perso schreiben darf.

Du brauchst wie bei Paßwörtern einen Schlüssel pro Anwendungszweck.

Wie gesagt, das ist alles für den Normalanwender gar nicht mal zu kompliziert, aber es ist zu aufwendig und der Aufwand wird gescheut. Dummerweise kann es dafür aber keine einfachere Lösung geben.

[Meillo]

Ich sehe in einer Public-Private-Key Infrastruktur aber noch ganz andere Probleme. Im Grunde genommen sind diese Keys auch nicht mehr wert als Paßwörter, nur daß sie in einer Datei stecken und länger als Paßwörter sind.

Sie unterscheiden sich in der Art, dass das Geheimnis nie uebertragen werden muss, sondern man macht die Pruefung per Challenge-Response-Verfahren. Das ist ein entscheidender Vorteil.

Ausserdem sind sie asymetrisch, was Verschluesselung und Signierung zulaesst, ohne dass die Gegenstelle dein Geheimnis kennt. Mit Passwoertern geht das nicht.

Daraus ergibt sich aber die selbe Problematik mit den Keys wie bei Paßwörtern, Ist der private Key erst kompromitiert, mußt du ihn ändern, mit allen damit verbundenen Konsequenzen:

[...]

Du brauchst wie bei Paßwörtern einen Schlüssel pro Anwendungszweck.

Das ist korrekt, aber man kann Schluesselhierarchien aufbauen, bei denen dann nur Teile tiefer Ebenen kompromitiert sind, die hoeheren Ebenen aber nicht in Mitleidenschaft gezogen werden. Per Web-of-Trust kann man Vertrauen vererben. Diese Moeglichkeiten hat man mit Passwoertern gar nicht.

Wie gesagt, das ist alles für den Normalanwender gar nicht mal zu kompliziert, aber es ist zu aufwendig und der Aufwand wird gescheut. Dummerweise kann es dafür aber keine einfachere Lösung geben.

Du sagst es: Es *kann* keine einfachere Loesung geben. Alles was einfacher ist ist keine Loesung.

[novalix]

Wie gesagt, das ist alles für den Normalanwender gar nicht mal zu kompliziert, aber es ist zu aufwendig und der Aufwand wird gescheut. Dummerweise kann es dafür aber keine einfachere Lösung geben.

Du sagst es: Es *kann* keine einfachere Loesung geben. Alles was einfacher ist ist keine Loesung.

Man kann das Handling von Schlüsseln durchaus etwas einfacher gestalten, bzw. mehr in die eingeübte Praxis integrieren.
Vor ein paar Jahren bin ich mal auf einen Maildienst aufmerksam gemacht worden, der "einfache Verschlüsselung" für Outlook-Benutzer anbot. (Weiß nicht mehr, wie die hießen. Saßen in Hannover, iirc.)
Das war vom Workflow her kaum eine Umstellung für die User. Das Problem dabei war, der private Schlüssel lag auf deren Server ::sich-vor-die-Stirn-klatsch-Smilie::

Besser macht das turtl (allerdings nicht im Bereich Email). Hier wird im Client auf Grundlage handelsüblicher Credentials (Username und Passwort) ein Schlüsselpaar erstellt und benutzt. Der User macht also das, was er sonst auch immer macht, unter der Haube wird aber fleißig verschlüsselt und zwar im Client. Man kann dann innerhalb des Systems auch weitere, abgeleitete PubKeys erzeugen (wiederum repräsentiert durch ein Nutzername-Passwort-Paar), um Inhalte zu teilen.

[Meillo]

Wie gesagt, das ist alles für den Normalanwender gar nicht mal zu kompliziert, aber es ist zu aufwendig und der Aufwand wird gescheut. Dummerweise kann es dafür aber keine einfachere Lösung geben.

Du sagst es: Es *kann* keine einfachere Loesung geben. Alles was einfacher ist ist keine Loesung.

Man kann das Handling von Schlüsseln durchaus etwas einfacher gestalten, bzw. mehr in die eingeübte Praxis integrieren.

Das meine ich mit der Unterscheidung von zufaelliger und essenzieller Komplexitaet. Die zufaellige Komplexitaet muss man schon reduzieren. Da ist noch viel Luft nach oben. Das sollte man tun. Man kann es aber nicht einfacher machen als die essenzielle Komplexitaet der Fachdomaene nun eben ist.


Beispielsweise kann man Autofahren einfacher machen indem man Automatik- statt Schaltgetriebe verwendet (zufaellige Komplexitaet), ebenso kann man wartungsaermere Elektroantriebe statt Verbrennungsmotoren verwenden (zufaellige Komplexitaet), aber man kann nicht die Verantwortung des Fahrzeugfuehrers loswerden (essenzielle Komplexitaet) man kann nicht die Interaktion mit anderen Verkehrsteilnehmern loswerden (essenzielle Komplexitaet). Man kann die Wegfindung z.B. mit Navis vereinfachen oder komplett auslagern (zufaellige Komplexitaet), aber man kann nicht die Angabe des Fahrziels auslagern (essenzielle Komplexitaet).

Fred Brooks' beschreibt das AFAIR in ``No Silver Bullet''. Diese explizite Sicht auf die zwei so unterschiedlichen Arten von Komplexitaet sollte viel mehr eingenommen werden.