Problem:
Die Banken möchten ein nur für sie ausnützbares Backdoor in ihre hauseigenen eingesetzte SSL-Library einbauen, die TLS-1.3-konform ist, und sich damit zu "unzuverlässigen und nicht vertrauenswürdigen" Endpunkten machen. Warum auch nicht, bei "Sofortüberweisung" und wüsten Zocker-Spekulationen mit großem Potential, die globale Wirtschaft zu versenken, machen sie ja auch alle mit.
Lösung:
Standard-Schwächung der Kryptographie durch einen deterministischen mittels shared Secret gesicherten Pseudozufallsgenerator ohne geheime Entropie.
Dieses bleibt gegenüber allen, die das shared secret nicht kennen, sicher. Das Problem des Mitlauschens durch Herausgabe der shared Secrets ist gegeben; auch kann diese Schwächung durch einen NSL erzwungen werden. Das ist aber grundsätzlich ein Problem, und nur durch E2E-Encryption zu lösen, bei denen die Algorithmen auf beiden Seiten in den Händen der Nutzer sind.
Es gibt keine Lösung dafür, dass eine Seite nicht vertrauenswürdig ist. Kryptographie kann nur die Kommunikation zwischen zwei vertrauenswürdigen Seiten absichern.
Die Implementierung ist relativ trivial: Statt das Secret für den ephemeral Key esk als
esk=echt_guter_rng();zu generieren, macht man das z.B. über
esk=echt_guter_hash({psk, ip, port, millisecondsofepoch});oder
esk=echt_gute_block_verschlüsselung(key=psk, block={ ip, port, millisecondsofepoch, padding });psk, ip, port und millisecondsofepoch (+-n für kleine n) sind der Logging-Appliance bekannt, damit ist das esk mit wenig Aufwand errechenbar, auch gern nachträglich.
Es gibt gegen eine solche Verschlimmbesserung einer Implementierung keinen Schutz, außer das Audit der Implementierung. Und selbst das lässt oft zu wünschen übrig, wie man am PRNG von Debian-SSL gesehen hat. Dieser Angriff auf exzellente Verfahren ist immer möglich. Er muss nicht in einem Standard festgeschrieben werden.
Das Posting wurde vom Benutzer editiert (21.07.2017 14:02).