Seagate vil lave harddisk med indbygget kryptering

Wow. Betyder det, at jeg rent faktisk kan have mine filer i fred? Antipiratorganisationer vil brokke sig voldsomt.

der er sikket en eller anden form for bagdør til datane.

Enig, der må være en måde rundt om det, såå, ved ikke helt hvor brugbart det bliver.
Men ja, APG vil da helt sikkert brokke sig.

Bortset fra det, så ville det være rart hvis der ikke er stavefejl i overskrifterne, hvilket der desværre har været et par gange her på newz. Men ja, når alt komme til alt så er det jo indholdet der er vigtigst, og vi forstår vist allesammen godt hvad der burde stå.

#1 Ja, det gør det, og nej, der bør naturligvis ikke være nogen bagdør til dataene.
Hvis dataene er krypteret med DES-algoritmen med en nøgle kun du kender, så er der ikke umiddelbart nogen vej udenom.
Det er muligt at APG vil brokke sig, men de kan ikke forbyde kryptering.

er det ikke en gammel nyhed ?

Jeg er ikke så meget inde i datakryptering - her lige et spørgsmål:
Hvis man krypterer med en nøgle, er nøglen så ens password? Og hvad sker der når man skifter password?

Ja, du krypterer med din nøgle, så du kan ikke skifte password uden at omkryptere alting.

Gad vide hvorfor de har brugt 3DES frem for den bedre AES...

Vil det ikke få stor indflydelse på fil-kidnapning? At deres programmer ikke kan læse dataen, vil jo betyde de ikke kan "fængsle" ens data.

#6 Krypteringsnøglen kan f.eks. ligge på en USB-nøgle, der skal sidde i computeren. Smadrer du USB-nøglen, ja, så får du ikke sådan lige fat i dine data! :-)

I øvrigt krypteres en nøgle normalt med et password. Se på digital signatur, som indeholder din private nøgle. Den kan du kun bruge, hvis du indtaster en adgangskode (f.eks. for at signere en e-mail). Selvom nøglen er den samme, kan du stadig til enhver tid ændre din adgangskode for at åbne nøglen.

Jeg tror helt sikkert det bliver en succes, hvis det lykkes ordentligt for dem. Det vil i hvert fald blive et produkt jeg vil få stor glæde af, men, som de andre siger, vil det med garanti irritere antipiraterne som bare pokker. :)

Hvordan vil de egentligt forhindre, at det ikke går udover ydelsen?

#10 Eftersom det er en chip i harddisken der krypterer dine data er der en større ydelse (vil jeg gå ud fra) end hvis du blot har et software-krypteret filsystem, hvor krypteringen kører over CPU'en. Så med denne harddisk skal du ikke spilde CPU-resourcer på at få dine data krypteret.

Ydelsen afhænger selvfølgelig af hvor hurtigt deres chip kan kryptere/dekryptere data.

#10 Sætte krypteringsdelen ind som selvstændigt modul, og så modvirke eventuel sløven ved at forbedre resten af harddisken?

#6 Nøglen kan eksempelvis som sagt ligge på en USB-nøgle og vil altså ikke være et password som brugeren selv skal indtaste, selvom det naturligvis er muligt at lave en kombination af begge. Det svarer lidt til den kryptering de er indbygget i NTFS i Windows bare uden den dårligere ydelse (du skal selv så denne krypting til hvis du vil bruge den).
#7 Sikkerhed. AES er udelukkende bedre fordi nøglen er længere. Nøglelængden på AES er typisk 128 bit hvor den på DES er 56 bit. Ved at kryptere 3 gange med 3 forskellige DES-nøgler opnår man i princippet en nøglelængde på 3x56bit = 168 bit, dvs 30 bit mere.
#10 Hvis krypteringsenheden i harddisken kan kryptere data hurtigere end de kan skrives til disken, så bliver der ikke ret meget ydelsestab. Tabet vil så kun består i at dataene skal igennem et par ekstra kredsløb hvilket næppe vil betyde ret meget i praksis.

#7: DES er jo en ældre sag, blev en standard tilbage i 76, hvilket også betyder at den er meget hardware optimeret. Tripple DES er jo ikke anderledes, hvilket også må betyde at den er meget hardware optimeret (Blev standardiseret i 99 eller deromkring). AES som er nyere, er direkte blevet lavet med det formål at den skulle være software orienteret.

Tripple DES bruges jo stadigvæk rigtig meget idag, bla. at USAs regering, så tvivler på at man vil finde nogen backdoors i den :)

AES tilbyder 128,192,256 bit nøgler, tripple DES er 168bit, hvilket også er en hæderlig nøgle størrelse.

Ok Tak for jeres mange svar.

Men hvis nøglen eksempelvis ligger på en USB nøgle (som man normalt har med sig på rejser og lign) ryger fordelen jo lidt.. +80% vil nok opbevare den sammen med den bærbare - altså ryger sikkerheden fuldstændig?

(med mindre der også skal indtastes password)

#13 AES er også bedre på andre punkter, eks. er block størrelsen jo 128 imod DESs 64. Hvilket fra hvad jeg har forstået giver en mere effektiv og hurtigere algoritme.

#1 og #2: Faktisk har I begge ret; DES er så svær at bryde at det er de færreste tyveknægte der har råd til det, men stadig så let at bryde at de fleste regeringer og meget store virksomheder har muligheden hvis behovet opstår.

I 93 blev der udviklet en speciel CPU til præcist det formål, og for omkring 100.000$ kan man få en maskine der i snit vil tage 1,5 dage om at finde en vilkårlig nøgle. Derfor er det (ligesom al anden kryptering) ikke 100% sikkert, men det er sikkert nok mod almindelig industrispionage og tyveri.

Sikkert mod regeringen bliver det aldrig. Specielt ikke da vi ikke ved helt præcist hvad de har at gøre med.

Jeg vælger at antage, at det på den ene eller anden måde bliver muligt, at læse hvad der står på denne disk hvis man virkelig vil. Det bliver nok besværligt, men det skal nok kunne lade sig gøre.
Hvem har så seriøst brug for en krypteret disk ?

Folk der vil skujle noget fra forældre, kærste eller ægtefælde.

Disken vil sikkers kunne sælges i stor stil på gund af folks skræk for AGP og lignende.

#17 Ja, det er helt korrekt. Derfor er krypteringsgraden også sat op ved at forlænge nøglen til det tredobbelte. Så er man i hvert fald sikret godt på den anden side af næste istid, også fra forskellige regeringers supercomputere. Vi taler altså om 2^112 gang så stærk kryptering som DES. Det vil også tage 2^112 gang så lang tid at bryde, så selvom DES kan brydes på 1,5 døgn -det er nok noget mindre i dag, lad os sige 24 timer på en standard PC-, så vil det stadig tage 2^112 døgn på en PC. Hvis vi siger at en supercomputer kan lave 1024 gange så mange beregninger i sekunder (det er et pænt tal) så er vi nede på 2^102 døgn, hvilket stadig er lang tid...
Ingen kryptering er 100% sikker med du er død af andre grunde inden din 3DES nøgle er brudt.

#16 Men en selvstændig endhed til at stå for krypteringen er ydelsen måske ikke helt så vigtig, så længe den kan følge med skrivningen til harddisken.

#15 Ja, USB-nøglen var også bare et forslag. Man kan gøre ting, der er langt smartere end det, og man kan forbedre sikkerheden med et password som du siger. Men én af idéerne er naturligvis at tage USB-nøglen med når man forlader sin computer.

#18 Sikkerhed er ikke nødvendigvis et spørgsmål om at have noget at skjule. Vi har får hele tiden flere og flere vigtige data på vores computer. I virkeligheden er det måske lidt uheldigt at vores data ikke er bedre beskyttet. Man kan efterhånden meget med sin banknøgle og sin digitale signatur eksempelvis og passwordet er en langt ringere beskyttelse end selve nøglen giver. Du ville jo heller ikke bare lade dit dankort ligge ud flyde fordi du ved at der ikke er andre der kender pin-koden, vel?

Hvad med politiet, kan de bryde den? Hvis ikke er det jo ikke så godt mht børneporne, internetkriminalitet ol.

#21 Helt korrekt, men det er også muligt for sådanne mennesker at kryptere deres drev i dag ved hjælp af den indbyggede kryptering i NTFS-filsystemet i Windows.
Det interessante er her at denne harddisk selv kan gøre det og uden at det går ud over ydelsen.
Typisk fanger man også sådan nogle eksempelvis ved deres brug af kreditkort over nettet eller når de indleverer deres PC til reperation. I det sidste tilfælde er de jo under alle omstændigheder nødt til at udlevere nøglen for at reperatøren kan ordne computeren. Under alle omstændigheder opdager man aldrig børneporno osv. direkte på hvad folk har på deres computer for det er der jo ikke nogen der ser (undtagen reperatøren, selvfølgelig...).

#18 >
Ja eller folk der ikke vil have deres data havner i forkerte folks hænder, har du en laptop med en masse data og den bliver stjålet/glemt, og du ikke har krypteret eller sat andre ting i vejen er det jo nemt at få fat på din data.

#22 Typisk vil politiet jo konfiskere en mistænkts computer fra fx en ransagning, spørgsmålet er så om de kan få fat i bevismaterialet selv om computeren er krypteret...?

#24 Ja, min pointe er bare at de hverken er værre eller bedre stillet end nu, hvor krypteringen foregår i softwaren. Der er ingen der kan forhindre dig i at kryptere dine data ved hjælp af software på den harddisk du har nu. Det kan foregå helt usynligt mens du arbejder med computeren ved hjælp af indbyggede funktioner i Windows.
Og, nej uden nøgle kan de ikke få fat i bevis-materialet. Hele sikkerheden består jo i at andre ikke kan få adgang til data på disken.

Det eneste problem er bare at triple DES er ved at være den alder hvor de fleste algoritme bliver brudt eller bliver for usikre.

#26 Hvad mener du?

#1
truecrypt

#5 Jo det er en gammel nyhed. to uger gammel for at være helt præcis.
http://newz.dk/forum/item/55986/

#29 Jeg mener stadig at double-newz problemet kun kan elimineres ved lade brugerne rate nyheden, når selv admins poster sådanne.

[url=#6]#6[/url] drbravo

Hvis man krypterer med en nøgle, er nøglen så ens password? Og hvad sker der når man skifter password?

Det er et rigtig godt spørgsmål. Der er forskellige måder at gøre det på, og Seagate har mig bekendt ikke fortalt, hvordan de gør. Det er ikke særligt betrygende fordi netop denne del nemt kan indeholde sikkerhedshuller. Kan vi stole på at Seagate ikke har begået en af de fejl, som man kan finde i langt de fleste software implementationer?

En fremgangsmåde er at bruge passwordet selv eller en hashværdi af passwordet som krypteringsnøgle. I så fald er man nødt til at rekryptere hele disken for at skifte password.

En anden fremgangsmåde er at vælge en tilfældig nøgle og så kun kryptere nøglen vha. passwordet. Den krypterede nøgle lægges så i starten af disken. Dermed er det nok at rekryptere nøglen, når passwordet skal skiftes. Men denne fremgangsmåde har en svaghed idet at hvis man kan få fat i både det gamle password og den gamle krypterede nøgle kan man også dekryptere ting, der blev skrevet efter passwordet blev ændret.

Med en passende datastruktur kan man skifte password på en sikker måde uden at rekryptere hele disken. (Hvis du vil vide mere, så hold øje med, hvornår jeg bliver færdig med min PhD afhandling).

[url=#13]#13[/url] mathiass

Sikkerhed. AES er udelukkende bedre fordi nøglen er længere.

Det er ikke rigtigt. DES og 3-DES har kun 64 bits blokke, AES har 128 bits blokke. Blokstørrelsen betyder at en 3-DES nøgle aldrig bør anvendes til mere end ca. 512KB data. Har man 128 bits blokke vil jeg mene det er forsvarligt at anvende samme nøgle til op til 64GB data.

Ved at kryptere 3 gange med 3 forskellige DES-nøgler opnår man i princippet en nøglelængde på 3x56bit = 168 bit, dvs 30 bit mere.

For det første tillader AES nøgler på 128, 192 og 256 bits. For det andet giver 3-DES ikke 168 bits sikkerhed. Grunden til at man i første omgang valgte at bruge DES tre gange og ikke kun to er, at de to gange DES ikke giver nogen væsentlig forbedring af sikkerheden. De to gange DES kunne udsættes for et meet-in-the-middle angreb af kompleksitet 2^56. Angrebet kan også bruges mod 3-DES, men i så fald kan man ikke mødes præcis i midten, men må derimod bruteforce to gange DES på den ene side. Dermed er den reele sikkerhed i 3-DES ikke bedre end 112 bits. Man kan anvende samme nøgle til første og sidste DES krytpering, det giver ingen ekstra sikkerhed at anvende tre forskellige nøgler i forhold til tre krypteringer med blot to forskellige nøgler.

[url=#14]#14[/url] gimli

AES som er nyere, er direkte blevet lavet med det formål at den skulle være software orienteret.

Det er nu ikke helt rigtigt. Kriterierne i AES designet var, at den skulle være effektiv både i software og hardware samt at den skulle være effektiv på både 8 og 32 bits arkitekturer. Læs Rijmen og Daemens oprindelige proposal hvis du vil vide mere.

[url=#16]#16[/url] gimli

AES er også bedre på andre punkter, eks. er block størrelsen jo 128 imod DESs 64. Hvilket fra hvad jeg har forstået giver en mere effektiv og hurtigere algoritme.

Den måde AES er designet på betyder, at performance er stort set uafhængig af blokstørrelsen. Formålet med de større blokke er primært at forbedre sikkerheden.

[url=#22]#22[/url] mathiass

eller når de indleverer deres PC til reperation. I det sidste tilfælde er de jo under alle omstændigheder nødt til at udlevere nøglen for at reperatøren kan ordne computeren.

Er der tale om en hardwarefejl er det jo ikke nødvendigt at kende data for at kunne udbedre den. Og ligger problemet i data på disken, så restorer man jo bare fra en backupkopi. Personligt sletter jeg da altid indholdet af harddisken inden den indleveres til reperation.

[url=#24]#24[/url] jak_tjf

spørgsmålet er så om de kan få fat i bevismaterialet selv om computeren er krypteret...?

Sandsynligvis kan den begrænsede blokstørrelse udnyttes i et birthday attack. Dermed vil krypteringen lække ganske få oplysninger. Sidst nyheden var på newz regnede jeg lidt på, hvor meget man kunne forvente blev lækket. Jeg kom frem til ca. 102 kollisioner på en 500GB disk, som hver lækker 8 bytes.

De otte bytes, der lækkes ved en kollision er XOR af data fra to tilfældige steder på disken. Men når man finder den kan man dog se, hvilke to steder. Lad os antage, at sagen drejer sig om børneporno, og politiet allerede har fundet samme filer hos en anden person. Så kan de gå gennem alle data på tilsvarende offsets i de kendte filer, og lede efter et par, der matcher den XOR værdi kollisionen lækkede.

Hvis dette angreb lykkes har man et kraftigt indicie på, at disse to filer findes på den krypterede harddisk. Finder politiet en håndfuld af den slags synes jeg de skulle prøve dem ved retten. Den sigtede vil sikkert hævde, at det er en tilfældighed. Men hvis han ikke vil udlevere sin nøgle for at bevise, at det er en tilfældighed, så tror jeg han står dårligt.

[url=#28]#28[/url] serpent

truecrypt

Jeg demonstrerede for nyligt en mindre svaghed i den måde TrueCrypt vælger sine IV værdier. Placer denne fil på et filsystem krypteret med TrueCrypt. Hvis man så beregner XOR værdier af alle par af nabosektorer, så vil man pludseligt finde et par, der ikke er tilfældige. Det skræmende er, at mange implementationer af diskkryptering har tilsvarende svagheder.

betyder det at jeg ikke kan flytte min Disk over i en anden computer hvis den er udstyret med den slags kryptering, eller skal jeg så bare have nøglen til den liggende?

Jeg bruger password til at logge ind i Windows, så jeg er allerede beskyttet.. :oD

#31

Meget interssant indlæg. Jeg kan tydeligvis lære noget mere :-)
Specielt det med blokstørrelsens betydning var spændende, kan du uddybe årsagerne lidt, evt et godt link?
Hvad med blowfish 448 bit, kombineret med ex AES. Hvor mange GB kan man sikre?

[url=#34]#34[/url] serpent

Specielt det med blokstørrelsens betydning var spændende, kan du uddybe årsagerne lidt, evt et godt link?

Jeg har ingen links. Mit kendskab til området kommer fortrinsvist fra forelæsninger, foredrag og så de udregninger jeg selv har lavet.

Pointen er at for at en cipher er sikker skal det input man giver til den helst være tilfældigt. Det er derfor man f.eks. anvender CBC mode med et tilfældigt IV. Hvad der er endnu vigtigere end tilfældigt input er, at man ikke bruger samme input mere end en gang, fordi identiske input vil resultere i identiske outputs og kan derfor lokaliseres i de krypterede data.

Tilfældige inputs til cipheren sikrer, at det er usandsynligt, at man bruger det samme input flere gange. Men hvis man bliver ved med at tage tilfældige 64 bits blokke, så vil man før eller siden ramme den samme igen.

De grænser på 512KB og 64GB jeg nævner er jeg kommet frem til på følgende måde. Med en n bits cipherblok kan man ikke opnå en sandsynlighed for kollisioner på 2^-n, da man i sagens natur er nødt til at bruge nøglen mere end en gang. Jeg mener det er rimeligt at sigte efter en risiko for kollisioner på højst 2^-(n/2). Hvis man anvender nøglen 2^(n/4) gange er der i størrelsesordenen 2^(n/2) par som kan kollidere, og som hver kolliderer med sandsynlighed 2^-n. Så bliver sandsynligheden for en kollision højst de 2^-(n/2) jeg sigtede efter.

Det vil sige at jeg mener en god tommelfingerregel er, at en n bits cipherblok nøgle højst må anvendes til n*2^(n/4) bits data. Med en 64 bits blok giver det 64*2^16 bits = 512KB og med en 128 bits blok giver det 128*2^32 bits = 64GB.

Hvad med blowfish 448 bit, kombineret med ex AES.

Jeg kender ikke detaljerne i blowfish algoritmen. Men så vidt jeg kan læse mig frem til på nettet, så kan blowfish anvendes med forskellige nøglestørrelser, men cipherblokkene er altid på 64 bits. Dermed vil en blowfish med 448 bits nøgle stadigt være udsat for de svagheder, der ligger i en 64 bits blokstørrelse.

Hvis man kombinerer to ciphers er det afgørende, hvordan de kombineres. Hvis du f.eks. blot anvender to forskellige ciphers efter hinanden så kunne to ciphers med 64 bits blokke tilsammen give dig en ny cipher med 64 bits blokke og en større nøglestørrelse. Dermed er man stadigt udsat for angreb imod nøglestørrelsen og man er også udsat for meet-in-the-middle angreb som dem jeg beskrev imod 2-DES. Alt-i-alt vil resultatet være, at sikkerheden er ca. det samme som den bedste af de to ciphers.

Det du vinder ved at bruge to ciphers på den måde er altså, at du ikke er udsat den dag der bliver fundet en svaghed i den ene af de to ciphers.

Denne kombination af to ciphers gav altså ikke helt den styrke man kunne håbe på, og den virker kun, hvis de to ciphers har samme blokstørrelse.

En anden måde at kombiner to ciphers er at først lave en CBC mode kryptering med den ene cipher og derefter kryptere resultatet med den anden cipher. Gøres det rigtigt anvendes to uafhængigt genererede tilfældige IV værdier. Det betyder et ekstra spild på pladsen i forhold til en enkelt CBC mode kryptering. Men dog er spildet i et acceptabelt omfang (få procent). Af praktiske årsager ville man nok starte med at anvende cipheren med de største blokke, ellers ville man også spilde plads på padding.

Sikkerheden af denne konstruktion skulle jeg bruge noget mere tid på at analysere, så det vil jeg ikke udtale mig om. Men jeg tror den er mere sikker end blot at sammensætte de to ciphers. Det eneste jeg tør love er igen, at den er mindst lige så god som den bedste af de to ciphers.

For nu at vende tilbage til det oprindelige spørgsmål om, hvor mange data kombinationen af blowfish og AES kan sikre, så tør jeg altså kun sige mindst 64GB. Og da der er tale om en sammensætning af to ciphers med forskellig blokstørrelse vil det kun være den ene af de to konstruktioner man kunne bruge. Og hvad angår spildpladsen ved konstruktionen, så vil en software implementation med faste nøgler bruge 22 fysiske sektorer på hver 21 logiske sektorer. Altså ca. 5% spild.

Nu vi er ved blokstørrelser og filsystemer. Er der nogen der ved hvordan man kan mappe flere bufferheads til samme blok, for senere at remapper dem til forskellige blokke i Linux kernen?
Problemet er at vfs laget er helt vild med bufferheads, så man skal til at ændre en del hvis man ikke bruger bufferheads. Selv hvis man læser et buffer head låst og ikke markerer det dirty før man skal skrive, kan man ikke mappe flere bufferheads til samme blok. Kan man måske ændre lidt på de pages, som bufferheadsne bruger for at få det rigtige resultat?

[url=#36]#36[/url] lean

Nu vi er ved blokstørrelser og filsystemer.

Nu er det vist nogle andre blokke vi snakker om. Diskblokke er noget større end cipherblokke. :-)

hvordan man kan mappe flere bufferheads til samme blok

Giver det overhovedet noget mening? Mener du at b_data skal pege samme sted, eller mener du at de skal pege til samme fysiske sektor på disken? At lade dem pege på samme buffer i hukommelsen er åbenlyst et problem, fordi du så ikke ved, hvor mange buffer heads, der peger på det sted. Det vil også være et problem at have flere buffer heads til at træde hinanden over tæerne, når der skal opdateres. At have to forskellige buffer heads til at pege på samme disksektor er også et problem, for hvilken en er så den rigtige? Bufferne skal jo fungere som cache af diskens indhold, og to forskellige cachede udgaver af samme sektornummer er jo et problem.

Problemet er at vfs laget er helt vild med bufferheads

Er det et problem? Jeg synes det er rigtig smart fordi man så får sektorerne cachet, og undgår at have flere kopier, hvis mange bruger samme sektor.

Jeg fornemmer at du ikke helt har forstået hvordan buffer heads bør bruges. Prøv at forklare, hvad du prøver at opnå, så kan jeg sikkert give et forslag til, hvordan det gøres.

(Skal vi snakke videre om Linux buffer cache burde vi nok smutte et andet sted hen. Er der noget med at man kan oprette sådan en tråd på newz? Eller skal vi smutte over i en usenet gruppe? Jeg hænger ofte ud i comp.os.linux.development.system).