Kryptografisch sichere Prüfsumme

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.

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.
[...]

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?

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?

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.

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?

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.

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:
> 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.

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.

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).

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.