Gyanakodva nézz ezután a sűrített levegős dobozra is!

Titkosítás, biztonság, privát szféra

A Princeton egyetem egyik számítógépes biztonsággal foglalkozó kutatója vezette csoport olyan eljárást dolgozott ki, amellyel ellophatók a számítógépek memóriájában tárolt adatok (beleértve a biztonsági szempontból érzékeny információkat, kulcsokat is) még jóval a gépek kikapcsolása után is. Sokáig abban a hitben voltunk, hogy a kikapcsolt gép memóriájából nem lehet érzékeny adatokat kinyerni. Sajnos ez nem igaz. A kikapcsolás után akár percekkel is lehetséges adatot kinyerni a számítógépek memóriájából. Csak egy kis jég kell... Meg némi szoftver. A következő videó bemutatja, hogy hogyan...

Bővebben itt.

( pinyo_villany | 2008. 02. 22., p – 21:08 )

akkor kell csinálni egy kernel modult/rutint, ami a gép lelövése elött kisepri a memóriát ..

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.19-opt1

És honnan fogja tudni, hogy "söpörni" kell? Szerintem itt arról van szó, hogy ha kitéped a falból a 220-at, akkor is benne van. A kernel ezt hogyan kezeli le? :)

Mondjuk ez inkább csak érdekesség, mert azt régóta tudjuk, hogy az a gép, amelyhez másnak is van fizikai hozzáférése, az már nem csak a miénk többé :)

--
trey @ gépház

onnan hogy a paranoiások megpatchelik a kernelt és a "poweroff()" lefut a destroy_mem() :P

amugy a powerfail ellen meg vegye ki a ramot ... ha ennyire félti az adatait, vagy csepegtessen sósavat/kénsavat :D

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.19-opt1

"onnan hogy a paranoiások megpatchelik a kernelt és a "poweroff()" lefut a destroy_mem() :P"

Még mindig nem tudjuk, hogy a kernel hogyan értesül a leállításról, ha csak kirántom a konnektorból, vagy lehúzom a notebook akkuját :)

"amugy a powerfail ellen meg vegye ki a ramot"

Mármint menet közben, amikor otthagyja egy percre a gépét? :))

--
trey @ gépház

nyertél, a ha csak kirántom a konnektorból eset az nem tetszik, úgy nem működik :P

erre lehetne csinálni a "b" verziót :P van egy kis tartály a ram felett, amit egy kis elektromágnes tart zárva, ha elmegy az áram vagy nem szabályosan van leállítva a gép, akkor az elektromágnes elenged és a tartalma ráfolyik a ram-ra ... (kicsit brutális és költséges dolog ... meg lehet nagy a hibaszázalék, de :P mindenre van megoldás)

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.19-opt1

A megoldás az, hogy a RAM-ot is titkosítani kell, és ha ilyen leállás van, akkor a RAM titkosító kulcsot kell csak törölni.
A kernel biztosan tájékozódik arról, hogy elment az áram? Ha van pár ms ideje, akkor az biztosan elég, addig még bírják a kondik. Csak a kérdés, hogy mikor értesül, hogy baj van? Amikor már azok is üresek?

Más: egyébként az SRAM-al mi a helyzet? Az is csak lassan hal meg, vagy az azonnal? Annak azonnal meg kéne, amint elmegy az áram. Nem lehetne valahogy beletúrni a proci cache-be, és ott tárolni a kulcsot? Vagy a cache teljesen hardver vezérelt?

Az erdekes. Egy modon tudom elkepzelni: ha olyan jo a tapegyseged, hogy a power-good jelet azonnal lehuzza ahogy elment az aram, de meg par 100ms-ig a kodikbol nyomja a tapfeszt. Meg persze az alaplap is kell tudja ezt kezelni, es valami NMI-t kivaltania ilyenkor... ha ezek teljesulnek, akkor megoldhato.

Persze amikor odamennek folyekon nitrogennel fagyasztani a ramokat a gepben hogy ellopjak az adataidat, akkor nem hiszem hogy gond lenne nekik pl. a 220 helyett az alaplapra meno tapkabelek elnyisszantasa...

A'rpi

Nem, ilyenkor már nincs /dev/zero :-) Ha az egész memóriát felülírod akkor a kernelt is.

Másrészt itt az a probléma, hogy a gépet ellopják és megfosztják az áramforrásoktól. Tehát a rendszer futása egyszer csak megszakad (és nem értesül arról, hogy miért) mivel nincs áram. Tehát mód sincs rá, hogy a bármi memóriapucoló eljárás lefusson. Szerintem ez szoftveresen nem is megoldható.

Valami speciális memóriával (vagy egyébbel) meg lehetne oldani a problémát. A kütyünek lenne egy kis akkuja és amikor érzékeli, hogy nincs áram akkor nullázza a memóriát (legcélszerűbb, ha a memóriára van szerelve).

Gábor

( Hunger | 2008. 02. 22., p – 21:19 )

Nem új dolog ez. Aki anno a Commodore/Spectrum időkben szórakozott azzal, hogy a gép kikapcsolása-bekapcsolása után még mindig futtatható az előzőleg betöltött program, az tudja miről beszélek... ;)

Jaja! C64-nel meg volt XYZ cimen (nem emlekszem talan $8000 kornyeken a "CBM80 string?): hogyha ott volt vmi "jelzes", akkor az rom-ban az init rutin atadta a vezerlest, ezt hasznalta ki par program ugye hogy meg hw reset eseten is az induljon ujra (igaz c64-ben nem is volt gyarilag reset kapcsolo de mind1), meg meg mas dolgok is. A vicces tenyleg az volt hogy ilyen program utan gepet kikapcs bekapcs: altalban vmi osszevisszasag latszodott, neha felimerheto volt a screen tartalma meg ;) Volt hogy 4x kapcsoltam ki be, husszu masodperceket varva, es meg mindig es mindig. Legjobb "poen" akkor volt amikor el akartuk adni a gepet, jottek megnezni es pont akkor jott egy ilyen, es amikor probaltam elmagyarazni, hogy "a memoriaban maradt meg", akkor kb olyan mosollyal neztek mint aki arra gondol "ja, a hulye azt hiszi atvaghat minket", el is huztak gyorsan :(

Amigan van RAD: meghajto, ami reset-tulelo ramdisk... Bar nyilvan poweroffot kevesbe eli tul. :) Egyik havernak volt is ilyen ram-zapper progija, amivel kinullazta a RAM-ot pl. levelezo progi hasznalata utan. Mert a tesoja rendszeresen azzal szorakozott, hogy reset utan, mikor o ult a gephez, akkor hexdumpban olvasgatta a levelezeset a RAM-bol. :D

Pegasos meg olyan, hogy az OpenFirmware csak a RAM elso 32MB-jet inicializalja (sajat celjaira), ezert ott a MorphOS tud is ilyet, hogy a reset elotti debuglogjat el lehet erni reboot utan, mivel azt olyan teruleten tartja, amit az OF nem bant.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Mert a tesoja rendszeresen azzal szorakozott, hogy reset utan, mikor o ult a gephez, akkor hexdumpban olvasgatta a levelezeset a RAM-bol. :D

LOL :))

Pegasos meg olyan, hogy az OpenFirmware csak a RAM elso 32MB-jet inicializalja (sajat celjaira), ezert ott a MorphOS tud is ilyet, hogy a reset elotti debuglogjat el lehet erni reboot utan, mivel azt olyan teruleten tartja, amit az OF nem bant.

De örülnének egy ilyennek a PC-re alacsony szinten fejlesztő bitfaragók... A TrueCrypt-nél jelenleg az a hatalmas nagy szívás, hogy 18k loadere se fér el normálisan, mert a Vista magáénak tekinti 0x9000 címig a memóriát, így marad a 640k-ból 64k max. amelyre meg a jelenlegi BIOS-ok előszeretettel rakják a szarjaikat (RAID, AHCI, integrált audio, stb.), ezért a 18k méretű TrueCrypt betöltő rutin még mindig nem fér el sehogy a legtöbb rendszeren, úgyhogy a gyakorlatban használhatatlan vele.

( saabi v | 2008. 02. 22., p – 21:26 )

Kevéssé győzött meg. De ez az én bajom.
Arra már inkább kiváncsi volnék, mit csinálnak ha egy laptop-ban két modul van? Mint az enyémben, így azt dual-channel módban használja. Tehát a lopó gépbe a saját memóriája mellé még két modult kellene berakni. Én még nem láttam laptop-ot kettőnél több memória foglalattal.
Ha jól értettem, a másik egy hibernált gép disk-jéről töltötte vissza a memóriadump-ot. Ha én a disk-em a notebook-om alaplapjához zárolom (nem jut eszembe ennek a technológiának a neve), akkor az a disk nem fog más vezérlőn elindulni.
Persze az is lehet, hogy a fenti kétségek megalapozatlanok.

Ave, Saabi.

Haj, jobban oda kellett volna figyelnem a szövegre. :-)
Szóval lefagyasztom a két modul-t. Gyorsan lementem az egyiket, majd a másikat (mindezt tíz perc alatt, különben úgyjárok mint Cyclops a Postman-ben) aztán már csak össze kell passzítani hogy a dual-channel miképpen pakolta a memóriamodulokra az adatokat és már kész is a memóriadump...
Azon gondolkozom magamban, hogy TPM-es alaplapon elvileg a kulcs nem kerülhet ki a TPM chip-ből. Vagy csak a session kulcs titkosításához használt permanent kulcs tárolódik a TPM chip-ben?

Ave, Saabi.

Gyorsan lementem az egyiket, majd a másikat (mindezt tíz perc alatt, különben úgyjárok mint Cyclops a Postman-ben) aztán már csak össze kell passzítani hogy a dual-channel miképpen pakolta a memóriamodulokra az adatokat és már kész is a memóriadump...

Belerakhatod egyszerre mind a két modult is a lopó gépbe és egyszerre lementheted, minimális információ veszik el (lényegében a BIOS amennyit felülír + a kis programod, ami lementi a RAM tartalmát a diszkre).

De akár lehet a lopó gépben hekkelt, preparált BIOS is, vagy valami speciális, direkt erre fejlesztett céleszköz... ;)

Azon gondolkozom magamban, hogy TPM-es alaplapon elvileg a kulcs nem kerülhet ki a TPM chip-ből. Vagy csak a session kulcs titkosításához használt permanent kulcs tárolódik a TPM chip-ben?

Nyilván a folyamatos, nagy sávszélességet igénylő, gyors ki-be titkosítás elvégzésére (pl. FDE esetén a merevlemez tartalmáznak ki-be kódolására) alkalmatlan egy apró kis TPM modul, nem is arra lett kitalálva, csak a titkosító kulcs biztonságos tárolására és a megfelelő hitelesítésre. Miután viszont ez megtörténik (tipikusan használat közben) az értékes kulcs már szépen bekerül és ott figyel a memóriában... ;)

De nyilván nem komoly probléma ez, csak most felkapta a sajtó. A felmerülő támadási formák jórésze ellen meg minimális kernel kód változtatással védekezni lehetne. (Pl. olyan helyen tárolni a memóriában a fontos kulcsokat, amelyet a BIOS garantáltan felülír induláskor, így tényleg csak speciálisan ehez preparált céleszközzel lehetne az értékes kódokhoz hozzáférni)

Szerk.: Egyébként az ilyen problémák ellen is védene egy Trusted Computing által lefektetett elvek alapján működő rendszer. Kár, hogy a gyártók jórésze inkább csak a DRM miatt akarja implementálni...

De akár lehet a lopó gépben hekkelt, preparált BIOS is, vagy valami speciális, direkt erre fejlesztett céleszköz... ;)

memória hot-plugos rendszereken mi a helyzet? egy olyanba betolni és az még felül sem irja szerintem ...

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.19-opt1

( pepo v | 2008. 02. 22., p – 21:45 )

Ez nem annyira nagy újdonság.
Úgy '87 körül a Giana Sisters-hez az örökéletet úgy tudtam megcsinálni egy reszetgombnélküli c64-en, hogy kikapcsoltam, majd hirtelen vissza. A memóriában maradt a játék nagy része. Ezek után már csak egy lda, vagy ldx, vagy ldy $#05-öt kellet keresni a memóriában. Akkoriban nem volt sok lda $#05 egy játékban. Az akkumulátor regiszterbe kb 5-6 alkalommal került be az életek számával megegyező adat. Sőt lehetett szűkíteni, hogy nem a játék elején, hanem kb. 1/3-ad - 2/3-ad részében lehet valahol. Azt kitette a program egy memóriacímre, amit aztán szükség esetén dekrementált. Na, a 3 bájtos memória dekrementációs parancsot elég volt nop-okkal helyettesíteni. Pl.: poke 24576,234:poke 24577,234:poke 24578,234. És kész is volt az örökélet. :)

Hát azért Gamer Pistikének nem fog tetszeni a linux. Bár a grafikája már nem rossz, meg jó sok level van, de túl sok a cheat és a cheater. :)

Magyarázat: grafika: compiz. Level: disztrók és nehézségeik, pl. easy: ubuntu, hard: lfs, cheat: dokumentáció, cheater: akik használják a doksikat.

Én ragaszkodom hozzá, hogy te ügyesebben b*sztad szét a Giana Sisters-t.
Nem értem, hogy miért kellett versengésre hívnod a témát! Vagy arra akartál rámutatni, hogy akkora cracker voltál, hogy magát a Top Secret Service-t is szőnyeg alá söpörted? Ha ez volt a szándékod, akkor meghajlok!

Én a Pharaoh's Curse-ba tettem örök életet. Minidg jött a szemét kis madár aztán elvitt... és nem tudtam végigvinni. Pedig ez volt a kedvenc játékom :)

Hard-reset-et nyomtam a user port-on, aztán a sprite-sprite ütközést megtaláltam, meg ahol csökkentette az életet --> nop-pal tele. Aztán sys $8000 körüli értékkel újraindult :) Ja meg még a Falcon patrol volt ilyen, amit hekkeltem, de ha jól emlékszem ott a Restore gombra visszajött a játék :)

( pioo | 2008. 02. 22., p – 22:38 )

Olyat miernem mutatnak soha, hogy a linugzot fagyasztjak le zokszigennel es dozert bootolnak usb drajvrol es ugy nyomjak fel a rendszert, vagy resetelik a rootpasst, vagy valami...
Miert mindig linugz alol hekkelik az ablakosat?

Tul sok unatkozo linugzjuzer van, a picipuhasokat meg jol megfizetik es nem ernek ra ilyenekkel hujulni?

--
Aki falra szerelt tehennel vitatkozik, olyan mint vonat kerek nelkul, nem jut sehova.

Olyat miernem mutatnak soha, hogy a linugzot fagyasztjak le zokszigennel es dozert bootolnak usb drajvrol es ugy nyomjak fel a rendszert, vagy resetelik a rootpasst, vagy valami...

El kell, hogy keresitsem az arcodat, a fentiekre az altalad csodalt 'linugz' is erzekeny, mivel hw es nem sw "bugot" hasznal ki. Bar gondolom ennek atgondolasa mar komoly problemat okoz. :)

---
pontscho / fresh!mindworkz

Itt felreertes tortent! A hozzaszolasom lenyege arra iranyult, hogy miert nem egy a Microsoft(tm) altal kiadott kereskedelmi forgalomban kaphato operacios rendszert hasznalnak arra, hogy bemutassak az erintett hardver mukodesi jellegzetessegeibol adodo sebezhetoseget.

--
Aki falra szerelt tehennel vitatkozik, olyan mint vonat kerek nelkul, nem jut sehova.

( uid_1526 | 2008. 02. 23., szo – 00:08 )

Ilyet már C64-en is sikerült csinálni. Futott a játék, gyors ki-bekapcs, indulás után run, és ismét indult a játék.

Szerk: látom ezt már valaki elsütötte feljebb.

Paranoiásoknak: ki kell önteni a gépet műgyantával :-)

( bitumen | 2008. 02. 23., szo – 00:51 )

Ezellen hdaps-riasztó egész jól védhet. Főleg, hogy thinkpaden mutatják be. Aksit meg úgy nem húzza ki, hogy ne riasszon...

( dworld | 2008. 02. 23., szo – 05:26 )

Azt nem lehetne valahogy megoldani, hogy csak a sajat usb-s eszkozeinket(egyedi azonositojuk alapjan) engedjuk "elfogadni" a linuxnak? Meg kellene hatarozni, hogy milyen azonositoju eszkozoket fogadjon el, as akkor elvileg hiaba csatlakoztatna barmit is usb-n.

Persze ez csak lockolasnal mukodne..

------
dworld

( turul16 v | 2008. 02. 23., szo – 08:24 )

Jol elvitatkozgattok egy nem letezo probleman. :)

( Hijaszu | 2008. 02. 23., szo – 08:29 )

Szóval rábootolnak a saját kis szoftverükre. Hmm. Hát igen, ezért szokták az egyeb boot lehetőségeket letiltani. Akkor meg szétszedik a gépet? Ennyi erővel akár el is lophatnák :D

A probléma:

Eddig ez volt (ezt hitték az emberek): Az adatok titkosítva vannak a lemezen valamilyen szoftverrel. Ellopják a gépet, nem tudnak hozzáférni az adatokhoz, mert nincs meg a kulcs.

Most ez van: Ellopsz egy olyan gépet, amelyik fut, de mondjuk be van kapcsolva a képernyőkímélő, (azaz le van lock-olva) mert hosszabb ideig magára hagyták. Elvileg nem tudsz belépni, mert nem tudod a jelszót. Ha reboot-olsz, akkor meg nem tudsz hozzáférni az adatokhoz a titkosítás miatt. Azoban a lemeztitkosítást már feloldotta az user, hiszen fut az OS. A kulcs a memóriában. Ez kell neked. Szépen fogod az ellopott gépet, lejegeled a memóriát, hogy az hosszú ideig megtartsa a tartalmat, kiveszed, átteszed egy másik gépbe (vagy akár ugyanazon a gépen), a memória dumperrel lemented a memória tartalmát, megkeresed a kulcsot, vissza a memóriát az eredeti gépbe, bekapcsolod, megadod a key-t, elindul a rendszer. És már hozzá is fértél a hiperszuper titkos adatokhoz. Magyarul a technika megmutatja (legalábbis ezt állítják), hogy a napjaink (legtöbb) lemeztitkosításai (dm-crypt, Bitlocker, FileVault) szart sem érnek.

--
trey @ gépház

ha tényleg olyan hipertitkos az információ akkor még egy titkosított fájlrendszerrel is meg lehet bővíteni, ami mondjuk autómatice pl képernyővédőkor is lecsatol. A HDD fájlrendszeréhez hozzáférhetnek, de a rajta megtalálnak hipertitkos 100Mb-os fájl ami 2048 bites titkosított fájlrendszer... innentől örülhetnek a kulcsnak a HDD-hez, de a rajta levő állományhoz már nem biztos hogy belátható időn belül hozzáférhetnek...
Mivel a lecsatoláskor meg felülírja a memóriarészt ahol korábban tárolva volt a kulcs (írás olvasásig), így marad a brute force emberrablás ember betörése jelszó kiadásáig (valamikor volt hír hogy küzd ezzel az USA jogrend, hogy nem tehet magára terhelő vallomást az állmapolgár...se terrorista)

Minden esetre érdekes ez a cikk. Szerintem azzal lehetne elkerülni (alvás és képernyővédő kivételével), hogy hibernációnál ill kikapcsoláskor a kernelnek kell 00-zni a memóriának egészét vagy az érintett részét és nem csak a bios-ra hagyni a piszkos munkát.

Üdv:
Csabka

Azért a szarnál csak többet egy picivel, mert az adatok kinyerhetőségéhez a kikapcsolás után tíz percen belül neki kell esni a gépnek, nem elég 'csak úgy bármikor' ellopni azt. Ilyen pl. a bringalakat is: nincs olyan, amit pl. a hidraulikus erővágó ne vinne le, de azért amivel fél órát kell küzdeni, az már jónak számít(ana).

Hát igen, ez az egyszerű, ám annál kevésbé figyelmen kívül hagyható tény, miszerint az adatlopást helyben kell elvégezni, sokak figyelmét elkerülte. Ennek figyelembevételével a desktop gépek - hordozhatóságuk limitáltsága okán - rögtön kiesnek a veszélyeztetettek köréből. Egy laptopot már könnyebb elcipelni, de ha le van lakatolva, akkor már felkelthet némi figyelmet a lopás kisérlete.
Persze semmilyen védelmi technológia nem helyettesítheti az emberi figyelmet. Értékes adatokat - úgyértem mások számára értékeseket, pl. a családi fotóalbum számomra pótolhatatlan, másoknak mégis vajmi kevéssé kelti fel a figyelmét - tároló mobil eszközünkre nem árt figyelni és lehetőleg ne hagyjuk magára.

Ave, Saabi.

( log69 | 2008. 02. 23., szo – 08:46 )

Én azt furcsállom, hogy ez csak most derült ki. Nehéz elhinni, hogy a memória gyártók még nem készítettek hasonló teszteket (vagy csak nem akarták publikálni az eredényeket) :)

( log69 | 2008. 02. 23., szo – 09:30 )

Ugye az alapprobléma a memória adatainak pár percnyi túlélésével, hogy a titkosított merevlemezhez kiolvassák a kulcsot.

Amint a video anyagon elhangzott, a Vista Bitlocker-rel titkosított partícióhoz pár perc alatt megvan a kulcs a meleg ramból. Ezt az alábbi módon csinálhatják szerintem (exponenciális robbanás nélkül):

Végigolvassák byte-ról byte-ra az egymás mellett álló adatokat, és azt változó hosszú hash mintának véve bepróbálják a titkosított adat kibontásához. Ha veszünk 1 GB ram-ot és mondjuk 1-ől 20 byte-ig vesszük a mintát, akkor a memóriát csak 20x kell végignyalni, ami belátható időn belül is gyorsan megvan, összesen 2^30 x 20 byte felolvasásával (habár a hash-nél amúgy is lehetne fix 20 vagy 32 vagy egyéb fix hosszúsággal számolni).

Mi lenne ha a memóriában tárolt hash mintának byte-jait nem egymás mellett tárolnák, hanem egy meghatározott módon szétdobnák a memóriában -persze feltételezve, hogy az előző kulcsot sem úgy olvassák ki, hogy a program-kódszemetet megfejtik.

Így ha nem tudják olvasni a megmaradt assembly kódot és a hash byte-ok sem egymás mellett vannak, akkor a kombinációk száma túlságosan megnő.

Azt meg azért gondolom hogy nem a megmaradt program kódokat fejtik meg, mert az pár percnél tovább tartana valószínűleg (arra gondolok, hogy nem egy ismert bináris mintát keresnek, mert az persze gyorsan meglenne, habár erre meg lehetne azt az eljárást alkalmazni, miszerint a hash mintát kezelő algoritmus assembly utasításai közé véletlen szerű módon beszúronk NOP utasításokat, így lehetetlenné téve hogy egy ismert bináris kódrészletre tudjanak rákeresni).

( joco01 v | 2008. 02. 23., szo – 09:46 )

Szerintem ez ellen egyedül memória hardver módosítással lehet védekezni. Pl. ha elmegy a táp, a sok kis kondi áramát belevezeti egy nagy ellenállásba. Vagy valami titkosítást tesznek az adatvonalakra. Vagy bármi.

--
joco voltam szevasz

Hogy idezzem Hungert: "De akár lehet a lopó gépben hekkelt, preparált BIOS is, vagy valami speciális, direkt erre fejlesztett céleszköz... ;)" Nem egy was ist das egy olyan cel eszkoz sem. De ha " De nyilván nem komoly probléma ez, csak most felkapta a sajtó. A felmerülő támadási formák jórésze ellen meg minimális kernel kód változtatással védekezni lehetne." ez sem nyugtat meg, akkor par csepp ragaszto, kikotott usb/firewire es kesz.

Persze elkepzelem, hogy az esti agyon cenzurazott hiradoban tomegesen jelennek meg a hirek, "Ismeretlenek elloptak Kovacs Gedeon gazdasagi miniszter laptopjat es fejet. Szemtanuk meg lattaka a kriogenikus tartalyokkal rohano terroristakat, akiket az NBH a csukja es a fenytoro pajzs ellenere a Magyarok Nyilai elnevezesu szervezet tagjai voltak." Eh. :)

---
pontscho / fresh!mindworkz

( blalo | 2008. 02. 23., szo – 10:44 )

Szerintem meg nem kell mindent elhinni.

A dinamikus memória lényege, hogy feszültség alatt másodpercenként több ezerszer kell egy memóriacímhez fordulni, mert egy kondenzátor tárolja egy bit állapotát (leegyszerűsítve), és az olyan kicsi, hogy nagyon hamar elveszíti a töltését.
A videón is a dinamikus memóriát vették ki. Úgyhogy hűtögethetik, de az 10 percig nem fogja megőrizni az adatot. Még egy másodpercig sem.

A C64 statikus memóriát használ. Ez ha a tápvezetéken megkapja a feszültséget, akkor az adatot is megőrzi. Sokkal alacsonyabb feszültségen is, mint amiről még a C64 processzora üzemelni képes. Ha a gép ki lett kapcsolva, akkor is még a tápkondenzátorokról kap némi feszültséget. Persze egy-két perc múlva már kellően lecsökken a feszültség ahhoz, hogy a statikus memória is törlődjön.

Ha meg valaki paranoiás, akkor a jelszó bekérése, és ellenőrzése után felül kell írni a memóriaterületet ahol a jelszót tárolták. De szerintem ezt minden profi így csinálja, mert különben a RAM kivétele nélkül is könnyen el lehetne lopni a jelszót. :)

A dinamikus memória lényege, hogy feszültség alatt másodpercenként több ezerszer kell egy memóriacímhez fordulni, mert egy kondenzátor tárolja egy bit állapotát (leegyszerűsítve), és az olyan kicsi, hogy nagyon hamar elveszíti a töltését.

Valószínűleg ezért kezdi úgy Edward W. Felten a Freedom to tinker oldalon, hogy a probléma gyökere a napjaink DRAM memóriák egy nem várt tulajdonságának elhallgatásán alapul.

Ha meg valaki paranoiás, akkor a jelszó bekérése, és ellenőrzése után felül kell írni a memóriaterületet ahol a jelszót tárolták. De szerintem ezt minden profi így csinálja, mert különben a RAM kivétele nélkül is könnyen el lehetne lopni a jelszót. :)

A jelszót felülírhatja (valószínűleg meg is teszik), de a titkosításhoz szükséges kulcsot (amelyet a jelszó segítségével fejt vissza egy titkosított tárolóból vagy kér le akár a TPM modultól) a memóriában kell tárolnia ahoz, hogy műveleteket tudjon vele végezni (pl. ahoz, hogy a vinyó tartalmát transzparensen, a felhasználó számára láthatatlan módon tudja ki-be kódolni). Ez a titkosító kulcs pedig már épp elég egy támadónak, nincs szüksége feltétlenül a jelszóra...

Hogyan találja meg a kulcsot a több 100 megabájt között?

Az FDE megoldások (BitLocker, TrueCrypt, etc.) a boot legelején töltődnek be, még az oprendszer kernele előtt (hisz adott esetben már maga a kernel is lehet titkosított diszken, amit vissza kell fejteni a betöltéséhez), ennek köszönhetően fix helyre, eléggé könnyen meghatározható memóriaterületre töltődnek be ezek a loaderek és egy megszakításon keresztül (konkrétan 13-as interrupt hookolásával, mint DOS alatt anno a vírusok ;) biztosítják a transzparens titkosítást a lemezműveletekhez addig, amíg az operációs rendszerek driverei nem lesznek aktívak (onnantól kezdve azok végzik a műveleteket tovább). Rosszabb esetben tehát a kulcs megtalálható az alsó memóriaterületen (640k ;), amit valós módban használnak a boot során, jobb esetben ha ezt okosan törli is a védett módú driver, amikor átveszi a feladatot, akkor is az ő memóriaterületéből vissza lehet állítani (még jobb is, mert ezt biztos nem írja felül a BIOS az újraindítást követően ;). Manapság annyira jó memória dump és kód analizáló szoftverek vannak, hogy könnyedén visszafejthetők ezek az adatok. Elég csak a titkosítást végző kód szekvenciára rákeresni és megnézni, hogy honnan, melyik memóriacímről veszi a kulcsot.

Ha meg is találja, mit kezd vele, ha a kulcsban 1-2 bit már elállítódott (kevésbé optimális esetben több)?

1-2 bitet viszonylag könnyen és gyorsan lehet visszaállítani akár egy egyszerű bruteforce-al is... ;)

( Hiena v | 2008. 02. 23., szo – 12:32 )

Alapvetoen, kellemes kis video csak epp egyszerre ket dolgot kever ossze, valoszinuleg szandekosan.
A DRAM memoriak uzemmeleg allapotban tobbmillio masodpercenkenti frissitest igenyelnek. A tapfeszultseg megszunesekor, megszunik a frissites a DRAM cellakban (effektive kis kondenzatorok) a feszultsegszint csokkenni kezd, emiatt par masodperc alatt eltunik a tarolt informacio. Amikor a delikvens lefagyasztja a memoriat es ugy helyezi at, a fagyasztassal mintegy megnoveli a DRAM cellak kapacitasat ezert ha nem is 10 percig, de egy ket percig megorzi a tartalmat. Errol szol a video elso resze.
A video masodik reszenek ezen technologiahoz semmi koze, ugyanis alapvetoen ket dolgot hasznal ki. Az egyik, hogy a modern szamitogepekben a memoria kezeleset a north bridge vegzi. Ami technikai okokból körbe van pakolva par ezer mikrofaradnyi kondenzatorral. Amikor kirantja az ember az akkumulátort egy laptopbol, a kulonfele periferiak asszerint fognak leallni, hogy mennyi kapacitas van a kornyezetukben. Mivel a legtobb laptop aramfelvetelet probaljak minnel jobban korlatozni, ezert a legtobb periferia akar percekig is elketyeghet az alaplapi kondenzatorokban tarolt energiabol. Termeszetesen a processzor, a kijelzo, a HDD lesz az elsok kozott akik megallnak, mert ok a laptopok nagyfogyasztoi.
Namost, mi tortenik amikor csak egy pillanatra megy el a delej? Normalisan a gep ujrabootol es a BIOS ellenorzi a memoriat. Oooopsz... Rossz esetben ez azt jelenti, hogy a BIOS szepen vegig írja és olvassa FF-el es 00-val a memoriat. Jo estben meg vegigreseteli a memoriat, es megnezi, hogy tenyleg 00-val van tele. Goodbye, encryption key...
Es itt jon a masodik gebasz. Mivel a legtobb alaplapgyártó a dzsunka vegen rakja ossze az alaplapjat az esetek nagytobbsegeben tojik arra, hogy a belehanyt BIOS kelloen kitesztelt legyen, inkabb meghagyjak opcionak a BIOS frissites lehetoseget. A problema az, hogy regen ez ugy nezett ki, hogy lefutott a biosz majd egy megfeleloen elkeszitett boot floppyval az ember bebootolt egy megfelelo rendszert es utana futtatott egy programot ami felulirta a regi BIOSt. Ujabban a floppy szerepet az USB eszkozok vettek at, sot elegendo ha az adott eszkoz csak a BIOS imaget tartalmazza, mert a BIOS alapban kepes azt beolvasni es futtatni. A hiba ott van, hogy ez a gyarban, felig kesz BIOSszal osszerakott cuccokat, gyorsan es fajdalommentesen ujra lehessen flashelni és ilyen esetben a BIOS nem futtatja le az ontesztet, nincs memoria torles. A videoban azt hasznaljak ki, hogy az akkumulator kikapasa es visszarakasa utan az USB eszkozrol bebootolt par kb-os kod csak a memoria egy reszet (jo esellyel az elso par blokkot) foglalja el, a tobbi terulet erintetlen marad. Csinal egy memdumpot, amibol aztan kimagozza az elkodolasi kulcsot.
Vedekezesre szamos megoldas lehetseges. 1. A kulcsot a memoria elejere irjak, olyan teruletre ahova a BIOS bootnal igy-is, ugy-is irni fog. 2. North bridgenek a logikajan mododitani, hogy powerfail eseten, a memoriat kezdje el resetelni. Ez effektive par ms alatt lezajlik fagyasztospray ide vagy oda.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

1: egy gépben több memória modul is lehet. kivesznek egyet a lopott gépből, beteszik egy másik gépbe a 2. pozícióba, és a bios nem oda fogja tenni magát. ez csak egy egyszerű példa, igazából ha az adat ott van, azt ki fogják onnan olvasni.
2: becsúsztatnak egy kis műanyag lapot az érintkezők közé, elveszik pl. a ram modul tápját vagy földjét, és ennyi.

mondom, magában a ramban kell ez ellen védekezni, lásd kicsit feljebb.

--
joco voltam szevasz

( johnzero | 2008. 02. 23., szo – 12:48 )

Loop-AES + keyscrub a megoldás:

"If you want to enable AES encryption key scrubbing, specify KEYSCRUB=y on
make command line. Loop encryption key scrubbing moves and inverts key bits
in kernel RAM so that the thin oxide which forms the storage capacitor
dielectric of DRAM cells is not permitted to develop detectable property.
For more info, see Peter Gutmann's paper:
http://www.cypherpunks.to/~peter/usenix01.pdf
"

( csabka v | 2008. 02. 23., szo – 19:33 )

Csak egy gondolat, ha Bios is jelszavazva van, akkor nem növekszik meg az idő, hogy eljussanak odáig hogy bebootoljanak USB-n akármitkódot (pl nálam tiltva van minden egyéb média bootolása, bios pedig jelszóval védve). Persze a BIOS jelszó kiütése nem tart sokáig, de növeli a művelettel töltött időt. (kiszedett ram ellen amúgy meg mind1 :D de legalább nehezítettük).

Amúgy Theo mit mond erre OpenBSD-vel kapcs, biztos van véleménye...?

/A biztonság a használhatatlanságig fokozható/

Üdv:
Csabka

( kelemenm | 2008. 02. 23., szo – 22:36 )

Ebben a cikkben az a jó, hogy felhívja a figyelmet egyes biztonsági rendszerek hiányosságára. Encrypt után ha nem jó, és rögtön törölné a memóriából az encryptelt adatot, akkor nincs gond... (Amíg nem kezdenek kínai gyerekek versenyezni, hogy ki a gyorsabb, az algoritmus, vagy ők? :) )
Persze ha nincs Encrypt, akkor nincs probléma...
Az oprendszer által memóriában tárolt védett adatokat pedig sose értettem miért olyan titkosak :) Miért nem csak egymástól kell védeni a programok memóriaterületét? Mit kell a Microsoftnak Tőlem féltenie, amit az én memóriámban tárolnak? :o

( nextar | 2008. 02. 23., szo – 23:47 )

1. gondolat: bios jelszó és bootolásból kivesszük a removable mediat vagy fix hddt allítunk be.
2. gondolat: a biosba lehetne írni egy rutint, hogy amikor inicializálja a ramot törölje is azt. Az indításkor kikerülhetetlen.

Es ha egyszeruen lockolaskor illetve kikapcsolaskor szoftveresen torlodik a kulcs, akkor mi a helyzet? Ilyenkor az akkukivetellel se tudna sok mindent kezdeni.

Ez persze attol is fugg, hogy mit ertunk lockolas alatt, mert ha azt, hogy a programok futnak tovabb, csak egy login screen jellegu dolog megakadalyozza, hogy hasznaljam a gepet, akkor ez inkabb a user error kategoria, ha titkositott adatok vannak a gepen. Viszont ha a lock alatt mondjuk suspendet ertunk, akkor a suspend idejere elkepzelheto, hogy meg lehet csinalni, hogy torlodjon a jelszo, es bekapcsolaskor ujra bekerje.

Az, hogy kirantom a 220-bol a gepet, vagy beloginolva kiveszem az akksit, szinten user error kategoria. Egy titkositott gepet beloginolva talan nem kellene otthagyni, nem?

Ha pedig varatlan aramszunet van, akkor a felhasznalo is egyszeruen megertheti, hogy egesz addig, amig egy ujabb bekapcs-kikapcsot nem csinal, addig nincsenek biztonsagban az adatok. Es ez nem csak a kulcs miatt igaz, hanem peldaul azert mert a swap fajlban is lehetnek titkositatlan adatok ilyenkor.

Ezt nem egészen értem. Ha lenne egy rutin minden gép biosában, ami a ram "leszámolásakor" egyben törli is azt (nevezzük tesztelésnek), akkor max. szétszereléssel lehet megoldani az adathozzáférést. Ez kis ráfordítással (bios update) sokat javítana a helyzeten. Ha meg a kezükben van már a masina úgy is mindegy.

( parrot | 2008. 02. 24., v – 10:54 )

Nem lehetne ezt a felfedezést (mármint hogy a RAM tartalma nem vész el rögtön kikapcsolás után) másra is felhasználni? Pl. visszaállítani egy el nem mentett dokumentumot áramszünet után.

( gsimon | 2008. 02. 25., h – 15:03 )

Csodálom, hogy még senkinek sem jutott eszébe, hogy mindez ellen védelmet nyújthatna, ha a user egyszerűen magával vihetné a ramot meg a vinyót a gépből, de valami olyan módon, hogy annak az üzemét ne zavarja meg vele.
Hogy mindez lehetetlen lenne? Nem az. Nagyon egyszerű: vinni kell vele az üzemben tartáshoz szükséges részeket is. Aksit, frissítő áramköröket, hűtést, stb., mindezt ráadásul egy szép, kényelmes hordozható formában. Valami olyasmiben, mint például egy lecsukott laptop...
Basszus, ha már egyszer laptop (és érzékeny adatok vannak rajta), akkor _miért nem viszi magával_?