Hallo, Möchte man die Integrität von Daten überprüfen und eine absichtliche Manipulation sicher erkennen, so muss den Nutzdaten eine kryptografisch sichere Prüfsumme angehängt werden ein Message Authentication Code (MAC). Würde man eine gewöhnliche lineare CRC-Prüfsumme mitsenden, könnte jeder die Nutzdaten manipulieren und selbst wider eine korrekte Prüfsumme anhängen. Soweit ist mir klar, warum eine CRC-Prüfsumme kryptografisch nicht sicher ist. Nun stelle ich mir aber die Frage, was passiert, wenn die Daten zusätzlich verschlüsselt werden? Angenommen man berechnet eine gewöhnliche CRC-Prüfsumme vom Klartext, hängt diese dem Klartext an und chiffriert dann den erhaltenen Datensatz. Ein Angreifer sieht so weder die Prüfsumme, noch kann er die Daten so verändern, dass beim Empfänger nach dem Dechiffrieren die Prüfsumme korrekt ist. Im Prinzip würde es genügen, die CRC-Prüfsumme vom Klartext zu berechnen, die Nutzdaten zu chiffrieren und an den Chiffretext die vorher berechnete Prüfsumme anzuhängen. Auch so sollte es einem Angreifer nicht möglich sein, die chiffrierten Daten zu ändern und eine korrekte neue Prüfsumme zu generieren, da die Prüfsumme ja vom Klartext und nicht vom Chiffretext berechnet wurde. Ist eine derartige Nutzung der CRC-Prüfsumme dennoch nicht kryptografisch sicher, wenn ja warum? Besten Dank im Voraus, Roland.
Roland schrieb: > Möchte man die Integrität von Daten überprüfen und eine absichtliche > Manipulation sicher erkennen, so muss den Nutzdaten eine kryptografisch > sichere Prüfsumme angehängt werden ein Message Authentication Code > (MAC). Och, ich mach das immer so, dass ich die Daten manipuliere, und eine neue dazu passende MAC anhänge. :P
Roland schrieb: > Ist eine derartige Nutzung der CRC-Prüfsumme dennoch nicht > kryptografisch sicher, wenn ja warum? verschlüsselte Daten zu ändern ist ja kein Problem, das kann man einfach so machen, nur weiß man halt nicht was wirklich rauskommt. Da die CRC meist recht kurz ist, kann man Angreifer einfach probieren. Irgendwann wird es eventuell mal stimmen. Wenn man noch mit CBC (o. ä.) arbeitet wird es recht sicher. Aber man hat immer noch nicht den Vorteil einer echten Signatur, das man weis von wem die Nachricht ist.
Und erklär mal was DU under einer kryptografisch sicheren CRC-Prüfsumme verstehst. CRC-Prüfsummen sind nur eine kleine Untermenge der Prüfsummen.
Detlef Kunz schrieb: > Und erklär mal was DU under einer kryptografisch sicheren > CRC-Prüfsumme verstehst. > CRC-Prüfsummen sind nur eine kleine Untermenge der Prüfsummen. steht sogar im wiki [...] Obwohl eine herkömmliche Prüfsumme nützlich ist, um vor unbeabsichtigten Änderungen zu schützen, bietet sie keine Sicherheit gegenüber beabsichtigen Datenänderungen (Manipulation), da sie trivial zu umgehen ist. Es ist deshalb oft notwendig, anstelle eines einfachen Prüfsummenverfahrens kryptografisch stärkere Algorithmen, wie Einweg-Hash-Funktionen (z. B. den Secure Hash Algorithm), zu verwenden. Diese stellen weiterhin die Grundlage elektronischer Unterschriften dar. [...]
Warum dann überhaupt noch die Prüfsumme? Die Frage ist, was willst du erreichen? Eine kryptografische Prüfsumme erfüllt diverse Eigenschaften, aber die Sicherheit hängt auch von der Nutzung ab. Wenn du den gesamten Text sowieso verschlüsseln willst ist die Prüfsumme (ob nun ebenfalls verschlüsselt oder nicht) auch egal. Hängt die CRC einfach unverschlüselt hinten drann, so kann man eben einen Text erzeugen welcher für diese CRC gültig ist. Darum gehts ja. Bei einer krypt. Hashfunktion wäre das nicht möglich. Aber was bringt es? Der Empfänger möchte decodieren und sieht nur Müll. Du solltest also erstmal definieren was du willst. Was willst du schützen? Signatur mittels Hashfunktion macht ja nur Sinn, wenn man den eigentlichen Text unverschlüsselt überträgt und nur den Hashwert mit dem privaten Schlüssel des Absenders verschlüsselt (Signiert). Ist der Text sowieso verschlüsselt fällt die Notwendigkeit dafür meist weg.
Roland schrieb: > Ist eine derartige Nutzung der CRC-Prüfsumme dennoch nicht > kryptografisch sicher, wenn ja warum? Sicher ja aber kryptografisch unsinnig. Ist Deine Verschlüsselung "sicher", dann muss der Klartext nicht mehr gegen beabsichtigte Manipulation gesichert werden. Ist Deine Verschlüsselung nicht sicher, dann kann ein Angreifer die Nachricht entschlüsseln -> ändern -> neue Prüfsumme berechnen -> verschlüsseln -> weiterleiten. Bezüglich der Datenintegrität (Bitfehler) hättest Du prinzipiell recht. Aber dann musst Du auch sicherstellen, dass die beschädigte, verschlüsselte Nachricht (die ja den Fehler hätte) immer noch korrekt entschlüsselt werden kann. Hth Grüße Andreas
cyblord ---- schrieb: > Wenn du den gesamten Text sowieso verschlüsseln willst ist die Prüfsumme > (ob nun ebenfalls verschlüsselt oder nicht) auch egal wie kommst du darauf? eine nur weil man den Text nicht lesen kann, kann man die Nachricht genauso Manipulieren (nur sieht man nicht was rauskommt) Eine Prüfsumme braucht man auch bei Verschlüsselung!
Andreas H. schrieb: > Ist Deine Verschlüsselung "sicher", dann muss der Klartext nicht mehr > gegen beabsichtigte Manipulation gesichert werden. doch muss er. Woher soll man denn sonst erkennen das nicht geändert wurden ist?
Peter II schrieb: > cyblord ---- schrieb: >> Wenn du den gesamten Text sowieso verschlüsseln willst ist die Prüfsumme >> (ob nun ebenfalls verschlüsselt oder nicht) auch egal > > wie kommst du darauf? eine nur weil man den Text nicht lesen kann, kann > man die Nachricht genauso Manipulieren (nur sieht man nicht was > rauskommt) > > Eine Prüfsumme braucht man auch bei Verschlüsselung! Ich sagte auch nicht dass man sie nicht braucht, sondern dass es egal ist ob verschlüsselt oder nicht. Lern lesen Bub. Für die Datenintegrität mag man sie brauchen, für die Sicherheit gegen Manipulation nicht. Weil das verschlüsseln des Textes hierfür bereits ausreicht. > doch muss er. Woher soll man denn sonst erkennen das nicht geändert > wurden ist? Weil nur Müll beim dekodieren rauskommt. Daran erkennt man es. Eine sinnvolle Veränderung kann ein Angreifer nicht durchführen wenn verschlüsselt.
:
Bearbeitet durch User
Andreas H. schrieb: > Bezüglich der Datenintegrität (Bitfehler) hättest Du prinzipiell recht. > Aber dann musst Du auch sicherstellen, dass die beschädigte, > verschlüsselte Nachricht (die ja den Fehler hätte) immer noch korrekt > entschlüsselt werden kann. Wie würde ich diese Korrektheit ohne Prüfsumme erkennen? Nach meinem Verständniss wird ab dem Bitfehler Müll dekodiert und die Hoffnung besteht, dass dann die Müll-Checksumme nicht zufällig richtig ist.
cyblord ---- schrieb: > Weil das verschlüsseln des Textes hierfür bereits > ausreicht. Welcher Text ist nun richtig: "Anzahl der Angreifer: 10" oder "Anzahl der Angreifer: 99" >> doch muss er. Woher soll man denn sonst erkennen das nicht geändert >> wurden ist? > Weil nur Müll beim dekodieren rauskommt. dann ändere Doch einfach mal das letzte Zeichen einer Verschlüsslung, diese hat nur Auswirkung auf das ende von Text. Damit muss man die Manipulation nicht immer erkennen. > Daran erkennt man es. Eine > sinnvolle Veränderung kann ein Angreifer nicht durchführen wenn > verschlüsselt. doch kann er.
cyblord ---- schrieb: > Weil das verschlüsseln des Textes hierfür bereits > ausreicht. Hier noch ein extrem Beispiel: verschlüssle doch mal eine Binäre Zahl. (also 4byte) Dann manipuliere die Verschlüsselten Daten, und du wirst sehen das immer irgendeine Zahl rauskomme. Wie willst du jetzt erkennen welche die "echte" ist?
Peter II schrieb: > "Anzahl der Angreifer: 10" > oder > "Anzahl der Angreifer: 99" >> Daran erkennt man es. Eine >> sinnvolle Veränderung kann ein Angreifer nicht durchführen wenn >> verschlüsselt. > doch kann er. Dann erklär mal wie du aus der "10" eine "99" machst wenn der Text verschlüsselt ist und du den Schlüssel nicht kennst. Ein Angreifer kann den Text nur kürzen oder verstümmeln. Ja.
cyblord ---- schrieb: > Dann erklär mal wie du aus der "10" eine "99" machst wenn der Text > verschlüsselt ist und du den Schlüssel nicht kennst. mit einen Editor. Der punkt ist, das es nicht sicher ist. Wenn ich 10.000 Verssuche habe dann schaffe ich das. Nur weil es etwas schwerer ist, sollte man sich nicht darauf verlassen.
Peter II schrieb: > cyblord ---- schrieb: >> Dann erklär mal wie du aus der "10" eine "99" machst wenn der Text >> verschlüsselt ist und du den Schlüssel nicht kennst. > > mit einen Editor. Der punkt ist, das es nicht sicher ist. Wenn ich > 10.000 Verssuche habe dann schaffe ich das. Nur weil es etwas schwerer > ist, sollte man sich nicht darauf verlassen. Humbug. Dann könntest du genauso gut den Text so manipulieren dass die krypt. Hashsumme wieder passt und die Veränderung nicht aufällt. Das ist genauso schwer wie das manipulieren des verschlüsselten Textes. Beides ist "computationally infeasible" und damit sicher. Für trival kleine Klartexte ist jede Verschlüsselung angreifbar.
Vielen Dank für die zahlreichen Antworten! Es ist klar, dass bei beabsichtigter Manipulation oder bei Übertragungsfehlern nach dem Entschlüsseln der Klartext komplett fehlerhaft ist, allerdings muss dieser Umstand ja auch erst irgendwie erkannt werden. cyblord ---- schrieb: > Wenn du den gesamten Text sowieso verschlüsseln willst ist die Prüfsumme > (ob nun ebenfalls verschlüsselt oder nicht) auch egal. Hängt die CRC > einfach unverschlüselt hinten drann, so kann man eben einen Text > erzeugen welcher für diese CRC gültig ist. Darum gehts ja. Bei einer > krypt. Hashfunktion wäre das nicht möglich. Ja, man kann einen beliebigen Chiffretext erzeugen, der zur Prüfsumme passt. Aber die Prüfsumme wurde bei den echten Daten ja aus dem Klartext berechnet und die kennt der Angreifer nicht.
cyblord ---- schrieb: > Humbug. dann sag doch mal wie du an 4byte die eine Zahl darstellen, erkennen willst das sie manipuliert ist? 0x12345678 oder 0x04737432 welche Zahl wurde verändert?
Roland schrieb: > Ja, man kann einen beliebigen Chiffretext erzeugen, der zur Prüfsumme > passt. Aber die Prüfsumme wurde bei den echten Daten ja aus dem Klartext > berechnet und die kennt der Angreifer nicht. Ja aber der Angreifer kann dir einen Datenblock unterjubeln für den du eine korrekte Prüfsumme berechnest. Die Frage ist, darf das sein oder nicht. Darum die Frage: Was willst du genau schützen? Um es mal kurz zu machen: Deine Idee, die CRC mit zu verschlüsseln ist in diesem Fall sicher am besten und sollte sicher sein.
Hier sind tonnenweise Papers zu dem Thema verlinkt: http://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac
Okay, verstehe. Im konkreten geht es darum, die Daten die zu einem Bootloader gesendet werden zu verschlüsseln. Hier spielt im Prinzip eine Absicherung gegen absichtliche Manipulation keine Rolle und es würde eine gewöhnliche angehängte CRC-Prüfsumme vom Chiffretext genügen. Ich habe nur eben schon öfters gelesen, dass für die Erkennung einer Manipulation ein MAC erforderlich ist, wobei mir eben nicht so klar wurde, ob das ausschließlich für unverschlüsselte Übertragung gilt, oder generell, da eben bei verschlüsselter Übertragung eine mitverschlüsselte CRC-Prüfsumme ebenso die Integrität der Daten sichern sollte.
Roland schrieb: > Ich habe nur eben schon öfters gelesen, dass für die Erkennung einer > Manipulation ein MAC erforderlich ist, Der Unterschied ist: eine simple Prüfsumme schützt vor zufälliger Datenveränderung durch Störungen auf dem Übertragungsweg, ein Angreifer kann jedoch nach erfolgter Manipulation einfach die Prüfsumme wieder passend hinbiegen, das andere (MAC oder Signatur) schützt zusätzlich auch vor absichtlichen (böswilligen) Veränderungen indem es jeglichen Versuch die Prüfsumme im Nachhinein gezielt wieder passend zu machen vereitelt. Am einfachsten machst Du es in Deinem Falle so daß Du eine ausreichend lange Prüfsumme an die Daten anhängst und dann erst verschlüsselst (Daten mitsamt Prüfsumme). Danach wird es unmöglich sein die Daten so zu verändern daß sie danach noch als gültig erkannt werden, weder versehentlich noch absichtlich, und schon gar nicht in irgendeiner sinnvollen [dem Angreifer nützlichen] Art und Weise.
:
Bearbeitet durch User
Bernd K. schrieb: > Am einfachsten machst Du es in Deinem Falle so daß Du eine ausreichend > lange Prüfsumme an die Daten anhängst und dann erst verschlüsselst > (Daten mitsamt Prüfsumme). Danach wird es unmöglich sein die Daten so > zu verändern daß sie danach noch als gültig erkannt werden, weder > versehentlich noch absichtlich, und schon gar nicht in irgendeiner > sinnvollen [dem Angreifer nützlichen] Art und Weise. Genau. Das war mein Plan. Ohne jetzt zu erörtern wie Sinnvoll es für diese Anwendung im Speziellen ist, inwiefern unterscheidet sich dieses Verfahren in punkto Manipulationssicherheit nun von einem MAC den man an die Verschlüsselten Daten anhängt (Berechnet anhand des Klartextes oder anhand des Chiffretextes. Oder den man zuerst berechnet und dann mitverschlüsselt)?
Bernd K. schrieb: > Am einfachsten machst Du es in Deinem Falle so daß Du eine ausreichend > lange Prüfsumme an die Daten anhängst und dann erst verschlüsselst > (Daten mitsamt Prüfsumme). Wenn es nur darum geht, den Urheber eindeutig zu identifizieren, ist es nicht erforderlich, die Daten zu verschlüsseln. Es reicht aus, den Hashcode zu verschlüsseln.
Roland schrieb: > inwiefern unterscheidet sich dieses > Verfahren in punkto Manipulationssicherheit nun von einem MAC Aus dem Bauch raus: kein Unterschied (bei gleicher Hash-Funktion und gleich langem Schlüssel). Bin aber kein Kryptograph und kanns auch nicht beweisen, also lieber noch mal ne zweite Meinung einholen.
A. K. schrieb: > Wenn es nur darum geht, den Urheber eindeutig zu identifizieren, ist es > nicht erforderlich, die Daten zu verschlüsseln. Wenn ichs richtig gelesen habe will er Firmware-Updates verschlüsseln (und manipulierte solche abweisen).
Roland schrieb: > inwiefern unterscheidet sich dieses > Verfahren in punkto Manipulationssicherheit nun von einem MAC den man an > die Verschlüsselten Daten anhängt Kryptografische Signaturen sind asymmetrische Verfahren. Der Hashcode wird mit den privaten Schlüssel verschlüsselt und dann zusammen mit den Daten übermitteln. Der öffentliche Schlüssel des Absenders entschlüsselt den Hashcode und erlaubt die Verifizierung der Daten. Da dem Empfnger nur der öffentliche Schlüssel bekannt ist, lässt sich aus der dem Empfänger bekannten Information kein Paket schnüren, dass dieser akzeptieren würde. Vereinfacht gesagt verwendet ein MAC hingegen ein symmetrisches Verfahren, grob vergleichbar zur DES oder AES Verschlüsselung, in dem beide Seiten den gleichen geheimen Schlüssel verwenden. Somit ist dem Empfänger der geheime Schlüssel bekannt. Dem Empfänger ist es also möglich, falsche Daten mit korrektem MAC zu erzeugen. Somit ist das Verfahren nur sicher, wenn der Empfänger seine Information geheim halten kann - im Fall vom Bootloader also dessen Code.
Kleiner Tipp. Da gibts ein Buch namens "Handbook of Applied Cryptography" da wird das alles erklärt. http://cacr.uwaterloo.ca/hac/ Aber falls irgendwie möglich, verwende eine Bibliothek. Es ist sehr wahrscheinlich, dass Du dumme Anfängerfehler machen wirst. Die macht leider so ziemlich jeder am Anfang.
Bernd K. schrieb: > Wenn ichs richtig gelesen habe will er Firmware-Updates verschlüsseln > (und manipulierte solche abweisen). Ich hatte es so verstanden, dass er manipulierte Firmware ablehnen will. Nicht aber, sie dass er die Binärdaten der Firmware geheim halten will. Andernfalls wäre die Diskussion über Prüfsummen oder MACs sinnlos. Es ist vom prinzipiellen Verfahren her irrelevant, ob es sich um Botschaften handelt, oder um Firmware für einen Bootloader. Der Bootloader ist schlicht der Empfänger einer Botschaft, die ihn auf unsicherem Weg erreicht. Soll hingegen die Firmware selbst geheim gehalten werden, dann läuft es ganz banal auf Verschlüsselung der Firmware hinaus, ob symmetrisch oder asymmetrisch.
:
Bearbeitet durch User
Roland schrieb: > Im konkreten geht es darum, die Daten die zu einem Bootloader gesendet > werden zu verschlüsseln. Hier spielt im Prinzip eine Absicherung gegen > absichtliche Manipulation keine Rolle und es würde eine gewöhnliche > angehängte CRC-Prüfsumme vom Chiffretext genügen. Das ist so ziemlich das Gegenteil der ursprünglichen Fragestellung. :-) > Ich habe nur eben schon öfters gelesen, dass für die Erkennung einer > Manipulation ein MAC erforderlich ist, MACs begegnet man m.E. dort, wo öffentliche Botschaften authentifiziert werden müssen. Nicht aber bei ohnehin geheimen Botschaften. Bei verschlüsselten Daten muss es nur möglich sein, eine korrekte Entschlüsselung zu erkennen. Dafür reicht es auch aus, in den Plaintext (Code) vorneweg "Dies ist meine geheime Firmware" zu schreiben und zu verifizieren.
:
Bearbeitet durch User
Bernd K. schrieb: > Aus dem Bauch raus: kein Unterschied (bei gleicher Hash-Funktion und > gleich langem Schlüssel). Bin aber kein Kryptograph und kanns auch nicht > beweisen, also lieber noch mal ne zweite Meinung einholen. Okay, danke. Ist klar das die Länge der Prüfsumme gleich sein muss, um überhaupt einen Vergleich anstellen zu können, stimmt. Christian Berger schrieb: > Aber falls irgendwie möglich, verwende eine Bibliothek. Es ist sehr > wahrscheinlich, dass Du dumme Anfängerfehler machen wirst. Die macht > leider so ziemlich jeder am Anfang. An welche Fehler denkst Du da zuerst? --- Also dienen MACs in erster Linie dazu, unverschlüsselte Nachrichten gegen Manipulation zu sichern und spiele bei Verschlüsselten Nachrichten eine untergeordnete Rolle? Ja, das hatte ich anfangs vor, einfach am Ende der Nachricht eine bekannte Identifikatiossequenz mitzusenden. Nur wenn die Daten weder Übertragungsfehler aufweisen noch manipuliert wurden können sie korrekt dechiffriert werden und die bekannte Kennung kann erkannt werden. Allerdings ist der verwendete Blockchiffremodus CBC ja selbstsynchronisierend, wodurch eine Identifikatiossequenz am Ende der Nachricht keine Auskunft über die Korrektheit der gesamten Nachricht liefert. Es müsste in jedem einzelnen Chiffreblock eine Identifikation eingepflügt werden, was die Redundanz merklich erhöht.
Roland schrieb: > Also dienen MACs in erster Linie dazu, unverschlüsselte Nachrichten > gegen Manipulation zu sichern Man kann zur Integritätskontrolle natürlich auch einen MAC verwenden. Bin grad einem CCM Modus begegnet, der das wohl elegant kombiniert. Ich frag mich freilich, wie weit du damit wirklich gehen willst. Immerhin unterscheiden sich kleinere Firmware-Updates üblicherweise nur wenig vom Vorgänger, was völlig andere Risiken mitbringt als in den sonst üblichen Einsatzbereichen von Kryptographie. Weshalb man sich dann lieber gleich mit echten Kryptologen zusammen setzen sollte. Wenn man es wirklich ernst meint.
:
Bearbeitet durch User
Sich mit einem Kryptologen darüber zu unterhalten, ist bestimmt die beste Option. Aufgrund Deiner Aussage, dass es bei verschlüsselten Daten genügt, zu erkennen ob die Entschlüsselung erfolgreich war, habe ich mir überlegt, ob eine Prüfsumme überhaupt nötig ist. Wenn man eine Blockchiffre im CBC-Modus betreibt, dann entspricht der letzte Chiffreblock ja dem MAC des Klartextes. Der Empfänger bekommt den chiffrierten Datenstrom und entschlüsselt diesen wider mit dem CBC-Modus. Nun weiß der Empfänger ja nicht, ob der Chiffretext Übertragungsfehler beinhaltet oder Manipuliert wurde, weshalb auch vom rekonstruierten Klartext nicht bekannt ist, ob dieser korrekt ist. Nun könnte der Empfänger aber selbst den eben erhaltenen Klartext selbst wider mittels CBC verschlüsseln, wovon der letzte Block ja wider der MAC des Klartextes ist. Vergleicht er nun den eben selbst berechneten letzten Chiffretextblock mit dem zuvor Empfangenen letzten Chiffretextblock, sollte ja nur dann kein Unterschied feststellbar sein, wenn der übertragene Chiffretext nicht geändert wurde. Wäre das ein gangbarer Weg um die Integrität der Daten festzustellen oder unzuverlässig?
Roland schrieb: > Im Prinzip würde es > genügen, die CRC-Prüfsumme vom Klartext zu berechnen, die Nutzdaten zu > chiffrieren und an den Chiffretext die vorher berechnete Prüfsumme > anzuhängen. Auch so sollte es einem Angreifer nicht möglich sein, die > chiffrierten Daten zu ändern und eine korrekte neue Prüfsumme zu > generieren, da die Prüfsumme ja vom Klartext und nicht vom Chiffretext > berechnet wurde. > > Ist eine derartige Nutzung der CRC-Prüfsumme dennoch nicht > kryptografisch sicher, wenn ja warum? Hallo. Ich denke, diese Variante ist nicht kryptografisch sicher. Ein Grundsatz in der Kryptografie ist es, einem Angreifer keine Informationen zu geben. In dem Fall hier wären die Prüfsummen des Klartextes vorhanden, was mir nicht gefallen würde, wenn ich es mit der Verschlüsselung ernst meine. Eine bessere Methode wäre es, zuerst zu verschlüsseln, und dann auf den verschlüsselten Text eine MAC wie zb SHA256 anzuwenden. Der umgekehrte Weg kann unter Umständen unsicher sein. Da bin ich aber auch nicht drin - man sieht, Kryptografie hat viele Tücken, an die ein Anfänger garantiert nicht denkt. Deswegen unbedingt mit einem Kryptologen sprechen, wenn es euch wirklich wichtig ist mit der Sicherheit. Gruß
Roland schrieb: > Aufgrund Deiner Aussage, dass es bei verschlüsselten Daten genügt, zu > erkennen ob die Entschlüsselung erfolgreich war, habe ich mir überlegt, > ob eine Prüfsumme überhaupt nötig ist. Wenn man eine Blockchiffre im > CBC-Modus betreibt, dann entspricht der letzte Chiffreblock ja dem MAC > des Klartextes. Der Empfänger bekommt den chiffrierten Datenstrom und > entschlüsselt diesen wider mit dem CBC-Modus. > Wäre das ein gangbarer Weg um die Integrität der Daten festzustellen > oder unzuverlässig? Das ist prinzipiell möglich und nennt sich CBC-MAC. Womit du dann doch eine Prüfsumme hast :-) Aber bitte bedenken, dass du dafür zwei Schlüssel brauchst. Einen für die Verschlüsselung der Blöcke, und abschließend einen, mit dem das Ergebnis "verschlüsselt" wird und dadurch zu deiner MAC wird.
Roland schrieb: > Christian Berger schrieb: >> Aber falls irgendwie möglich, verwende eine Bibliothek. Es ist sehr >> wahrscheinlich, dass Du dumme Anfängerfehler machen wirst. Die macht >> leider so ziemlich jeder am Anfang. > > An welche Fehler denkst Du da zuerst? Naja, also Du hast ja scheinbar die Idee, dass es eine Prüfsumme gibt, die man nicht nachrechnen kann. Die gibt es nicht. Du könntest jetzt zum Beispiel annehmen, dass es in Deiner Situation reicht, einfach eine gewöhnliche Prüfsumme zu nehmen, und dann einfach ein Geheimnis an Deine Daten dran zu hängen. Das kann, wenn Du das Geheimnis wirklich geheim halten kannst, ausreichen, aber nur wenn Du eine kryptographisch sichere Prüfsumme verwendest. Das sind Prüfsummen wie SHA-2. Und Du gehst davon aus, dass das Geheimnis wirklich geheim bleibt. Um wirklich zu wissen was Du brauchst musst Du Dein Problem genau untersuchen. Wenn Du zum Beispiel kein Geheimnis sicher bei Sender und Empfänger speichern kannst, brauchst Du zum Beispiel Public Key Kryptographie. Und die wird wirklich schwierig. Da musst Du dann mit sehr langen Zahlen rechnen, Du brauchst guten Zufall, und du wirst erleben, dass Dir Dein Compiler Schwierigkeiten macht. Ein typischer nicht trivialer Fehler der mir auffällt ist zum Beispiel folgendes: Du berechnest eine Prüfsumme beim Empfänger und vergleichst Die mit einer übertragenen Prüfsumme. Wenn Du Dumm warst, wie zum Beispiel Nintendo, so nimmst Du zum Vergleich strncmp her. Der Angreifer kann dann provozieren, dass bei beiden Hashes als erstes Byte eine 0 steht. Dazu braucht er 256 Versuche. War der Programmierer minimal schlauer, so verwendet er memcmp. Das hält nicht an der ersten 0, dafür aber am ersten unterschiedlichen Datenwort. Sprich Du kannst an Hand der Laufzeit der Prüfroutine sehen, wie viele Datenworte Du richtig hast. Auf einem 8-Bit Rechner vereinfacht sich das Problem dann auf n*256 Versuche. Dann kann es sein, dass der Rechner Informationen über die Schlüssel über die Versorgungsspannung leckt, usw... Kryptographie ist schwierig, das kann man nicht mal eben in 2 Tagen lernen. Gute Kryptographie erkennst Du daran, dass die Macher am skeptischsten über ihre Sicherheit sind.
cyblord ---- schrieb: >> doch muss er. Woher soll man denn sonst erkennen das nicht geändert >> wurden ist? > Weil nur Müll beim dekodieren rauskommt. Damit das funktioniert, muss deine Nachricht so viel Redundanz enthalten, dass du Müll von echten Nachrichten unterscheiden kannst.
Vielen Dank für die Anworten. Ein gemeinsamer Schlüssel für die Chiffrierung kann vorab ausgetauscht werden und sollte zumindest auf einfachem Wege nicht auszulesen sein. Insofern soll das ganze auf einer symmetrischen Blockciffre beruhen. Seitenkanalangriffe auf den Empfänger sind natürlich ein Thema für sich und ein berechtigter Einwand, dass womöglich der Schlüssel auf diese Weise extrahiert werden kann. Ja, das ist wohl ein gutes Beispiel, welche Tücken es bei der realen Umsetzung gibt. xy schrieb: > Das ist prinzipiell möglich und nennt sich CBC-MAC. Womit du dann doch > eine Prüfsumme hast :-) > Aber bitte bedenken, dass du dafür zwei Schlüssel brauchst. Einen für > die Verschlüsselung der Blöcke, und abschließend einen, mit dem das > Ergebnis "verschlüsselt" wird und dadurch zu deiner MAC wird. Genau darauf zielt meine Frage ab. Eine Möglichkeit, den MAC einer Nachricht zu bilden ist ja das CBC-MAC-Verfahren, wo der letzte Block der CBC-Kette dem MAC entspricht. Möchte man nun zusätzlich die Daten verschlüsseln, gibt es drei Möglichkeiten: 1) MAC vom Klartext berechnen, Klartext verschlüsseln und den MAC anhängen 2) Klartext verschlüsseln, MAC vom Chiffretext berechnen und anhängen 3) MAC vom Klartext berechnen und an den Klartext anhängen, beides gemeinsam Verschlüsseln. Bei der ersten Methode ist mir klar, dass man zwei unterschiedliche Schlüssel benötigt, weil ansonsten ja der angehängte MAC gleich dem letzten Chiffreblock wäre und keine Mehrinformation liefern würde. Bei den letzten beiden Methoden ist mir nicht klar, warum man unterschiedliche Schlüssel benötigt, da der MAC ja entweder mit verschlüsselt wurde, oder trotz gleichem Schlüssel anders aussieht als der letzte Chiffreblock, da er ja vom Chiffretext gebildet wurde. Weiteres frage ich mich eben, ob man überhaupt eine dieser drei Methoden benötigt, wenn man beabsichtigt, eine Blockverschlüsselung zu nutzen. Wenn mit einer Blockverschlüsselung im CBC-Modus verschlüsselt wird, dann ist der Chiffretext eigentlich sicher (abhängig von der Blockchiffre) da der CBC-Modus ja die Diffusion deutlich verbessert. Zusätzlich zum nun erzeugten Chiffretext enthält der letzt Block ja nun automatisch einen MAC der Nachricht, der beim Empfänger verifiziert werden kann. Muss dennoch eine der oben genannten Methoden genutzt werden, auch wenn die Verschlüsselung selbst auf dem CBC-Modus beruht? Ja, der Angreifer weiß so praktisch den MAC des Klartextes, aber diesen weiß er genauso, wenn Methode 1 benutzt wird.
Bernd K. schrieb: > Am einfachsten machst Du es in Deinem Falle so daß Du eine ausreichend > lange Prüfsumme an die Daten anhängst und dann erst verschlüsselst > (Daten mitsamt Prüfsumme). Danach wird es unmöglich sein die Daten so > zu verändern daß sie danach noch als gültig erkannt werden, weder > versehentlich noch absichtlich, und schon gar nicht in irgendeiner > sinnvollen [dem Angreifer nützlichen] Art und Weise. Das ist ohne genauere Betrachtung der Eigenschaften der Prüfsumme und der Verschlüsselung bestenfalls Glückssache. Zum Vergleich: die IEEE hatte damals bei der Festlegung der WLAN-Verschlüsselung (WEP) kein Glück. (Ein CRC kombiniert mit einer Stromverschlüsselung ist leicht manipulierbar: https://de.wikipedia.org/wiki/Wired_Equivalent_Privacy#CRC32_als_Message_Authentication_Code_.28MAC.29) Wenn man nachprüfen will, ob die Daten manipuliert worden, nimmt man einen entsprechend sicheren Hash (MAC). Wenn der MAC ebenfalls manipulationsanfällig ist (z.B. weil man ihn zusammen mit den Daten überträgt), braucht man einen keyed hash, d.h. einen Hash, den man nur mit Kenntnis eines Geheimnisses (Schlüssel) korrekt berechnen kann. Am einfachsten bekommt man den mittels HMAC (https://en.wikipedia.org/wiki/Hash-based_message_authentication_code).
Nosnibor schrieb: > Wenn der MAC ebenfalls > manipulationsanfällig ist (z.B. weil man ihn zusammen mit den Daten > überträgt), braucht man einen keyed hash, d.h. einen Hash, den man nur > mit Kenntnis eines Geheimnisses (Schlüssel) korrekt berechnen kann. Genau das schlug ich auch vor (oder meinte ich vorzuschlagen) mit "ausreichend lange Prüfsumme", ich hätte vielleicht schreiben sollen krypotographisch sichere Prüfsumme. Also nochmal was ich meinte: * kryptographisch sicheren Hash über Plaintext berechnen * Hash an Plaintext anhängen * Obiges Ergebnis (Plaintext + Hash) verschlüsseln Dieses Verfahren wird dann folgende Eigenschaften aufweisen: * Einsicht in den Plaintext und gezielte Manipulation desselben ohne Kenntnis des Schlüssels nicht möglich * Manipulation macht außerdem eine Neuberechnung des Hash notwendig * Hash kann ohne Kenntnis des Schlüssels nicht berechnet werden da hierfür Entschlüsselung und anschließende Verschlüsselung notwendig wäre. => Manipulation und Neuberechnung des Hash ohne Kenntnis des Schlüssels nicht möglich
:
Bearbeitet durch User
Ich habe nun mal versucht, das ganze Szenarion, also Berechnen der Prüfsumme, verschlüsseln, einfaches manipulieren der Daten, entschlüsseln, erneutes Berechnen der Prüfsumme und verifizieren der Prüfsumme mittels eines kleinen PC-Programms zu simmulieren. Dabei habe ich die Prüfsumme mit dem CBC-MAC-Verfahren berechnet und die Verschlüsselung im CBC-Modus betrieben und die drei möglichen Betriebsarten durchgespielt. Wird der CBC-MAC vom Klartext berechnet, der Klartext im CBC-Modus verschlüsselt und der MAC an die Nachricht angehängt, so sind die Daten bei Verwendung des gleichen Schlüssels für die CBC-MAC-Bildung und die CBC-Verschlüsselung wie beschrieben und erwartet nicht gesichert, da die CBC-MAC-Bildung die Entschlüsselung beim Empfänger praktisch nur wider rückgängig macht und so auch bei geändertem Chiffetext zum selben ursprünglichen MAC führt. Selbes gilt, wenn der CBC-MAC vom Klartext berechnet, an den Klartext angehängt und beides mit dem selben Schlüssel im CBC-Modus chiffriert wird. Auch hier macht die CBC-MAC-Bildung beim Empfänger die dechiffrierung rückgängig und der berechnete MAC ist immer gleich dem originalen. Soweit eigentlich so, wie es das Lehrbuch sagt. Verschlüsselt man jedoch zurest die Daten mittels CBC-Modus und berechnet dann vom Chiffretext den CBC-MAC mit dem selben Schlüssel, dann ändert sich der beim Empfänger rückberechnete MAC, sobald die übertragenen Daten geändert wurden. Das ist soweit auch nachvollziehbar, da der CBC-MAC bei der Berechnung nochmals verschlüsselt, praktisch der Klartext zweimal chiffriert wird und beim Empfänger ja vor der Dechiffrierung der MAC berechnet wird, also keine Invertierung der Dechiffrierung stattfindet. Ob das Berechnen des CBC-MAC von den zuvor verschlüsselten Daten mit dem selben Schlüssel nun kryptografisch sicher ist, dass kann ich freilich nicht sagen. Ich wollte eben nur testen, ob es generell nicht möglich ist, die Daten zu sichern, wenn man für CBC und den CBC-MAC den selben Schlüssel nutzt, da die Erklärungen die ich gefunden habe, nicht zwischen den drei möglichen Betriebsarten von CBC mit CBC-MAC unterscheiden.
Bernd K. schrieb: > * kryptographisch sicheren Hash über Plaintext berechnen > * Hash an Plaintext anhängen > * Obiges Ergebnis (Plaintext + Hash) verschlüsseln Sieht gut aus, da stimme ich dir zu. Plaintext+Hash sorgt dafür, daß Veränderung auffliegt, wenn der Hash nicht entsprechend korrigiert wird. Verschlüsselung sorgt dafür, daß der Angreifer nur noch blind im Plaintext herumstochern kann, aber nicht so gezielt manipulieren, daß der Hash wieder stimmt. Ich sehe keinen konkreten Angriffspunkt. Aber den haben mehrere Dutzend Experten bei WEP auch nicht gesehen. Die Gemeinsamkeit zu WEP sehe ich darin, daß ein kryptographischer Mechanismus (Verschlüsselung) dazu verwendet wird, einen anderen (Hash) aufzuwerten. Und das sieht mir einfach zu sehr nach selbstgebasteltem pimp-my-crypto aus, als daß ich dem vertrauen könnte. Weil eben irgendwelche an sich nebensächlichen Eigenschaften der beteiligten Algorithmen miteinander wechselwirken können. Verschlüsselung ist eben nur so definiert, daß der Angreifer den Klartext nicht rekonstruieren kann. Was bei Manipulation passiert… tja, das hängt von Algorithmus und Modus ab, keine Garantie. Z.B. ist Stromverschlüsselung (also auch counter mode) anfällig gegen Bitkippen (wenn ich das 37. Bit des Schlüsseltextes invertiere, ist nach dem Entschlüsseln das 37. Bit des Klartextes invertiert). Oder ECB: da kann man Copy'n'Paste mit den Blöcken spielen. Und Hashes haben auch ihren klar definierten Nutzen. Wenn man mehr damit machen will, kann man seine Überraschungen erleben ("Verlängerung" von Hashes z.B., also daß jemand aus dem Hash einer nur teilweise bekannten Nachricht den passenden Hash einer verlängerten Nachricht berechnet). Hier ist eben ein keyed hash gesucht (naja, 'ne richtige Signatur wäre schöner, aber häufig hat man die Rechenleistung nicht und kommt auch ohne aus), und die Kryptographie bietet so etwas an, ohne daß man mit Eigenkontruktionen Schiffbruch riskieren muß. Verschlüsseln kann man ja hinterher immer noch; das ist dann unabhängig vom Manipulationsschutz und kann ihn nicht stören.
Man sollte das Szenario nicht gänzlich ignorieren. Bei Firmware stehen dem Angreifer typischerweise nur einige wenige Versionen der Datei zur Verfügung, die jeweils eine nicht weiter runterbrechbare Dateneinheit darstellen. Die dafür aber in weiten Teilen identischen Plaintext haben. Das ist eine deutlich andere Ausgangslage als in vielen anderen für Verschlüsselung typischen Szenarien, in denen man meist sehr viel mehr kleinere Dateneinheiten zur Analyse zur Verfügung hat.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.