Nyt værktøj knækker diskkryptering på Mac og Windows på under én time

Et kommercielt værktøj kan nu bryde både Apples FileVault og Microsofts Bitlocker diskkryptering på under en time.

Krypteringen af filerne på din harddisk er kun 995 dollars og en times regnearbejde fra at blive brudt, hvis du bruger Microsofts Bitlocker eller Apples FileVault. Det skriver CNET.

Det kommercielle dekrypteringsværktøj fra Passware understøtter nemlig nu både Microsofts og Apples seneste versioner af diskkryptering og kan bryde dem på under en time.

Passware kan blandt andet bryde Apples FileVault 2, som blev introduceret i den nyeste version af Mac OS X. Det kræver blot en Firewire-forbindelse til disken, hvorefter Passware-værktøjet kan analysere sig frem til at trække krypteringsnøglerne ud fra hukommelsen.

Passware bruger en tilsvarende metode til at få fat i nøglerne til Bitlocker To Go, som Microsoft introducerede sammen med Windows 7. Ud over Bitlocker og Filevault kan Passware også knække TrueCrypts diskkryptering.

Ifølge Passware tager det under 40 minutter at bryde krypteringen i Filevault 2. Selskabets værktøjer er fortrinsvis beregnet til at blive brugt til kriminalteknisk efterforskning, men kan også bruges til at redde systemer, hvor brugeren har mistet sit kodeord.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Bjarke I. Pedersen

Det fremstår lidt som om tingene er knækket, hvilket ikke passer.

Jf. http://www.lostpassword.com/hdd-decryption.htm fungerer det ved, at man tager et komplet memory dump af maskinen, imens den kører, over firewire.
Hvis ikke, så tager den og forsøger med brute force, som den eneste mulighed.

Så egentlig er der ikke noget nyt i, at man kan hente det ud fra en memory dump...

  • 2
  • 0
Jacob Christian Munch-Andersen

Der er ingen kendte huller som kan bryde krypteringen af de to systemer med en blot tilnærmelsesvis realistisk mængde regnekraft såfremt et passende stærkt password er brugt.

Det som programmet kan er at fiske kodeordet ud af maskinens hukommelse når man er logget ind, og altså alligevel har adgang til de krypterede filer.

  • 7
  • 0
Dana Skovsende

Konklusionen er at nøglen kan findes hvis den STADIG befinder sig i hukommelsen og dette tager under 40 minutter. Dette er en HELT anden sag end at disken kan dekryptere på under 40 minutter.

Nu skal jeg ikke gøre mig klog på FileVault eller Bitlocker sikkerhed, men TrueCrypt diske er gentagne gange forsøgt dekrypteret med "brute force" uden held. (Underforstået at TrueCrypt bliver brugt korrekt) Der er heller ikke nogle kendt sikkerhedshuller i TrueCrype måde at kryptere på.

Bl.a. har FBI blevet nødt til at give op overfor TrueCrypt
http://news.techworld.com/security/3228701/fbi-hackers-fail-to-crack-tru...

  • 4
  • 0
Kasper Dupont

Lad mig være den første til at sige, at måden de produkter krypterer disken på kunne være bedre. Men de små problemer der er med selve krypteringen er underordnede i forhold til de fejl der er i systemerne omkring krypteringen.

Jeg har til dato ikke set et eneste system hvor kombinationen af diskkryptering og suspend fungerede korrekt. Når der suspendes skal det sikres at krypteringsnøglen ikke kan udledes fra indholdet af RAM. Det er underordnet om der er tale om suspend til RAM eller suspend til disk. Dog vil jeg mene at med suspend til RAM er det acceptabelt hvis kun nøglemateriale og ikke alt andet beskyttes. Ved suspend til disk skal hele billedet af RAM være beskyttet mindst lige så godt som resten af diskens indhold.

Der er mange systemer der spørger om brugerens password når de vågner fra suspend. Men det foregår som regel med en ganske almindelig skærmlås, og bagved den kører det komplette system med adgang til alle de krypterede data. Dermed er nøglen selvfølgelig tilgængelig. Hvis kombinationen af suspend og diskkryptering fungerede korrekt ville der være brug for en lille smule ekstra kode til at håndtere brugerens password når computeren vækkes fra suspend.

Det lyder også som om at hullet der tillader at man aflæser hele indholdet af RAM over firewire stadig er til stede. Det er skræmmende hvis der ikke er blevet gjort noget for at lukke det hul, når nu det har været kendt i flere år.

Jeg undrer mig så over at det kan tage 40 minutter at bryde krypteringen, hvis man har et fuldt billede af RAM. Det burde jo ikke tage længere end 40 sekunder. Når systemet vågner fra suspend er det jo i stand til at dekryptere indholdet af disken så snart billedet af RAM er indlæst (endnu hurtigere ved suspend til RAM).

Måden AES fungerer på er en medvirkende årsag til at denne type angreb er så lette at realisere. Det er ikke fordi der er tale om at udnytte en decideret fejl i AES, men en cipher kunne være designet til at besværliggøre denne type angreb.

Specielt de angreb der tidligere blev demonstreret med at nedkøle RAM for at bevare indholdet af RAM imens strømmen kortvarrigt blev afbrudt udnyttede detaljer i måden AES fungerer på.

Problemet med AES er at når en nøgle laves om til en key schedule vil denne key schedule have en let genkendelig struktur, der samtidigt kan udnyttes som fejlkorrigerende kode. Dermed kan nøglen rekonstrueres selvom der måtte være nogle få bitfejl i denne key schedule.

Havde cipheren i stedet være designet således at afbildningen fra nøgle til key schedule var en kryptografisk PRNG, så ville den type angreb besværliggøres og muligvis helt kunne forhindres.

Da samtlige angreb jeg har set imod AES har fokuseret på den svage key schedule synes det oplagt at man nok burde overveje om ikke en opdateret udgave af AES med en ny key schedule ville være en god idé. Jeg ville personligt kigge på blowfish for at hente inspiration til en bedre key schedule.

Men selvom en anden cipher kunne gøre det sværere at finde nøglen i et billede af RAM, så er det sikreste dog at sørge for at nøglen ikke er til stede i RAM på det tidspunkt hvor angrebet sættes ind.

  • 1
  • 0
Baldur Norddahl

Jeg har til dato ikke set et eneste system hvor kombinationen af diskkryptering og suspend fungerede korrekt. Når der suspendes skal det sikres at krypteringsnøglen ikke kan udledes fra indholdet af RAM. Det er underordnet om der er tale om suspend til RAM eller suspend til disk. Dog vil jeg mene at med suspend til RAM er det acceptabelt hvis kun nøglemateriale og ikke alt andet beskyttes. Ved suspend til disk skal hele billedet af RAM være beskyttet mindst lige så godt som resten af diskens indhold.

Jeg bruger den indbyggede fulddiskkryptering i Ubuntu. Suspend til RAM er ganske som du beskriver. Men ved suspend til disk er alt krypteret. Swap, hukommelsebillede, filsystem med mere er alle gemt i samme krypterede partition. Maskinen skal da også bruge nøglen for at kunne starte igen, præcis ligesom ved koldstart. Ja, faktisk tror jeg slet ikke at det er muligt at vide om maskinen er suspenderet eller slukket, før efter at man har givet den nøglen.

Firewire er noget møj. Det er et fejldesign der gør det muligt at tilgå hele hukommelsen. Mig bekendt er der intet operativsystemet kan gøre ved det. Muligvis kan firewire deaktiveres. Men ellers er det en åben ladeport der muliggør hackning af enhver maskine, som du har fysisk adgang til.

  • 1
  • 0
Log ind eller Opret konto for at kommentere