Mi a különbség az ATA Secure Erase és a Security Erase között? Hogyan tudom biztosítani, hogy működtek?

Szeretnék egy köteg meghajtót (spinning és SSD) biztonságosan törölni. Ismerem az ATA Secure Erase (SE) parancsot a hdparm segítségével , de nem vagyok biztos benne, hogy a Biztonsági törlés (SE +) parancsot kell-e használnom helyette.

Van néhány bizonyíték arra, hogy ezek a parancsok ne dolgozzon minden meghajtón. Hogyan biztosíthatom, hogy a meghajtó valóban törlődik, beleértve a tartalék területeket, az átcsoportosított szektorokat és hasonlókat?

Tervezem használni a linux élő CD-t (USB-n). Az Ubuntu működőképes élő CD-t biztosít amelyet telepíthetek a hdparm-ra, de van-e egy kisebb élő CD-terjesztő, frissített szoftververziókkal, amelyeket inkább használnom kell?

Tehát összefoglalva:

Mik az SE előnyei és hátrányai versus SE +?

Hogyan biztosíthatom, hogy a meghajtót valóban és alaposan kitörölték?

Melyik linux disztribúciót használjam?

Megjegyzések

  • Általános szabály, hogy ' az a legjobb, ha több kérdést nem tartalmaz egy kérdésbe. Hosszabb, bonyolultabb válaszokat ad és nehezebb keresse meg a kérdéseket. Csak egy tipp – én ' nem próbállak megcsinálni!

Válasz

Idézi ezt az oldalt :

A biztonságos törlés felülírja az összes felhasználói da-t ta területek bináris nullákkal. A továbbfejlesztett biztonságos törlés előre meghatározott (a gyártó által beállított) adatmintákat ír be az összes felhasználói adatterületre, beleértve azokat az ágazatokat is, amelyeket az újraelosztás miatt már nem használnak.

Ennek a mondatnak csak a lemezek forgatásakor van értelme és titkosítás nélkül. Egy ilyen lemezen bármikor megjelenik a lemez logikai nézete, amely hatalmas számozott szektorok sorozataként jelenik meg; a " biztonságos törlés " arról szól, hogy ezeket az ágazatokat (és csak ezeket az ágazatokat) felülírjuk egyszer nulla . A " továbbfejlesztett biztonságos törlés " keményebben próbálkozik:

  • Többször felülírja az adatokat különböző bitminták, annak biztosítása érdekében, hogy az adatokat alaposan megsemmisítsék (hogy valóban szükség van-e erre, vitatható, de sok hagyomány működik itt).

  • Felülírja azokat a szektorokat is, amelyeket már nem használnak, mert valamikor I / O hibát váltottak ki, és újratervezték őket (azaz az egyik tartalék szektort a lemez firmware használja, amikor a számítógép elolvassa vagy írja).

Ez a szándék . Az ATA specifikáció szempontjából két parancs létezik, és nincs valódi módja annak, hogy megtudjuk, miként valósítja meg a törlést, vagy akár azt, hogy ténylegesen megvalósul-e. A vadon élő lemezekről ismert, hogy időnként némi szabadságot élveznek a specifikációval (pl. Az adatok gyorsítótárazásával).

A biztonságos törlés másik, meglehetősen hatékony módszere a titkosítás :

  • Az első bekapcsoláskor a lemez egy véletlenszerű szimmetrikus kulcsot generál K , és egy újraindítás ellenálló tárhelyen tartja (például néhány EEPROM-ot). .
  • Minden olvasott vagy írt adat szimmetrikusan lesz titkosítva, a K kulcsot használva.
  • Egy " biztonságos törlés ", a lemeznek egyszerűen el kell felejtenie a K t egy új generálásával és az előző felülírásával.

Ez a stratégia a forgó lemezekre és az SSD-re egyaránt vonatkozik. Valójában, amikor az SSD végrehajtja a " biztonságos törlést ", akkor KELL használnia a titkosítási mechanizmust, mert az " felülírása nullákkal " sokkal kevésbé van értelme, tekintve a Flash-cellák viselkedését és az SSD-kben használt nehéz átdolgozás / hibajavító kódrétegeket.

Amikor egy lemez titkosítást használ, nem tesz különbséget a " biztonságos törlés " és a " továbbfejlesztett biztonságos törlés "; megvalósíthatja mindkét parancsot (ATA protokoll szinten), de ugyanazokat az eredményeket hozza. Ne feledje, hogy hasonlóan, ha egy forgó lemez azt állítja, hogy mindkét módot megvalósítja, akkor nagyon jól lehet, hogy mindkét parancsot ugyanazon művelethez kapcsolja (remélhetőleg az " továbbfejlesztett " one).

Amint azt az ezen az oldalon leírjuk, a hdparm -I /dev/sdX parancs valami ilyesmit fog jelenteni:

Security: Master password revision code = 65534 supported enabled not locked not frozen not expired: security count supported: enhanced erase Security level high 2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT. 

2 perc nem elegendő az egész lemez felülírásához, tehát ha ez a lemez valamilyen tényleges " biztonságos törlés ", a titkosítási mechanizmusnak kell lennie.Másrészt, ha hdparm jelentést tesz erről:

 168min for SECURITY ERASE UNIT. 168min for ENHANCED SECURITY ERASE UNIT. 

, akkor arra következtethetünk, hogy:

  • Ez a lemez teljes adat felülírást hajt végre (ez az egyetlen oka annak, hogy csaknem három órát vesz igénybe).
  • A " biztonságos törlés " és " továbbfejlesztett biztonságos törlés " valószínűleg ugyanaz a lemez.

A lemez méretétől és a tömeges I / O normál teljesítményétől függően (az hdparm -tT /dev/sdX mérhető) még arra is következtethetünk, hogy az adatok hányszor vannak állítólag felül van írva. Például, ha a fenti lemez mérete 1 terabájt és 100 MB / s írási sávszélességet kínál, akkor 168 perc elegendő egyetlen felülíráshoz, nem pedig a három vagy több átadás, amely " továbbfejlesztett biztonságos törlés " állítólag magában foglalja.

(Nincs különbség a Linux disztribúciói között ezen a területen; mindannyian használják ugyanaz a hdparm segédprogram.)


Meg kell jegyeznünk, hogy a titkosításon alapuló biztonságos törlés valóban csak az adatok minőségének erejéig törli az adatokat a titkosítás és a kulcsgenerálás. A lemez titkosítása nem könnyű feladat, mivel biztonságosnak kell lennie, és mégis támogatnia kell a véletlenszerű hozzáférést. Ha a firmware egyszerűen megvalósítja az ECB alkalmazást, akkor azonos sima szövegblokkok szivárognak ki, amit általában a pingvin szemléltet. kép . Ezenkívül a kulcsgenerálás botcsinálható; lehetséges, hogy az alapul szolgáló PRNG meglehetősen gyenge, és a kulcs teljes körű keresésre alkalmas lenne.

Ezek a " részletek " nagyon fontosak a biztonság szempontjából, és nem lehet tesztelni őket . Ezért, ha biztos akar lenni az adatok kitörlésében, csak kétféle mód van:

  1. A lemezgyártó elegendő részletet közöl arról, hogy mit valósít meg a lemez, és garantálja a letörlést (lehetőleg szerződés szerint).

  2. Régi jó fizikai megsemmisítéshez folyamodik. Hozza ki a nagy igénybevételre alkalmas aprítógépeket, a forró kemencét és a bogrács savat!

Megjegyzések

  • # 1 ½. Futtat egy másik megfelelő FDE-réteget azon felül, hogy a meghajtó milyen védelmet nyújt, és idő előtt meghatározza, mit kell tenni az FDE-séma ' s összes másolatának felülírása érdekében. (Például a LUKS használatával a konténer első ~ 10 MB felülírása szinte garantálja a kulcsok összes másolatának felülírását, a többi tároló csak véletlenszerű adatokká válva. Miután a szoftveres FDE kulcsok eltűntek, minden bizonnyal elvégezhet egy Az ATA Secure Erase is, de még akkor is, ha ez rosszul valósul meg, az adataidnak ésszerűen biztonságosnak kell maradniuk ha a szoftveres FDE-t jól csinálják.
  • Úgy gondolom, hogy nem értek egyet a " 2 perc nem elegendő az egész lemez felülírásához ", mert az a megértésem, hogy az SSD-k általában ezt valósítják meg, az az, hogy minden blokkhoz nullát küldenek, szinte Egyidejűleg. A lemezem 2 percet ír SE-re és 8 percet az Enhanced SE-re. I ' m azt hiszem, hogy a második is ugyanezt teszi, de nem nulla adatok esetén?
  • Ha a biztonságra vonatkozik, ' gyanús a kód (azaz ROM-ok), ' nem tudom lefordítani, beírni / telepíteni magam. már kno w az NSA elfogta az újonnan vásárolt útválasztókat, és hátsó ajtókat telepített beléjük. Miért ne szabotálná a merevlemez ' s beépített titkosítását is? Valójában miért ne tenné meg ezt a szokásos működési eljárást?
  • @sherrellbc: Ez ' valójában nem is olyan váratlan. Az SSD egy " fizikai-logikai " leképezést használ. Biztonsági okokból vissza szeretné állítani ezt a leképezést a biztonságos törlés után is. Különösen az összes logikai szektort vissza szeretné állítani egy őrszemre " nincs hozzárendelve ". Ezt minden nullához keményen be kellene kódolni; csak az első íráskor hozna létre SSD egy tényleges leképezést.
  • Van itt egy meghajtóm, ahol a továbbfejlesztett törlés 2 perc (valójában kevesebb, mint 1 másodperc), a rendszeres törlés pedig 8 + óra. more than 508min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

Válasz

Amikor belenéztem, Az volt a benyomásom, hogy az ATA biztonságos törlését és egyéb szolgáltatásait még nem minden gyártó alkalmazza megfelelően az adatok tényleges törlése / tisztítása szempontjából. ATA biztonsági törlés az SSD-n http://arstechnica.com/security/2011/03/ask-ars-how-can-i-safely-erase-the-data-from-my-ssd-drive/

Megértésem (korlátozott), hogy az SSD-k biztonságos törlése még mindig nincs teljesen szabványosítva , még a hdparm biztonságos törlési szolgáltatásához is.Az adatokat nem feltétlenül töröljük, bár a Polynomial válasza az előző kérdésre azt jelzi, hogy az egyetlen fennmaradó adat titkosításra kerül. A legjobb megoldás lehet, ha felveszi a kapcsolatot az eladóval, és megnézi, mit mondanak.

A hagyományos HDD-k tekintetében elegendő a DBAN, bár nem garantálja, hogy minden adat valóban törlődik. (lásd: http://www.dban.org/about )

Válasz

A forgó HDD-k esetében a (a linuxon), hogy 100% -ban biztos legyen abban, hogy minden szektor törölve lett, és nem attól függ, hogy a gyártó valóban végrehajtja-e a SATA erase parancsot.

dd status=progress if=/dev/urandom of=/dev/sdx bs=512K 

Sajnos ez SSD-ken nem fog működni (jól fog futni, de óriási esély van arra, hogy az összes adatot nem töröljük).

További előny a dd kap-e haladásjelzőt, nem fogja megkapni ezt a hdparm használatával, és az dd használatával törölheti a műveletet kicsit nehezebb a hdparm használatával.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük