C/C++ Forum :: frage zu coldboot angriffen auf aes

cooky451 Mitglied 21:29:25 28.01.2012 Titel:

Christoph schrieb:

A) Der Key ist ausgerichtet auf 256 Bit, d.h. die Adresse des Keys im RAM ist durch 32 teilbar.

Den Zusammenhang verstehe ich nicht. Warum liegt der Key denn an einer solchen Adresse, nur weil der 32 Byte groß ist?

Unregistrierter

Mechanics schrieb:

Wenn das eigentliche Programm (z.B. truecrypt) weiß, wo die Daten liegen, weiß es auch der Angreifer. Weil er auch auf Truecrypt Zugriff hat.

der computer ist aus, wird mit einem kleinem system gebootet (etwa innerhalb von 30sec je nach ram-type und ob kältespray eingesetzt wird oder nicht) und der ram wird kopiert. (so habe ich den coldboot angriff verstanden.)

man dürfte doch eigentlich nicht wissen, welche adressen von welchem programm angefordert wurden, also auf welchen speicher truecrypt zugriff hatte.

Christoph schrieb:

A) Der Key ist ausgerichtet auf 256 Bit, d.h. die Adresse des Keys im RAM ist durch 32 teilbar.

es sind alle adressen möglich, außer die letzten 31, da hier keine 32byte mehr hinpassen.

folglich gibt es 2·1024·1024·1024 - 31 mögliche adressen.
man braucht 2,147483617·10^5 sekunden, also etwa 2,5 tage.
(natürlich kann es doppelte bytefolgen gebne, die ignoriert werden könnten, wodurch die rechenzeit etwas kleiner wird.)

wenn jetzt durch eine datenstruktur gewährleistet wird, dass der key in einzelne bytes zerteilt wurde und die nun nicht hintereinander stehen ( zugriff erfolgt dann per pointer), kann eigendlich jedes byte im ram ein teil vom schlüssel sein.
man kann sicher davon ausgehen, dass im ram jedes byte mindestens einmal vorkommt, wodurch (falls die pointer die den schlüssel speichern auch auf gleiche adre4ssen zeigen können) die rechnung nun etwas anders aussieht:
es gibt 256 bytes
folglich 256^8 möglichkeiten.
hierfür braucht man dann etwa 5.849424173·10^7 jahre, da das problem auf ein brute force zenario ausgedehnt wurde.

natürlich würde diese ganze idee zusammenbrechen, wenn man feststellen kann welchen arbeitsspeicher truecrypt angefordert hat.
kann man sowas etwa feststellen?

SG1 Mitglied 11:51:30 29.01.2012 Titel:

wsxdfg schrieb:

man dürfte doch eigentlich nicht wissen, welche adressen von welchem programm angefordert wurden, also auf welchen speicher truecrypt zugriff hatte.

Und wieso darf man das nicht wissen? Klar weiß man das!

Zitat:

wenn jetzt durch eine datenstruktur gewährleistet wird, dass der key in einzelne bytes zerteilt wurde und die nun nicht hintereinander stehen ( zugriff erfolgt dann per pointer), kann eigendlich jedes byte im ram ein teil vom schlüssel sein.

*gähn* Dann nimmt man halt eben jene Datenstruktur, um den Schlüssel wieder zusammenzusetzen. Überhaupt kein Problem.

Christoph Moderator 13:04:41 29.01.2012 Titel:

wsxdfg schrieb:

Christoph schrieb:

A) Der Key ist ausgerichtet auf 256 Bit, d.h. die Adresse des Keys im RAM ist durch 32 teilbar.

es sind alle adressen möglich, außer die letzten 31, da hier keine 32byte mehr hinpassen.

Wenn ein Key 32 Byte lang ist, wird jedes vernünftige Programm den Key an einer durch N teilbaren Adresse ablegen (mit N>=4). Alles andere wäre ziemlich ineffizient.

Aber wenn du darauf bestehst, kann man die Bedingung auch weglassen.

wsxdfg schrieb:

folglich gibt es 2·1024·1024·1024 - 31 mögliche adressen.
man braucht 2,147483617·10^5 sekunden, also etwa 2,5 tage.
(natürlich kann es doppelte bytefolgen gebne, die ignoriert werden könnten, wodurch die rechenzeit etwas kleiner wird.)

Genau. Bei 2,5 Tagen lohnt es sich nicht, sich geschicktere Angriffe auszudenken.

wsxdfg schrieb:

wenn jetzt durch eine datenstruktur gewährleistet wird, dass der key in einzelne bytes zerteilt wurde und die nun nicht hintereinander stehen ( zugriff erfolgt dann per pointer), kann eigendlich jedes byte im ram ein teil vom schlüssel sein.
man kann sicher davon ausgehen, dass im ram jedes byte mindestens einmal vorkommt, wodurch (falls die pointer die den schlüssel speichern auch auf gleiche adre4ssen zeigen können) die rechnung nun etwas anders aussieht:
es gibt 256 bytes
folglich 256^8 möglichkeiten.
hierfür braucht man dann etwa 5.849424173·10^7 jahre, da das problem auf ein brute force zenario ausgedehnt wurde.

natürlich würde diese ganze idee zusammenbrechen, wenn man feststellen kann welchen arbeitsspeicher truecrypt angefordert hat.
kann man sowas etwa feststellen?

Pointer zeigen auf virtuelle Adressen, nicht auf echte RAM-Adressen. Deswegen ist es gar nicht so trivial, den RAM nach Pointern zu durchsuchen und mit diesen Pointern auch etwas anzufangen, wenn man nur den physischen Speicher sieht.

Wenn man den kompletten RAM fehlerfrei sieht, sollte es gehen, denn truecrypt muss den Key ja auch irgendwie finden. Hat SG1 ja gerade gesagt. Aber bei Cold-Boot-Angriffen sind manche RAM-Abschnitte schon weg. Wenn man Pech hat, ist die Tabelle beschädigt, die virtuelle Adressen auf physische Adressen mappt. Dann wird es schwieriger. Müsste man ausprobieren. Da fehlt mir auch Detailwissen, wie einfach man virtuelle Adressen rekonstruieren kann, wenn man nur den physischen Teil sieht.

Christoph Moderator 13:06:42 29.01.2012 Titel:

Für viel erfolgssprechender halte ich übrigens die Methode, den Key gar nicht erst im RAM abzulegen, sondern nur in der CPU. Die CPU bietet dann natürlich auch keine Methode an, den Key wieder auszulesen, man kann ihn nur noch benutzen, wenn man ihn einmal reingeschoben hat in die CPU. Ich meine mal gelesen zu haben, dass aktuelle (oder kommende?) CPUs so ein Feature haben sollen, aber vielleicht irre ich mich auch.

Patrickssj6 Mitglied 16:09:52 29.01.2012 Titel:

Christoph schrieb:

Für viel erfolgssprechender halte ich übrigens die Methode, den Key gar nicht erst im RAM abzulegen, sondern nur in der CPU. Die CPU bietet dann natürlich auch keine Methode an, den Key wieder auszulesen, man kann ihn nur noch benutzen, wenn man ihn einmal reingeschoben hat in die CPU. Ich meine mal gelesen zu haben, dass aktuelle (oder kommende?) CPUs so ein Feature haben sollen..

So ist es.

knivil Mitglied 16:35:56 29.01.2012 Titel:

Annahme: 128 Bit Schluessel liegt zusammenhaengend im Speicher. Ich kenne teile der Orginalnachricht und der verschluesselten, sagen wir 16 Byte. Irgendwo in 2GByte gespeichertes RAM liegt der AES-Schluessel. Macht also etwa 2^31 bzw. ca. 2 * 10^9 moegliche Schluessel. Gesucht: Zeit zum finden des Schluessels.

Mit den AES-Instructionen des Intel i5 benoetigt man 3.5 Takte pro Byte, also 56 Takte fuer 16 Byte. Der Rechner ist 3Ghz schnell und verfuegt ueber 4 Kerne. Pro Sekunde koennen also (3*10^9 * 4) / 56 Schluessel getestet werden, also ca. 214 Millionen Schluessel. D.h. der Schluessel ist in 10 Sekunden gefunden.

Zitat:

den Key gar nicht erst im RAM abzulegen, sondern nur in der CPU.

Aehm, und wenn der Prozess gescheduled wird, Registerinhalte auf dem Stack landen, ... genau deswegen gibts es ja TPM, damit der Nutzer mit Zugang zur Hardware das DRM nicht umgehen kann.

Zitat:

kann eigendlich jedes byte im ram ein teil vom schlüssel sein.

Unrealistisch, da AES auch schnell sein soll. Wenn erst der Key gesucht werden muss, drueckt das stark die Geschwindigkeit. Darueber hinaus kennt man die Prozessstruktur und den zugehoerigen Speicher des Verschluesselungsprogramms. AES bzw. jede andere Verschluesselung ist nur sicher, wenn man keinen direkten Zugriff auf die laufende Hardware hat.

mfq Mitglied 13:59:54 03.02.2012 Titel:

Christoph schrieb:

Ich meine mal gelesen zu haben, dass aktuelle (oder kommende?) CPUs so ein Feature haben sollen, aber vielleicht irre ich mich auch.

Von der Idee hatte ich vor längerer Zeit schon mal in einer Diplom-Arbeit gelesen. Mittlerweile wurde das ganze wohl auch umgesetzt und zwar in Form eines Linux-Kernelpatches.

http://www1.informatik.uni-erlangen.de/tresor/

Der Schlüssel (und anscheinend auch sonstiger AES-State) wird hier ausschließlich in einem CPU-Register gehalten und erreicht nie den Hauptspeicher. Auf aktuellen Intel-CPUs mit hardwaregestützter AES-Verschlüsselung (AES_NI) soll das super funktionieren, mit Abstrichen ("performance penalty of about factor six compared to generic AES and the only supported key length is 128 bits") ist es aber auch auf älteren x86-CPUs, die zumindest SSE2 haben, nutzbar.