Sichere Anwendung - OpenSource-Fähigkeit

[qwert_zuiopue]

Insbesondere da man schnell vergisst, dass es immer möglich ist, den Schlüssel zu knacken. Egal wie lange der Schlüssel ist.
Es gibt immer die Chance, das der erste eingegebene Schlüssel, der richtige sein kann.
Ist nur nicht sehr wahrscheinlich.

Das ist richtig. Aus diesem Grund werden veraltete Nachrichten automatisch gelöscht und von Zeit zu Zeit ein neuer Schlüssel erstellt . Dann hält sich der Schaden in Grenzen.

EDIT: Nach längerem Nachdenken über das Problem habe ich herausgefunden, dass es reicht, von wenigen sicherheitsrelevanten Modulen den Quelltext öffentlich zugänglich zu machen. Meiner Idee nach gibt es zwei Software-Module. Ein Modul, das den Download und Upload aus und zur Datenbank durchführt, und ein Modul, welches die Nachrichten entschlüsselt anzeigt. Nur in diesem Modul wird der private Schlüssel gebraucht und nur dieses muss somit öffentlich sein - ebenfalls enthalten ist der Teil, welcher die Schlüssel erzeugt.
Dass das Closed-Source-Modul keine Kenntnis vom privaten Schlüssel hat kann man dann leicht überprüfen, indem man den Pfad zum privaten Schlüssel ändert und sicherstellt, dass dieser Pfad niemals einer Instanz einer Klasse des Closed-Source-Moduls übergeben wird.
Passt das so oder hab ich irgendwo noch einen Denkfehler?

 

[Kiwi++Soft]

@asagk1963

Danke für diese sehr interessanten Ausführungen!

In der Tat habe ich mich schon ein bisschen mit dem Thema 'Verschlüsselung' beschäftigt, aber nur auf der 'Anwendungsseite' der Funktionen, die in den gängigen APIs (java.security, Bouncycastle) zur Verfügung gestellt werden.

Ich arbeite als Software-Entwickler und hatte daher schon Aufgaben zu erfüllen, in denen ich diese APIs nutzen musste:

• Speichern von Benutzer-Kennworten, so dass ein Administrator diese nicht lesen kann.
• Speicher von Kennworten zu Drittsystem, so dass die Maschine diese lesen kann, aber die Kennworte nicht in Klartext gespeichert sind.
• Speichern von Benutzer-Spezifischen Kennworten zu Drittsystemen, so dass ein Administrator diese nicht lesen kann, sondern diese nur verwendet werden können, wenn der entsprechende Nutzer angemeldet ist.
• Speichern von Client/Serverzertifikaten zur HTTPS/SSL/TLS Kommunikation mit Drittsystemen.
• Implementierung von AS1/AS2/AS3 Kommunikation mit Drittsystemen.

Dabei werden einem prinzipielle Grenzen klar, beispielsweise ist es immer so, dass ein Kennwort, dass die Maschine selbst entschlüsseln kann, niemals sicher gespeichert werden kann, denn die Maschine kennt den Schlüssel, und damit kann er gefunden werden. Ebenso ist klar, dass auch ein 'SecureRandom' nicht secure ist/sein kann.

Allerdings habe ich auch eine gewisse pragmatische Sicht auf die Dinge entwickeln müssen:

• Wenn wir mit Drittsystemen arbeiten, muss die von diesen Systemen verstandenen Kommunikations-Protokolle implementieren, und nicht mir Gedanken darüber machen, ob diese Protokolle sicher sind, oder wie man die Kommunikation sicherer machen können.
• Wenn wir Daten speichern, ist es zwar erstrebenswert, die 'derzeit üblichen Standards' einzuhalten, und bei der Implementierung dafür zu sorgen, dass diese so sorgfältig ist dass wir auch die entsprechenden Zertifizierungen bekommen. Das Entwickeln neuer Sicherheitsstandart ist aber weder das Ziel meines Arbeitgeber, noch das, was unsere Kunden von uns erwarten würden.

Daher habe ich auf beruflicher Seite weder den Auftrag, noch die Zeit, mich tiefer als die Nutzung der vorhandenen API's mit dem Thema zu beschäftigen.

Bereits solche Fragen, was mathematisch hinter einem Algorithmus wie RSA oder Diffie-Hellmann steckt, waren rein private Interessen von mir (Ich habe eine gewisse Vorliebe für Algebra und Zahlentheorie).

Letztendlich muss ich aber auch eines mal festhalten:

Die Tatsache, dass die NSA (und wahrscheinlich auch einige andere Geheimdienste) mich ausspioniert, ist lästig, mehr aber nicht. Mein Leben, mein Konto, das ist durchschnittlich. Wenn man mich von staatlicher Seite angreifen will, muss man dafür nicht meine elektronische Kommunikation entschlüsseln. Die Beträge meines Kontos sind für Geheimdienste uninteressant. Und wenn ich Opfer von 'Big-Data' werde (weil man nicht die Inhalte meiner Kommunikation sondern nur meine Kommunikations-Meta-Daten auswertet), kann ich durch bessere Verschlüsselung daran auch nichts ändern.

Und in einer E-Mail, oder einem Messenger würde ich ohnehin nichts schreiben, was ich nicht auch auf einer Postkarte schreiben würde. Nicht mal am Telefon sage ich irgendwas, was ich nicht bereit wäre öffentlich zu verlautbaren.

Beunruhigender finde ich da, dass ich nicht weiß (nicht wissen kann), ob die Zugangsdaten zu diversen Online-Shops, bei denen ich mein Spielzeug kaufe, oder ob die Zugangsdaten zu meinem Online-Banking sicher sind.

Dabei geht es übrigens keineswegs nur um Man-In-The-Middle Attacken, letztlich reicht es, wenn deren Server angegriffen werden, und die Zugangs Daten geklaut werden.

Erschreckend finde ich ebenfalls, wie wenig Aufwand es ist, ein von einer CA zertifiziertes X509 Zertifikat zu bekommen. Für den HTTPS-Server unserer Firma haben wir X509 Zertifikate, ebenso zum Zertifizieren unserer Software. Diese lassen wir uns Zertifizieren von einer in den gängigen Betriebssystemen als Root-CA eingetragenen Organisation. Die Überprüfung unserer Identität durch diese Organisation ist allerdings m.E. mangelhaft, das heißt, m.E. könnte sich jeder ein Zertifikat, das ihn als 'Wen-Auch-Immer' zertifiziert, auf diesem Wege besorgen. Und das reicht für eine 'Man-In-The-Middle' Attacke völlig, ganz ohne eine Kommunikation zu entschlüsseln.