Hybride Verschlüsselung - Public Key als Angriffsstelle?

[Milgo]

Hey Leute,

ich muss für ein zukünftiges Problem Daten verschlüsseln und suche aktuell nach der besten Möglichkeit diese umzusetzen.
Ich möchte die Daten eines Nutzers verschlüsselt zu meinem Server schicken und dort entschlüsseln. Mir scheint die hybride Verschlüsselung hier sinnvoll, ich verschlüssel also die Daten des Nutzers symmetrisch mit einem zufälligen Key, welcher asymmetrisch mit einem Public Key verschlüsselt wird.
Die verschlüsselten Daten sowie der verschlüsselte Key werden an den Server gesendet, welcher den Key und damit auch die Daten entschlüsseln kann.

Nun stellt sich mir die Frage, ob der Public Key in diesem Szenario nicht eine Schwachstelle sein kann. Wenn der Public Key statisch bleibt, hat ein Angreifer ja viel Zeit um mit Brute Force den Private Key zu finden und wenn er den einmal gefunden hat, kann der Angreifer alle Daten (falls er diese sniffen könnte) entschlüsseln, oder? Wenn ich den Public Key andererseits dynamisch ändere, muss dieser irgendwie (im Zweifelsfall über das Netz) angefordert werden, hier kann ein Angreifer ebenfalls versuchen dem Anwender seinen eigenen Public Key unterzujubeln, so dass er gesniffte Daten direkt entschlüsseln kann.

Ist meine Sorge unbegründet oder wie begegnet man diesem Problem (vielleicht den public Key über SSL ausliefern?)?

 

[kinglouy]

Sollte bei 2048 Bit Schlüssellänge (oder mehr) kein Grund zur Sorge bestehen. Den Public Key zu verschlüsseln macht wenig Sinn, der muss nicht geheim sein.

 

[=DarkEagle=]

http://www.heise.de/security/artikel/ENISA-Empfehlungen-zu-Krypto-Verfahren-2043356.html
"Auch herkömmliches RSA darf man noch benutzen; allerdings sollte man gemäß ENISA Systeme mit RSA-Schlüsseln unter 3072-Bit nur noch für Legacy-Systeme einsetzen; für mittelfristig gespeicherte Daten werden mindestens 3072 Bit und für langfristige Sicherheit sogar nur Systeme mit 15360-Bit-Schlüsseln empfohlen (das entspricht dann der Sicherheit von 256-Bit-Schlüsseln bei symmetrischen Verfahren). Damit unterscheiden sich die ENISA-Empfehlungen deutlich von denen des NIST, das den Einsatz von 2048-Bit-RSA-Schlüsseln bis zum Jahr 2030 als akzeptabel klassifiziert [2]."

Wenn ein Angreifer genügend Ressourcen hat, um Dir einen 2048-bit oder 4096-bit RSA-Schlüssel anzugreifen, dann kannst Du Dich auch nicht auf SSL zu Verschlüsselung des PublicKeys verlassen, wenn das ein offizielles Zeritifkat und kein eigenes ist. Dann wird der Angreifer auch entsprechend einen Weg haben, dein SSL-Zertifkat zu fälschen und eine Maninthemiddle-Attacke durchzuführen. Da ich mal denke, dass da keine Staatsgeheimnisse übertragen werden, nimm 4096-bit und gut ist.

 

[tiash]

Überlege dir gut, wie wichtig das Problem ist und ob du dir wirklich zutrauen möchtest, es eigenständig umzusetzen. Gibt es eventuell fertige Verfahren / Software, die deine Problemstellung behandelt? Kryptographie ist ein schwieriges Feld, da scheitert es dann im Zweifelsfall nicht daran, dass du einen unsicheren Verschlüsselungsalgorithmus ausgewählt hast sondern an so Dingen wie fehlendem / fehlerhaftem Padding, Seitenkanälen durch Timing der Operationen, oder noch ganz anderen obskuren Dingen.

Grundsätzlich sind Public Key Verfahren darauf ausgelegt, dass der öffentliche Schlüssel lange Zeit bekannt bleibt. Bei ausreichender Bitlänge, Anmerkungen dazu hast du oben bekommen, reicht die verbleibende Zeit bevor die Sonne eines fernen Tages erlischt nicht aus, um den privaten Schlüssel zu raten.


Edit: Guter Stil wäre nichts desto trotz ein Verfahren mit Perfect Forward Secrecy. Dabei tauschen Client und Server lnformationen zur Schlüsselerzeugung aus, ohne dass der komplette Schlüssel jemals über das Netzwerk ging. Ein Angreifer, der den Netzwerkverkehr mitschneidet UND den Public Key des Servers kompromittiert kann dann trotzdem nicht alte Nachrichten entschlüsseln.
Ein weiterer Vorteil: der Server muss sich nicht darauf verlassen, dass der Client gute symmetrische Schlüssel bildet, weil beide Seiten frisches Material in den Schlüssel einbringen.