frage zu coldboot angriffen auf aes



  • hi.
    ich habe mich ein wenig mit aes beschäftigt und frage mich nun, wie ein coldbootangriff hier eigendlich aussieht.
    klar man macht sich eine kopie vom ram und sucht hier irgendwas.
    aber was sucht man?
    den key? das würde mich wundern, denn wie will man wissen, dass man gerade die richtigen 256bit als key nimmt? bei 2gb kann man ja auch schlecht alle möglichkeiten ausprobieren....

    was sucht man sonst?



  • Ich versteh die Frage nicht. Was hat Coldboot mit AES zu tun? Du musst schon etwas konkreter werden. Wenn du wissen willst, wie man über Coldboot Attacken Truecrypt oder Bitlocker angreifen kann, dann gibt es auch schon wesentlich konkretere Ansätze, weil das einfach ganz konkrete Technologien sind, und man weiß (oder herausfinden kann), wie sie konkret funktionieren, wie und wo sie Schlüssel ablegen usw. Aber ob das jetzt AES oder 3DES ist, ist im ersten Schritt völlig nebensächlich.



  • ok dann nehmen wir als bsp mal truecrypt.

    ließt man da direkt den key aus?
    wenn der key ausgelesen wird, warum wird er dann nicht im ram verteilt(so sollte es doch nur schwer möglich sein ihn zu finden) und warum wurde dann eigendlich der key in eine leicht zu findende/erkennende struktur gepackt und nicht einfach irgendwo zufällig im ram abgelegt, sodass man nicht erkennen kann, dass eine bitfolge der key ist?



  • Weil obfuscation noch nie ein Hindernis war.



  • aber wenn der key eine zufällige folge von bits ist und man an dieser nicht erkennen kann, ob es sich um einen aes-key handelt oder, dann kann man doch mit einer kopie vom ram doch nichts anfangen, da es in den 2gb sehr viele möglichkeiten gibt, die 256bit lang sind.
    oder gibt es eine möglichkeit zu erkennen, ob 256bit jetzt ein key sind oder nicht? (afaik gibt es keine)



  • Dann stelle ich dir folgende Fragen:

    - wenn der Key zufällig im Speicher verteilt ist, woher weiß dann der Truecrypt Treiber/Bootloader wo der Key zum entschlüsseln ist?

    - wie kann truecrypt mit wild im Speicher verteilten Keyfragmenten die nötigen Rechenoperationen durchführen, die zum entschlüsseln notwendig sind?



  • mit zufällig im ram meinte ich, dass der key nicht von einem bestimmten muster umgeben ist.
    z.b. kann man per pointer den key addressieren.
    natürlich muss man dann auch gewährleisten, dass der pointer nicht in einer leicht zu erkennenden struktur eingebettet ist.
    wieso ist eigendlich der key von einer leicht zu erkennenden struktur umgeben (bzw wodurch kommt diese zu stande)?



  • wsxdfg schrieb:

    wieso ist eigendlich der key von einer leicht zu erkennenden struktur umgeben (bzw wodurch kommt diese zu stande)?

    Wie kommst du jetzt drauf? Was ist überhaupt leicht zu erkennen oder nicht? Man könnte z.B. eine Entropieanalyse machen, glaub aber nicht, dass es jemand macht.

    schmuessla hats eigentlich schon auf den Punkt gebracht. Wenn das eigentliche Programm (z.B. truecrypt) weiß, wo die Daten liegen, weiß es auch der Angreifer. Weil er auch auf Truecrypt Zugriff hat.



  • So ist es, das ist alles nur obfuscation, das bringt keine zusätzliche Sicherheit sondern höchstens zusätzliche Zeit.

    Das Ganze ist übrigens auch kein Angriff auf AES sondern ein Angriff auf ein System um den Schlüssel zu erlangen.

    Das Problem besteht ja, soweit ich das recht in Erinnerung habe, bei Systemen mit PBA, da hier beim Herunterfahren der Speicher nicht überschrieben werden kann, weil der passende Zeitpunkt dafür nicht ermittelt werden kann und der Tatsache dass SDRAM halt doch nicht beim ersten ausbleibenden refresh-Signal seinen Inhalt "vergisst"



  • wsxdfg schrieb:

    aber was sucht man?
    den key? das würde mich wundern, denn wie will man wissen, dass man gerade die richtigen 256bit als key nimmt? bei 2gb kann man ja auch schlecht alle möglichkeiten ausprobieren....?

    Rechne doch mal spaßeshalber aus, wie lange das Durchsuchen von 2GB dauert, wenn man zwei Dinge annimmt:
    A) Der Key ist ausgerichtet auf 256 Bit, d.h. die Adresse des Keys im RAM ist durch 32 teilbar.
    😎 Du kannst pro Sekunde 10000 Keys testen (das ist niedrig geschätzt).



  • 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?



  • 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?



  • 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!

    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.



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



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



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



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

    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.

    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.



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


Log in to reply