OlbersD -
25.02.10 18:59
Immer wieder gibt es Vorschläge um E-Mail sicher zu machen wie die PGP, Elektronische Signatur oder De-Mail. Je größer der Presserummel um so idiotischer die Verfahren. Dabei ist es im Prinzip ganz einfach. Alles was an mathematischen (kryptografischen) Verfahren wirklich gebraucht wird, ist eine Funktion wie h(Message) = SHA-1(Message). Dieser Prüfwert (Hash) unterscheidet sich praktisch immer, wenn sich zwei Nachrichten (Message) unterscheiden. Damit lässt sich auch leicht eine Prüfwert
berechnen, der nur von berechtigten Personen ermittelt werden kann, weil zu Berechnung ein geheimer...
- An Secure Hash Algorithm – Wikipedia Twitter senden
- Mit Secure Hash Algorithm – Wikipedia Facebook empfehlen
Secure Hash Algorithm – Wikipedia
Ein total einfaches aber praktisch perfektes Verfahren ist:
Prüfwert gleich
function (Key, Message) = SHA1 (Key, SHA1(Message))
Es ist mit an Sicherheit grenzender Wahrscheinlichkeit auszuschließen, dass unterschiedliche Nachrichten den gleichen Prüfwert aufweisen, denn so genannte Kollisionen, unterschiedliche Nachrichten mit gleichem Prüfwert, konnten bis heute nie gefunden werden. Ebensowenig ist es möglich einen korrekten Prüfwert zu berechnen, ohne den Schlüssel (Key) zu kennen.
Weiterhin ist zu beachten, dass zur Berechnung des Prüfwert die Nachricht nicht bekannt sein muss. Es genügt den Wert sha1(Message) zu kennen. Eine Prüfung kann daher durch eine hinreichend vertrauswürdige Person/Insititution erfolgen, die aber keine Kenntnis der Nachricht haben muss.
So ungefähr könnte es laufen. Der Versender einer E-Mail berechnet von seiner Nachricht den Wert SHA1(Message) und den Prüfwert = SHA1(Key, SHA1(Message)). Den Prüfwert und eventuell den SHA1-Wert (könnte auch nur der Empfänger aus der Nachricht berechnen) überträgt er zusammen mit der Nachricht. Den Prüfwert reicht er bei einem Dienstleister (Trustcenter) ein, wobei der Dienstleister den Schlüssel Key kennt und den Prüfwert berechnen kann.
Zum Beispeil auf Nachfrage des Empfängers kann der Dienstleister die korrekte Berechnung des Prüfwerts bestätigen. Natürlich teilt er dem Empfänger nicht den Prüfwert mit, sondern bestätig nur, dass der Prüfwert, den er vom Empfänger der E-Mail erhält, stimmt, das heißt vom Sender verschickt wurde.
Es gibt übrigens keinen Mangel an geeigneten Hashs.
de.wikipedia.org
Ich habe mir das heute nochmal durchgelesen:
de.wikipedia.org
Es ist einfach nur zum Kopfschütteln, welch ein hirnloser Schwachsinn fast der gesamten Menschheit als Ausgeburt der Genialität verkauft werden kann.
In der Tat war dieses PGP und der ganze Quatsch mit den öffentlichen Schlüsseln in den 90-ern höchst populär. Aber nicht nur das, es wurde zum Beispiel in ganz Europa (EU) die Elektronische Signatur mit diesem Public-Key-Nonsense gesetzlich geregelt. Die Gesetze gibt es noch heute. Sie sind nichts als ein sinnloses bürokratisches Monster.
Warum ist der Public Key Nonsense? Ganz einfach, weil keiner wirklich wissen kann, wer den Private Key kennt.
Weil die 90-er ja schon eine Weile her sind ist vielleicht nicht allgemein bekannt, wie die Sache mit dem Public Key funktioniert. Also nochmal kurz, mit dem Public Key kann eine Signatur entschlüsselt werden, aber die Umkehrung davon funktioniert nur mit dem Gegenstück dem Private Key.
Aber was nützt uns das - im Grunde nichts! Denn wie gesagt woher weiß ich, dass eine Nachricht tatsächlich von Herrn Müller unterschrieben (elektronisch signiert) wurde?
Antwort: Ich kann dies nur wissen, wenn ich mir sicher bin, dass Herr Müller und niemand sonst den Private Key kennt. Aber wie soll ich dies wissen? Ja, da gab es diese Zerfikate, da stand drin der PK von Herrn Müller ist XYZ. Aber stimmt das Zertifikat wirklich? Also, die Zertifikate stellt ein so genanntes Trustcenter aus. Erst einmal muss sicher gestellt sein, dass diese nicht gefälscht werden können und das Trustcenter muss die Identität von Herrn Müller erst einmal prüfen, sich zum
Beispiel den Pass zeigen lassen und die Unterschrift vergleichen. In dieser Stelle wird schon klar, dass es da bestimmt keine 100-prozentige Sicherheit gibt.
Ganz wichtig ist die Erkenntnis, das Verfahren kann niemals funktionieren, wenn das Trustcenter nicht vertrauenswürdig ist. Ein kriminelles Trustcenter könnte statt nach Prüfung der Unterschrift ein Zertifikat auszustellen und Herrn Müller mit dem Private Key auszustatten, einfach ein Zerfikatat und den Private Key für Herrn Müller erstellen, obgleich ein Herr Müller niemals ein solches Zertifikat beantragt hat. Von dem Private Key könnte das Trustcenter dann beliebig viele Kopien erstellen,
an beliebige Leute verteilen und natürlich auch selbst zum fälschen von Unterschriften benutzen.
So, und spätestens an dieser Stelle wird klar, das Public-Key-Verfahren ist Nonsense. Ist das Trustcenter wirklich vertrauswürdig, könnte es ohne Weiteres auch eine Kopie des Private Key behalten. Dies ist nach dem Signaturgesetz zwar verboten, aber die Einhaltung dieser Vorschrift, kann gar nicht wirksam kontrolliert werden. Wie sollte jemand erkennen können, ob das Trustcenter nicht eine Kopie des Private Key behält, den es ja selbst erstellt und dem Kunden aushändigt?
Das Public-Key-Verfahren ist totaler Nonsense, weil vollkommen überflüssig. Statt ein Schlüsselpaar zu erzeugen, ein Zerfikat zu erzeugen, dieses öffentlich abrufbar zu machen und den Private Key dem Kunden, dessen Identität vorher geprüft wurde, zu übergeben, könnte auch einfach nur ein geheimer Schlüsselwert erzeugt werden von dem das Trustcenter eine Kopie behält.
Mit dem geheimen Schlüssel Key, könnte wie oben beschrieben nur der Kunde und das Trustcenter aus einer Nachricht einen Prüfwert berechnen. Das Trustcenter könnte also auf Anfrage die Echtheit des Prüfwerts bestätigen. Wenn der Kunde beim Erstellen einer Nachricht, den Prüfwert errechnet und beim Trustcenter einreicht, kann auch der Zeitpunkt der Erstellung bestätigt werden.
An dieser Stelle ist bereits klar, das PK-Verfahren ist keinesfalls besser als normale Verfahren nur mit geheimen, aber nicht mit öffentlich bekannten Schlüsseln. Aber die PK-Verfahren leisten selbst seitens der hoch gepriesenen Algorithmen nicht was sie versprachen. PGP wie es Anfang der 90-ern vermarket wurde, ist vollständig geknackt. Es gibt heute längst Verfahren, um das angeblich völlig Unmögliche leisten, nämlich den geheimen Priviate-Key aus dem öffentlichen PK oder den Zertifikaten
in kurzer Zeit zu berechnen. Dies ist heute schon innerhalb von Stunden möglich. Dies gilt zwar nicht bei längeren Schlüsseln, aber mit den damals empfohlenen Schlüssellängen und RSA ist dies kein Problem mehr. Aber bei keiner Schlüssellänge würde wohl jemand viel darauf wetten, dass sie nicht geknackt werden können.
Hieraus ergibt sich sofort: Damals mit PGP geleistete Unterschriften haben heute keinerlei Beweiskraft mehr. Aus den öffentlichen Schlüsseln, die ja zur Prüfung notwenig sind, kann auch der geheime Schlüssel berechnet werden. Mit dem geheimen Schlüssel kann dann eine Unterschrift für ein rückdatiertes Dokument gefälscht werden. Die Echtheit der PGP-Signatur kann also faktisch nicht mehr geprüft werden.
Selbst die mit großem Tam-Tam, teilweise noch bis heute, vermarkete Hashfunktion MD5, die PGP verwendete, hält nicht was sie verspricht. Es wurden nämlich "Kollisionen" gefunden, das heißt, unterschiedliche Nachrichten mit gleichem MD5-Wert, während für SHA-1 solche Kollisionen, allen Unkenrufen zum Trotz, bis heute nicht bekannt sind.
Allerdings ist dieser Fehler von MD5 von eher akademischer Bedeutung. Ein Betrüger könnte theoretisch einen Vertrag konstruieren, mit für ihn günstigeren Bedingungen, der den gleichen MD5-Wert aufweist wie ein von ihm signierter Vertrag, Dass er sich damit tatsächlich einen Vorteil erschleichen könnte, erscheint eher fraglich. Natürlich genügt es nicht irgendwelche zwei unsinnigen Zeichenfolgen zu produzieren, die zufällig den gleichen MD5 haben. Allerdings könnte es eventuell gelingen
einen gefälschten Vertrag zu konstruieren, wenn ein Teil der Nachricht verändert wird, der den Sinn des Vertrags nicht verändert. Der Betrüger hat aber das Problem, dass solche Kollisionen mit an Sicherheit grenzender Wahrscheinlichkeit nicht rein zufällig entstehen. Mindestens ein Vertrag wurde also offenkundig in betrügerischer Absicht manipuliert.
Trotzdem erscheint es nicht sinnvoll, den kaputten MD5, statt einer Vielzahl von vergleichbaren Algorithmen (SHA-1 zum Beispiel) zu verwenden, wo nach heutigem Stand keine Kollisionen gefunden werden können. Dennoch bleibt es richtig, Kollisionen sind keine unmittelbare Bedrohung für die Sicherheit des Verfahrens.
Aber eines ist klar, PGP in seiner Ursprungsfassung, die angeblich sogar gegen Geheimdienste gehärtet sein sollte, ist restlos kaputt. Vor allem das PK-Verfahren (RSA) ist mit den damals empfohlenen Schlüssellängen leicht zu knacken und damit können geheime Botschaften entschlüsselt und Signaturen gefälscht werden, ein absoluter Totalschaden!
Ich sehe da gerade so eine schwachsinnige Werbung für Massensignaturen. Daher nochmal der Hinweis. Ein SHA-1-Wert hat 160 Bit, 20 Bytes oder 40 hexadezimale Zeichen, fast jeder Computer, nicht nur große Server, kann locker ein paar Milliarden Signaturen speichern und auch so viele Signaturen pro Tag ausrechnen. Die Signaturen können auch leicht auf einigen DVDs archiviert werden, eventuell auch einige Sicherheitskopien. Die Speicher und Rechenkapazitäten sind also weit mehr als ausreichend.
Im Grunde albern darüber viele Worte zu verlieren. Die Kosten für einen Signaturservice müssen also nicht hoch sein.
Noch einmal zur Verschlüsselung. Das One-Time-Pad ist hunderprozentig sicher. Wird der einmalige Schlüssel mit einem Pseudo-Zufallsgenerator erzeugt, gilt dies faktisch ebenenso. Mit SHA-1 oder jeder anderen Hashfunktion, die (nach heutigem Stand) kollisionsresistent ist, ist der PRNG leicht zu realisieren:
next random bytes = h ( f (One-Time-Password, counter) )
counter = counter + 1
Aus SHA-1(Message) kann die Nachricht (Message) praktisch nicht berechnet werden. Dies ist in der Fachwelt eigentlich unumstritten. Aus h(f(One-Time-Password, counter)) lässt sich daher der Schlüssel (One-Time-Password) nicht ermitteln. Die Zufallsfolge wird sich praktisch auch nie wiederholen, weil sonst auch Kollisionen berechnet werden könnten.
f sollte eine praktisch kollisionsfreie Funktion sein, für unterschiedliche Argumnete also (praktisch) immer verschiede Werte ergeben. f = SHA-1 oder sonst eine kollisionsresistente Hashfunktion wäre auch denkbar. Die Funktion f könnte auch als irgend eine eindeutig umkehrbare Funktion gewählt werden, insbesondere auch als Identität und somit also weggelassen werden.
Aber selbstverständlich muss es nicht SHA-1 sein, es gibt auch RIPEMD-160 und weitere Hashfunktionen lassen sich leicht aus diesen gewinnen, die keinesfalls schlechter sind.
1. Verkettung
h' (Message) = h( h(Message) )
hn (Message) = h(h(h( ... h(Message) ... )))
2. Konstante Nachricht hinzufügen
h' (Message) = h ( 'XXX' || Message )
oder
h' (Message) = h ( Message || 'XXX')
oder
h' (Message) = h ( 'XXX' || Message || 'XXX')
Diese beiden grundlegenden Methoden neue Hashfunktionen können natürlich auch beliebig kombiniert werden
h' = SHA-1('XXX' , RIPEMD-160('YYY' || Message ))
Es ist also nicht notwendig, und daher auch wenig sinnvoll, dass immer das gleiche, öffentlich bekannt gegebenes Verfahren benutzt wird. Die Geheimhaltung des Verfahrens ist für seine Sicherheit zwar nicht erforderlich, aber die Geheimhaltung erhöht den Grad der Sicherheit weiter.