Hva er forskjellen mellom ATA Secure Erase og Security Erase? Hvordan kan jeg sikre at de jobbet?

Som sitert fra denne siden :

Sikker sletting overskriver alle bruker-da ta områder med binære nuller. Forbedret sikker sletting skriver forhåndsbestemte datamønstre (satt av produsenten) til alle brukerdataområdene, inkludert sektorer som ikke lenger er i bruk på grunn av omdisponering.

Denne setningen er fornuftig bare for spinnende disker, og uten kryptering. På en slik disk er det når som helst et logisk syn på disken som en enorm sekvens av nummererte sektorer; " sikker sletting " handler om å overskrive alle disse sektorene (og bare disse sektorene) en gang , med nuller . " forbedret sikker sletting " prøver hardere:

• Den overskriver data flere ganger med distinkte bitmønstre, for å være sikker på at dataene blir grundig ødelagt (om dette virkelig er nødvendig er gjenstand for debatt, men det er mye tradisjon her).

• Den overskriver også sektorer som ikke lenger brukes fordi de utløste en I / O-feil på et tidspunkt, og ble kartlagt på nytt (dvs. en av reservesektorene brukes av diskens firmware når datamaskinen leser eller skriver den).

Dette er intensjonen . Fra ATA-spesifikasjonssynspunktet er det to kommandoer , og det er ingen reell måte å vite hvordan slettingen implementeres, eller til og med om den er faktisk implementeres. Det er kjent at disker i naturen til tider tar seg noen friheter med spesifikasjonen (f.eks. Med data caching).

En annen metode for sikker sletting, som er ganske mer effektiv, er kryptering :

• Når den slås på første gang, genererer disken en tilfeldig symmetrisk nøkkel K og holder den i noe omstartbestandig lagringsplass (for eksempel noen EEPROM) .
• Alle data som leses eller skrives, blir kryptert symmetrisk med K som nøkkel.
• Å implementere en " sikker sletting ", disken trenger bare å glemme K ved å generere en ny, og overskrive den forrige.

Denne strategien gjelder både spinnende disker og SSD. Når en SSD implementerer " sikker sletting ", MÅ den faktisk bruke krypteringsmekanismen, fordi " overskriving med nuller " gir mye mindre mening, gitt oppførselen til Flash-celler og de tunge remapping / feilkorrigerende kodelagene som brukes i SSD-er.

Når en disk bruker kryptering, vil den ikke skille mellom " sikker sletting " og " forbedret sikker sletting "; det kan implementere begge kommandoene (på ATA-protokollnivå), men de vil gi de samme resultatene. Merk at på samme måte, hvis en spinnende disk hevder å implementere begge modusene også, kan den veldig godt kartlegge begge kommandoene til samme handling (forhåpentligvis " forbedret " one).

Som beskrevet i denne siden , er hdparm -I /dev/sdX kommando vil rapportere noe sånt som dette:

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 minutter er ikke nok til å overskrive hele disken, så hvis den disken implementerer noe faktisk " sikker sletting ", det må være med krypteringsmekanismen.På den annen side, hvis hdparm rapporterer dette:

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

så kan vi konkludere med at:

• Denne disken utfører en full dataoverskriving (det er den eneste grunnen til at det vil ta nesten tre timer).
• " sikker slett " og " forbedret sikker sletting " for den disken er sannsynligvis identisk.

Avhengig av diskstørrelse og normal ytelse for bulk I / O (kan måles med hdparm -tT /dev/sdX, kan man til og med utlede hvor mange ganger dataene er angivelig overskrevet. For eksempel, hvis disken ovenfor har størrelse 1 terabyte og tilbyr 100 MB / s skrivebåndbredde, er 168 minutter nok for en enkelt overskriving, ikke de tre eller flere passene som " forbedret sikker sletting " skal innebære.

(Det er ingen forskjell mellom Linux-distribusjoner i det området; de bruker alle det samme hdparm verktøyet.)

Man må merke seg at den krypteringsbaserte sikre slettingen virkelig tørker dataene bare i den grad kvaliteten på kryptering og nøkkelgenerering. Diskkryptering er ikke en enkel oppgave, siden den må være sikker og likevel støtte tilfeldig tilgang. Hvis firmware bare implementerer ECB , vil identiske blokker med ren tekst lekke, som vanligvis illustreres av pingvinen bilde . Videre kan nøkkelgenerering være feil; det er mulig at den underliggende PRNG er ganske svak, og nøkkelen vil være mottakelig for uttømmende søk.

Disse " detaljer " er veldig viktige for sikkerheten, og du kan ikke teste for dem . Derfor, hvis du vil være sikker på å slette dataene, er det bare to måter:

1. Diskprodusenten gir deg nok detaljer om hva disken implementerer, og garanterer tørken (helst kontraktuelt).

2. Du tyr til gammel gammel fysisk ødeleggelse. Ta ut tunge makuleringsmaskiner, den varme ovnen og syregryten!

Kommentarer

• # 1 ½. Du kjører et nytt lag med riktig FDE på toppen av hvilken beskyttelse stasjonen tilbyr, og bestemmer på forhånd hva som må gjøres for å overskrive alle kopier av FDE-skjemaets ' s nøkler. (For eksempel, med LUKS, vil overskriving av de første ~ 10 MB av beholderen nesten garanteres å overskrive alle kopier av nøklene, noe som gjør resten av containeren bare tilfeldige data. Når programvarens FDE-nøkler er borte, kan du absolutt utføre ATA Secure Erase også, men selv om det er dårlig implementert, bør dataene dine forbli rimelig sikre hvis programvaren FDE gjøres riktig.
• Jeg tror jeg er uenig med " 2 minutter er ikke nok til å overskrive hele disken " fordi min forståelse av hvordan SSD-er generelt implementerer dette er at de sender null til hver blokk, nesten samtidig. Disken min sier 2 minutter for SE og 8 minutter for Enhanced SE. Jeg ' Jeg gjetter at den andre gjør det samme, men for data som ikke er null?
• Når det gjelder sikkerhet, er jeg ' mistenksom mot kode (som betyr ROM-er). Jeg kan ' t kompilere og brenne / installere meg selv. allerede kjent w NSA har fanget opp nyinnkjøpte rutere og installert bakdører i dem. Hvorfor ikke sabotere en harddisk ' sin innebygde kryptering også? Faktisk hvorfor ikke lage den vanlige driftsprosedyren?
• @sherrellbc: At ' faktisk ikke er så uventet. En SSD bruker en " fysisk-til-logisk " -tilordning. Av sikkerhetsgrunner vil du også tilbakestille denne kartleggingen etter en sikker sletting. Spesielt vil du tilbakestille alle logiske sektorer til en sentinel " ingen kartlegging ". Dette ville være hardkodet til alle nuller; bare ved første skriving ville SSD opprette en faktisk kartlegging.
• Jeg har en stasjon her hvor forbedret sletting er 2 minutter (faktisk mindre enn 1 sekund) og vanlig sletting er 8+ timer. more than 508min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

Da jeg så på dette, Jeg fikk inntrykk av at ATA-sikker sletting og andre funksjoner ikke er godt implementert av alle produsenter ennå når det gjelder faktisk sletting / sanering av data. ATA-sikkerhetssletting på SSD http://arstechnica.com/security/2011/03/ask-ars-how-can-i-safely-erase-the-data-from-my-ssd-drive/

Min (begrensede) forståelse er at sikker sletting av SSD-er fremdeles ikke er fullstendig standardisert , selv for hdparms sikre slettefunksjon.Dataene slettes ikke nødvendigvis, selv om svaret på det forrige spørsmålet på Polynomial indikerer at de eneste gjenværende dataene vil bli kryptert. Det beste alternativet kan være å kontakte leverandøren og se hva de sier.

Når det gjelder tradisjonelle harddisker, bør DBAN være tilstrekkelig, selv om det ikke garanterer at alle data virkelig blir slettet. (se http://www.dban.org/about )

Når det gjelder spinnings-harddisker, foretrekker jeg å bruke dd (på linux) for å være 100% sikker på at alle sektorer er utslettet og ikke er avhengig av at produsenten faktisk implementerer SATA-slettekommandoen riktig.

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

Dessverre vil dette ikke fungere på SSD-er (vel, det vil kjøre, men det er stor sjanse for at alle data ikke blir slettet).

En annen fordel ved å bruke dd får du en fremdriftsindikator, får du ikke det ved å bruke hdparm og ved å bruke dd kan du avbryte operasjonen, det virker litt vanskeligere med hdparm.