[EiP][Groepsproject] Echt veilige usb stick.

• Alles over de stick is open source en vrij beschikbaar.

Door alles openbaar te laten is het sneller te kraken...
Waarom zou je erg geheime data op een usb-stick willen bewaren die je vervolgens zó kan verliezen?

edit:
Wel een leuk streven hoor, maar ik twijfel aan de haalbaarheid ervan.

[ Voor 14% gewijzigd door sajoku op 13-03-2008 14:17 ]

sajoku schreef op donderdag 13 maart 2008 @ 14:16:
[...]

Door alles openbaar te laten is het sneller te kraken...

Jij hebt het niet begrepen. De veiligste versleutelingsalgoritmes zijn de openbare algoritmes, omdat die uitvoerig door wetenschappers en rekencentra getest kunnen worden. Juist de onveilige algoritmes zijn de 'eigen algoritmes', die door semi-bedrijven en hobbyisten in elkaar geklust worden onder het mom van 'security by obscurity'. Dat is dus net niet wat de TS wil.

Mijn voorstel (zoals die ook al in de EL-kroeg stond)

-een ARM zorgt voor encryptie/decryptie en toegangscontrole
-NAND flash wordt door de ARM AES geencrypt zodat de NAND flash alleen geen waarde heeft.
-Sleutel van AES blijft in de ARM en word gewist als een poging word gedaan om hem te hacken.
-Een pincode (4-8 cijferig) wordt gebruikt als toegangs controle. Is de pincode 3x fout ingetoetst wordt de sleutel vernietigd en kan de USB stick alleen nog geformateerd worden.

Het USB mass storage gedeelte is gedocumenteerd door Atmel: Klik (pdf) ook de code is beschikbaar: Klik (zip)

[ Voor 21% gewijzigd door 0fbe op 13-03-2008 14:36 ]

Tuxie schreef op donderdag 13 maart 2008 @ 14:24:
[...]


Jij hebt het niet begrepen. De veiligste versleutelingsalgoritmes zijn de openbare algoritmes, omdat die uitvoerig door wetenschappers en rekencentra getest kunnen worden. Juist de onveilige algoritmes zijn de 'eigen algoritmes', die door semi-bedrijven en hobbyisten in elkaar geklust worden onder het mom van 'security by obscurity'. Dat is dus net niet wat de TS wil.

My bad!
Ik bedoelde het eigenlijk anders. Als je alle technieken openbaar maakt, dus ook voor potentiele aanvallers is het sneller te kraken. (Dus niet specifiek op het encryptie aspect.)

Ik zeg trouwens niet dat "we" ons eigen algoritme moeten toepassen. Het vertellen dat je een bepaald algroritme gebruikt is in sommige gevallen een aanvaller een aanvalspunt aanreiken.
In de praktijk is dit meestal niet het geval omdat het toch teveel tijd kost om te brute-forcen bijv.

Ik heb nog met mijn vader gepraat over dit project (hij is security specialist). Hij kwam met de volgende opmerkingen:

-Toetsen zijn alleen veilig als ze onhoorbaar zijn. (elke toets geeft een uniek geluid, hiermee kun je met een geluidsopname de sleutel achterhalen)

-Zorg dat de pincode niet te lang is zodat mensen hem gaan opschrijven.

-Geef een policy bij de usb stick waar in staat hoe je er mee moet omgaan.

timcooijmans schreef op donderdag 13 maart 2008 @ 14:31:
Mijn voorstel (zoals die ook al in de EL-kroeg stond)

-een ARM zorgt voor encryptie/decryptie en toegangscontrole
-NAND flash wordt door de ARM AES geencrypt zodat de NAND flash alleen geen waarde heeft.
-Sleutel van AES blijft in de ARM en word gewist als een poging word gedaan om hem te hacken.
-Een pincode (4-8 cijferig) wordt gebruikt als toegangs controle. Is de pincode 3x fout ingetoetst wordt de sleutel vernietigd en kan de USB stick alleen nog geformateerd worden.

Het USB mass storage gedeelte is gedocumenteerd door Atmel: Klik (pdf) ook de code is beschikbaar: Klik (zip)

Hier ben ik het ook eens mee, iig na toevoeging van de door SA007 genoemde keytranslatie chip. Verder is potten in zwarte chemohardende epoxy een goed id.

Ik kan me niet helemaal vinden in het argument van een apparate key controller (alhoewel ik wel moet toegeven dat ik geen idee heb over hoe gemakkelijk het is om met bijv. JTAG een ARM te "hacken") Laten we dus maar voor een apparte key controller gaan. Iemand een voorstel voor zo'n chip? Ik weet dat TI ze maakt maar dan beginnen ze vanaf 10+ USD/stuk...

Edit:
Even gekeken:
Atmel heeft een Secure Serie maar die zijn allemaal alleen onder NDA beschikbaar denk ik (zit zelfs een model tussen dat USB support en ARM is) (AT91SC192192CT-USB of AT90SC6464C-USB)

[ Voor 37% gewijzigd door 0fbe op 13-03-2008 18:56 ]

Vandaag trouwens, dankzij mijn hack, bij een bedrijf langs geweest waar ze o.a. creditcards testen op veiligheid. Hoop geleerd, gezien en bekeken CSI was er niets bij Lasers om de transistors te beinvloeden, stroomverbuirk meten, straling op fracties van een IC bekijken enz. enz.

The contents of the drive are filled with epoxy, so if a hacker tries to physically access the chips, he'd more likely damage them instead. Even if he did get access to the memory chips, they'd be worthless without the encryption chip. Electron-shielded, even a scanning electron microscope can't get inside.

Beide punten zijn inderdaad wel lastig, maar niet onmogelijk met een goed lab. De vraag is alleen, hoever wil je gaan? Zo'n shield kun je omzeilen, maar dan moet je het IC gaan blootleggen, en met een ion beam de shielding zodanig kunnen modificeren dat het IC a; nog steeds werkt, en b; er niets van merkt. En dan kom je dus nog bij de data die encrypted is opgeslagen.

Waarschijnlijk moeten we hem zodanig veilig maken, dat buiten de IC's er niets aan bruikbare data gelezen kan worden. DWZ, 1 IC (uC)wat de USB, password en encrypty doet. En 1 IC waarin de gecodeerde data wordt opgeslagen. Wat er in het IC gebeurt hebben wij toch niet voor het zeggen, want daar is de fabrikant verantwoordelijk voor. Hopen dat dat IC dus een goeie shielding heeft. Data tussen uC en EAM heb je weinig aan, dat is toch al encrypted, en dus uiteindelijk hetzelfde als dat er in het RAM terecht komt.

Op welke manier willen we de sleutel toepassen? Software is niet universeel en mogelijk te omzeilen. Echter kunnen knopjes en hoop storing rondsturen welke is op te vangen, waardoor alsnog is te achterhalen wat de code is. Dat moet dus goed onderdrukt worden.

En wat betreft de self-destruct, 1 van de meest gemaakte fouten: code onjuist? dan aantal pogingen verlagen..... Nee, eerst verlagen, en mocht de code goed zijn, dan de teller resetten. Anders is het mogelijk om te voorkomen dat de code verlaagd wordt door bijv. het IC snel uit te gooien.

SA007 schreef op donderdag 13 maart 2008 @ 20:00:
Via JTAG is het kinderlijk eenvoudig om het programma enzo uit te lezen.

Een key moet je gewoon niet in een general purpose ding doen, zelfs al zou je vanalles kunnen blokkeren, als er een fout zit in 'random' stuk code waardoor je externe code uit zou kunnen voeren heb je direct een lek in het systeem.

Door het code in een apparte beveiligde chip te steken die puur en alleen de key bijhoudt verklein je de kans op programmeerfouten die voor toegang tot de key kunnen zorgen aanzienlijk.

Over de toetsen: Siliconen toetsen zijn stil, al is het wel een idee om er een feedback in de vorm van een piepje of knipperend ledje in te doen.

Over het ingieten in epoxy, het kan opzich, maar zou niet nodig moeten zijn als beveiliging.

@ _ferry_:
knoppen zijn vrij eenvoudig te beveiligen, elke knop duw je gewoon een capicitor naast en een eigen lijn naar de controllerchip.
En opzich is dat ook niet zo boeiend, want dat is alleen dat je het code uit zou kunnen lezen als iemand het invoert.

Normaal via JTAG wel ja maar ook als functies disabled zijn? anyway, als je een voorstel hebt voor een keycontroller laat het maar weten Qua feedback: ik zou 4 ledjes (geven positie van invoeren van de code aan) 1 R/B ledje (locked/unlocked) en 12 knoppen (0-9 + ok en backspace) op het stickje (wat wel wat groter dan een stickje zal worden zo) bestukken

12 knoppen? Dat kost een hoop ruimte! op de corsair padflop zitten er 6, en die is al groot. Elke knop telt daar als 2 mogelijke cijfers, dan kun je bijvoorbeeld zelf zoals bij SMS´en de toets 2x indrukken voor het 2e cijfer. Daarnaast gewoon een rood en groen ledje voor locked-unlocked, en via knipperen kun je bijv. een melding geven zoals een foute code.

[ Voor 22% gewijzigd door _ferry_ op 13-03-2008 22:05 ]

_ferry_ schreef op donderdag 13 maart 2008 @ 22:04:
12 knoppen? Dat kost een hoop ruimte! op de corsair padflop zitten er 6, en die is al groot. Elke knop telt daar als 2 mogelijke cijfers, dan kun je bijvoorbeeld zelf zoals bij SMS´en de toets 2x indrukken voor het 2e cijfer. Daarnaast gewoon een rood en groen ledje voor locked-unlocked, en via knipperen kun je bijv. een melding geven zoals een foute code.

Een knop die je meerdere malen in moet drukken voor een/meerdere getallen heeft echt een waardeloze usecue. Ik kan je dat iig afraden als het bruikbaar moet zijn buiten een select groepje 'techneuten' en kenners.

[ Voor 53% gewijzigd door j-a-s-p-e-r op 13-03-2008 22:14 ]

Als je nou een USB stick uitrust met een bluetooth chippie + antenne. Bij ingebruikname koppel je dat ding éénmalig aan je telefoon. Iedereen heeft een telefoon met bluetooth (nouja, kan er eentje hebben) en de kans dat je die tegelijk met je stick kwijtraakt lijkt me erg klein.
Bij iedere access naar je stick checkt hij eerst of je foon binnen bereik is (~10 meter max), voordat de data wordt vrijgegeven. Giet dat systeem in een bakje epoxy en: happy hacking .

Reptile209 schreef op donderdag 13 maart 2008 @ 22:21:
Als je nou een USB stick uitrust met een bluetooth chippie + antenne. Bij ingebruikname koppel je dat ding éénmalig aan je telefoon. Iedereen heeft een telefoon met bluetooth (nouja, kan er eentje hebben) en de kans dat je die tegelijk met je stick kwijtraakt lijkt me erg klein.
Bij iedere access naar je stick checkt hij eerst of je foon binnen bereik is (~10 meter max), voordat de data wordt vrijgegeven. Giet dat systeem in een bakje epoxy en: happy hacking .

Brr...telefoons zijn nog diefstalgevoeliger dan een usb stick...

Mistraller schreef op donderdag 13 maart 2008 @ 22:35:
[...]

Brr...telefoons zijn nog diefstalgevoeliger dan een usb stick...

Ja, maar niet samen. Je hebt beiden nodig om bij je data te kunnen, en de kans dat je ze alletwee tegelijk "verliest" is dan niet zo groot. Bovendien kan je je foon nog verder "beveiligen" met een pincode, zodat ook de bluetooth niet zomaar te activeren is.

Dus als ik een nieuwe telefoon neem ben ik mn data kwijt?

Desnoods. Dan kopieer je je data elke twee jaar naar een nieuwe ultra-veilige stick voor je nieuwe telefoon-abbo. Je staatsgeheimen mogen wel wat geld kosten toch?
Of zorg er voor dat software de koppeling kan bijwerken als de oorspronkelijke telefoon in de buurt is zodat je kan overstappen.

ja goed, dat beveiliging niet voor een duppie op de eerste rang zitten is, ben ik met je eens. Maar dit gaat toch over een doe-het-zelf usb stick, of zoiets, bedoeld voor 'normale' mensen. Als je je data anders veilig wilt houden dan zou ik een hele grote beveilingsgorilla huren de de stick in zn binnenzak stopt

Ik doel dus ook eigelijk meer op de relatie tussen beveilings(niveau) en de doelgroep.

Leuk hersenspinsel: hoeveel USB-sticks zouden er eigenlijk langer meegaan dan een telefoon? Ze zijn wat meer wasmachinegevoelig zeg maar . Maar je hebt gelijk: ik denk niet dat dit door een hobbyist te bouwen is, maar misschien wel een leuk gat in de markt voor een fabrikant (koppelverkoop met Nokia: bij je nieuwe foon een nieuwe stick )

Onthoud in elk geval 1 ding: Alles is te kraken d.m.v. brute force, maar soms zal dit zo lang duren dat met hier niet aan begint.

Op de flash in de USB stick staat de data.
Stel, je voert op elk stuk data een XOR bewerking uit met behulp van een geheime sleutel.
Deze conversie voer je uit vlak voordat de transparante data op de flash geschreven wordt.

Met de zelfde XOR bewerking kan je de data weer terugvormen. Met een verkeerde sleutel krijg je corrupte data terug (met de kans dat Windows hangt ).


De sleutel moet lang zijn. Met 256 bits kom je al een heel eind, 320 bits is het al aardig onkraakbaar d.m.v. brute force, en 384 bits zou echt veel moeite kosten.

De geheime sleutel moet gemakkelijk te gebruiken zijn. Bijvoorbeeld een irisscan, vingerafdruk of het intypen van een hele zin.
Bedenk wel dat er veel professionele bedrijven hiermee bezig zijn, en dat dit niet zo gemakkelijk uitvoerbaar is.

Kijk, het is inderdaad een goed initiatief, dit project, maar volgens mij kan je het heel goedkoop en simpel houden, om vervolgens nog praktisch iedere groep gebruikers tevreden te stellen. Als je een USB-stick neemt, en daar 2 partitie's op maakt. Vervolgens een static compiled linux, mac os en windows versie van truecrypt opzet, verder inclusief de source en eventuele deps (zijn dr bar weinig volgens mij), dan kan je de tweede, grote partitie gewoon als container van de data gebruiken. Ok, het is met software, maar wel toegankelijk voor praktisch alle os's. Verder is het een stuk goedkoper dan de meeste plannen die ik hoor

Noot: ik heb geen enkele ervaring met (dit soort) elektronica wat dit betreft, dus ik kan te simpel denken. Verder is het zeer zeker wel erg interessant om te lezen

stel.. je neemt een stuk van het geheugen van de microcontroller om de sleutel in op te slaan. de rest van het stuk geheugen vul je met nepsleutels (of random data). de pincode die je in moet vullen, geeft nu het adres van de sleutel. niet direct, maar via een slimme berekening. misschien staat de sleute ook niet op volgorde in het geheugen, maar is ook de volgorde uit de pincode te acterhalen.
de pincode zelf moet natuurlijk ook niet opgeslagen worden, maar een gehashte versie (of een versie die met een public/private key pair ge-enrypt is)

op deze manier kan je proben wat je wil, maar vind je niet de sleutel.

verder moet natuurlijk gedacht worden aan versleten toetsen, en verschillen in het stroomgebruik van de avr bij een foute en een goede pincode (af te luisteren aan de ruis op de voedingslijn).

donzz schreef op donderdag 13 maart 2008 @ 23:23:
stel.. je neemt een stuk van het geheugen van de microcontroller om de sleutel in op te slaan. de rest van het stuk geheugen vul je met nepsleutels (of random data). de pincode die je in moet vullen, geeft nu het adres van de sleutel. niet direct, maar via een slimme berekening. misschien staat de sleute ook niet op volgorde in het geheugen, maar is ook de volgorde uit de pincode te acterhalen.
de pincode zelf moet natuurlijk ook niet opgeslagen worden, maar een gehashte versie (of een versie die met een public/private key pair ge-enrypt is)

Het aantal combinaties blijft even groot als het aantal pincodes.
Stel, de codes 0000-9999 zijn mogelijk. Elke pincode verwijst naar een adres die de juiste sleutel erbij zoekt. Al kan die sleutel een paar miljoen/miljard combinaties bevatten, er zijn toch maar 10000 mogelijkheden om uit te proberen....

en je krijgt er 3 voordat de interne HV generator de flash chip frituurt
[edit:] en waarom niet een pincode van 8 cijfers? dat is niet zo raar... (of nog meer)

[ Voor 36% gewijzigd door AlexanderB op 14-03-2008 01:26 ]

-Toetsen zijn alleen veilig als ze onhoorbaar zijn. (elke toets geeft een uniek geluid, hiermee kun je met een geluidsopname de sleutel achterhalen)

Dan gebruik je optiek of condensator techniek. Deze zijn druktoetsloze schakelaars.

Optiek met licht waar optische kop als knop voorsteld. Hou vinger tegenaan en het wordt gezien als sluiting dmv reflectie. Of je maakt gebruik van camera en virtueel geprojecteerde toetsenbord, welke al bestaat op de markt voor PDA als compact pakket.

Voor echt voor jezelf lezen: maak gebruik van LCD bril dat flikkert, en een veranderende touchscreen waar cijfers voor andere ogen alsmaar verandert. Zonder LCD bril dat zich sluit bij foutieve cijferverdeling en opent bij goede cijfer verdeling heb je dan echt juiste voor je eigen ogen en anderen zonder LCD bril zien alleen maar cijferchaos op de scherm. Meekijken is bijna niet mogelijk meer.
Bekend techniek dat vroeger is gebruikt voor 3D kijken op de scherm.
De verbinding naar de bril kan gecodeerde wireless verbinding zijn, maar meestal optische IR-kabel is beter. Kun je ook niet meer magnetische golven afluisteren.

Bij condensator methode zijn alle toetsen in vorm van 2 metalen contacten of als zogenaamde key-touchpad. Daar druk je dan tegenaan voor weerstand verandering of condensator verstoring. Er is geen geluid of het klinkt overal gelijk.

Ook touchscreen is te doen. Bekend voorbeeld is code intoetsen op HTC telefoon die over touchscreen beschikt en geen nummerieke toetsenbord kent.

[ Voor 26% gewijzigd door MrDummy op 14-03-2008 08:20 ]

Ik weet een veel veiligere methode: als je nu zo'n ding in je lichaam implanteert, dan raak je hem nooit kwijt (want dat is volgensmij het grootste risico met die dingen) en je bent er altijd zelf bij als ie gebruikt wordt.
En als bedrijfsgegevens zo veel waard worden dat het een kidnapping rechtvaardigt qua kosten/risico is het beter om helemaal geen bedrijfsgegevens buiten het bedrijf te laten komen.

AlexanderB schreef op vrijdag 14 maart 2008 @ 01:24:
en je krijgt er 3 voordat de interne HV generator de flash chip frituurt

Ik begrijp even niet waar je hiermee op doelt.

AlexanderB schreef op vrijdag 14 maart 2008 @ 01:24:
[edit:] en waarom niet een pincode van 8 cijfers? dat is niet zo raar... (of nog meer)

Stel je hebt een pincode van 8 cijfers. Dan heb je dus 100 000 000 mogelijke combinaties.
Er is dan minimaal 100 megabyte nodig om een 100 miljoen sleutels van 1 byte (8 bits) lang te onthouden.


Pas als je 27 bits gebruikt heb je 2^27 = 134 217 728 mogelijkheden, en zijn er geen pincodes die de zelfde key opleveren.

Als je de 100 000 000 combinaties x 27 bits doet, heb je 2 700 000 000 bits ruimte nodig.
Als je dit deelt door 8 kom je op 337,5 megabyte aan sleutels.
Hiervoor zal je bijvoorbeeld extra geheugen moeten toevoegen op de USB stick omdat de gehele flash al gebruikt is voor je bestandopslag. Verder moet je dus geen typfouten maken in de 337,5 meg aan sleuteldata.

[ Voor 4% gewijzigd door Onbekend op 14-03-2008 09:33 ]

AlexanderB schreef op vrijdag 14 maart 2008 @ 01:24:
[edit:] en waarom niet een pincode van 8 cijfers? dat is niet zo raar... (of nog meer)

Omdat mensen de code dan gaan opschrijven, een 4 cijferige pincode is al ceilig genoeg als je hem niet kan bruteforcen.

MrDummy schreef op vrijdag 14 maart 2008 @ 08:11:
[...]

Dan gebruik je optiek of condensator techniek. Deze zijn druktoetsloze schakelaars.

Optiek met licht waar optische kop als knop voorsteld. Hou vinger tegenaan en het wordt gezien als sluiting dmv reflectie. Of je maakt gebruik van camera en virtueel geprojecteerde toetsenbord, welke al bestaat op de markt voor PDA als compact pakket.

Voor echt voor jezelf lezen: maak gebruik van LCD bril dat flikkert, en een veranderende touchscreen waar cijfers voor andere ogen alsmaar verandert. Zonder LCD bril dat zich sluit bij foutieve cijferverdeling en opent bij goede cijfer verdeling heb je dan echt juiste voor je eigen ogen en anderen zonder LCD bril zien alleen maar cijferchaos op de scherm. Meekijken is bijna niet mogelijk meer.
Bekend techniek dat vroeger is gebruikt voor 3D kijken op de scherm.
De verbinding naar de bril kan gecodeerde wireless verbinding zijn, maar meestal optische IR-kabel is beter. Kun je ook niet meer magnetische golven afluisteren.

Bij condensator methode zijn alle toetsen in vorm van 2 metalen contacten of als zogenaamde key-touchpad. Daar druk je dan tegenaan voor weerstand verandering of condensator verstoring. Er is geen geluid of het klinkt overal gelijk.

Ook touchscreen is te doen. Bekend voorbeeld is code intoetsen op HTC telefoon die over touchscreen beschikt en geen numerieke toetsenbord kent.

Gaat dit bril id niet te groot worden voor een normale draagbare USB stick

[ Voor 70% gewijzigd door dalus op 14-03-2008 09:42 ]

Onbekend schreef op vrijdag 14 maart 2008 @ 09:32:
[...]

Ik begrijp even niet waar je hiermee op doelt.

Hij bedoeld dat je maximaal 3 keer een fout wachtwoord mag intypen. Hoewel dit theoretisch misschien een goede manier is, is het erg lastig om veilig toe te passen. Je kan namelijk heel moeilijk garanderen dat je counter wel weggeschreven wordt, en op die manier is het dan toch nog mogelijk om te brute forcen.

[...]

Stel je hebt een pincode van 8 cijfers. Dan heb je dus 100 000 000 mogelijke combinaties.
Er is dan minimaal 100 megabyte nodig om een 100 miljoen sleutels van 1 byte (8 bits) lang te onthouden.


Pas als je 27 bits gebruikt heb je 2^27 = 134 217 728 mogelijkheden, en zijn er geen pincodes die de zelfde key opleveren.

Als je de 100 000 000 combinaties x 27 bits doet, heb je 2 700 000 000 bits ruimte nodig.
Als je dit deelt door 8 kom je op 337,5 megabyte aan sleutels.
Hiervoor zal je bijvoorbeeld extra geheugen moeten toevoegen op de USB stick omdat de gehele flash al gebruikt is voor je bestandopslag. Verder moet je dus geen typfouten maken in de 337,5 meg aan sleuteldata.

Ik denk niet dat een lang wachtwoord erg praktisch is, en de eindgebruiker zal toch wel iets vinden om zijn wachtwoord korter te maken.


Misschien is het een goed idee om een challenge te geven voor de PC, hierna moet een wachtwoord ingevoerd worden en versleuteld worden met de challenge. Als deze fout is kan je een time out genereren in de micro waarna deze pas weer een nieuwe challenge verstuurd.

Ik denk dat we de randvoorwaarden van dit project wat moeten aanscherpen. Er worden hier oplossingen genoemd die echt over the top zijn. Ook worden er dingen genoemd die sowieso niet aan de startvoorwaarden voldoen.

Even wat er nu is samenvatten:

• Goedkoop (niet significant duurder dan een onbeveiligde stick dus)
• Niet OS gebonden en zichtbaar als normale stick - key controle moet op de stick dus
• Formaat moet handzaam blijven

Zelf stel ik wel voor om de mogelijkheid te bieden met een los programma de key in te kunnen vullen, maar het moet altijd mogelijk blijven op de stick zelf ook je key in te vullen. Dat kunnen we nog even bekijken.

Als ik kijk naar de lijst uit de TS die ik heb samengevat komt daar 1 woord uit naar voren: consumentenproduct

De beveiliging moet dus goed en gedegen zijn, maar niet perfect. We limiteren ons praktisch al aan een 4 cijferige pincode aangezien langer voor consumenten niet werkt. Het is dan ook even de vraag hoe veilig de chip moet zijn die de crypto operaties doet. Natuurlijk mag je hem niet even simpel met JTAG uit kunnen lezen. Maar aangezien een 'scanning electron microscope' vrij duur is hoeven we hiertegen niet te beveiligen. Iemand die zo ver wil gaan voor je data heeft ook andere methoden om je pincode te achterhalen (gezin ontvoeren werkt vrij goed geloof ik en is nog goedkoper ook).

Dus ik stel voor als extra restrictie:

• Beveiliging hoeft alleen tegen amateurs en semi-professioneel. Zodra de kosten boven 10.000 euro komen om de stick te kunnen kraken hebben we ons doel gehaald.

Uitleg:

pc usb connection: duidelijk, de usb poort zelf
key input: invoer van sleutel

device control: de chip verantwoordelijk voor de controle. NIET de encryptie/decryptie.
Attempt counter: telt het aantal pogingen (vitaal voor mijn 'ontwerp')
data storage: de uiteindelijke data.

Keylist: beveiligde opslag van de sleutel etc.
encrypt/decrypt: de encrypter/decrypter.


Werking:

vóór gebruik registreer je de sleutel, en iets heel belangrijks: de 'mislukte' voorpoging.
Je hebt dan dus 2 of 3 sleutels, afhankelijk van wat je genoeg vind. Deze sleutels worden eenmalig opgeslagen op de keylist, in volgorde.
Hier zit enigzins vrijheid in. Je mag namelijk twee keer ernaast zitten (maar wel nog steeds de juiste volgorde).

Dit word allemaal gecontroleerd op juistheid, en mits correct krijgt de encrypter toegang tot de chip, en kan de data gelezen worden.


Of het heel verantwoord is om 2 of 3 sleutels te moeten invoeren, weet ik niet zeker. De juiste volgorde maakt het echter wel bijna onmogelijk om te brute-forcen, zelfs al heb je de mogelijkheid tot brute-forcen.

Ik zie niet echt het verschil tussen 2 of 3 sleutels in goede volgorde en een gewoon 3x zo lange sleutel. Dus dat maakt theoretisch ook niets uit ivm brute-force.

Ik vraag me af of een brute force niet te voorkomen is met delays, ik bedoel een gebruiker doet er toch enkele (tienden) van seconden over om een code in te voeren. Wanneer je gaat brute forcen doe je dit op een aanzienlijk sneller tempo

Aangezien alles in de stick moet gebeuren zit je volgens mij vast aan een encryptieprocessor.
Daarnaast moet volgens mij moet de feitelijke encryptiesleutel in de stick alleen op RAM terecht komen, anders is er altijd wel een manier om hem uit te lezen.
Dus als je met een password werkt dan wordt de sleutel een afgeleide van een vaste wel opgeslagen waarde en het password. Dus encryptiefunctie(password, constante) = key.
De constante is dan wel opgeslagen, maar het password niet.
Zodra je dan de stick verwijderd is de feitelijke key weg en dus is de data onbruikbaar.

justmental schreef op vrijdag 14 maart 2008 @ 16:25:
Aangezien alles in de stick moet gebeuren zit je volgens mij vast aan een encryptieprocessor.
Daarnaast moet volgens mij moet de feitelijke encryptiesleutel in de stick alleen op RAM terecht komen, anders is er altijd wel een manier om hem uit te lezen.
Dus als je met een password werkt dan wordt de sleutel een afgeleide van een vaste wel opgeslagen waarde en het password. Dus encryptiefunctie(password, constante) = key.
De constante is dan wel opgeslagen, maar het password niet.
Zodra je dan de stick verwijderd is de feitelijke key weg en dus is de data onbruikbaar.

Da's toch het idee van een hash-functie met 'salt'? Daar zat ik ook al aan te denken. Je hoeft de key helemaal niet ergens 'permanent' op te slaan ofzo en vervolgens met je password iets 'unlocken'.

Zit je alleen nog wel met het 'probleem' van het brute-forcen, maar dat blijf je altijd wel houden.

Osiris schreef op vrijdag 14 maart 2008 @ 16:29:
Da's toch het idee van een hash-functie met 'salt'? Daar zat ik ook al aan te denken. Je hoeft de key helemaal niet ergens 'permanent' op te slaan ofzo en vervolgens met je password iets 'unlocken'.

Zit je alleen nog wel met het 'probleem' van het brute-forcen, maar dat blijf je altijd wel houden.

Ik weet niet of hash functies voldoende onvoorspelbaar zijn voor deze toepassing, maar het principe is hetzelfde ja.
Dat bruteforcen kun je wellicht al ondervangen door de stick een seconde te laten doen over het verwerken van het password, dan zit je met 8 tekens al aan de 90000 jaar.

justmental schreef op vrijdag 14 maart 2008 @ 16:34:
[...]

Ik weet niet of hash functies voldoende onvoorspelbaar zijn voor deze toepassing, maar het principe is hetzelfde ja.
Dat bruteforcen kun je wellicht al ondervangen door de stick een seconde te laten doen over het verwerken van het password, dan zit je met 8 tekens al aan de 90000 jaar.

Dus het moraal van dit verhaal: maak nooit een usb-stick die 90000 jaar meegaat?


Verder inderdaad wel een goede methode, was er nog niet eens op gekomen

Hoe gaan we het toelatingssignaal eigenlijk maken?

Het mag niet zomaar een pin zijn die aan is als de sleutel goed is... Dan hoef je er alleen een spanning op te zetten om het te unlocken

Toelatingssignaal? Alle data zit gewoon encrypted in de Flash en zodra het 'opgeroepen' wordt gaat het zeg maar: flash -> decrypter -> USB-interface?

In dat opzichte kun je denk ik wel veel 'jatten' van TrueCrypt. Da's open-source, slaat de data encrypted op en gebruikt alleen (als je geen keyfile gebruikt ) een password -> hash -> key geloof ik. TrueCrypt werd ook al in de Kroeg genoemd IIRC?

Snelheid is hopelijk geen issue overigens? On-the-fly AES decrypten lijkt me niet echt tof voor een mini-chipje met een handjevol MHz-en

Da's denk ik ook het 'probleem' met alle consumer-'secure'-dingen: kijk naar dat voorbeeld hier, snelheid wordt als kernpunt nummero één aangeduid. En gezien het feit dat er software voor nodig is, gebeurt dat decrypten ongetwijfeld op de PC? Wat weer niet de bedoeling is.

[ Voor 35% gewijzigd door Osiris op 14-03-2008 17:25 ]

usb RAID is wel superinteressant moet ik zeggen, je hebt 2 onderdelen nodig om het compleet te maken, de ene te verkrijgen via een webservice ofzo? en de andere op je sticky..!

Is het niet mogelijk om een crossplatform programmaatje te maken dat automatisch opstart en om het wachtwoord vraagt?

Je vult het wachtwoord in, ww wordt verstuurd naar usbstick. Is het wachtwoord goed wordt de "partitie" met het progje gedeactiveerd en de normale partitie geactiveerd.
Is het wachtwoord fout wordt dat in de stick geregistreerd en wordt het programma opnieuw opgestart tot je pogingen op zijn dan wordt alles gereset naar fabriekswaarden.

Op deze manier kan je gewoon je ww intikken op de pc maar blijft toch de volledige controle op de stick.

Een programmaatje hiervoor is niet zo moeilijk. Desnoods kan je verschillende programma's maken voor Windows, Linux of Mac.

MewBie schreef op vrijdag 14 maart 2008 @ 18:09:

Je vult het wachtwoord in, ww wordt verstuurd naar usbstick. Is het wachtwoord goed wordt de "partitie" met het progje gedeactiveerd en de normale partitie geactiveerd.

En nu "hoe" wordt die partitie geactiveerd en gedeactiveerd?

Wat dacht je van een mini computer?
Misschien iets té duur voor dit project...


Ik zal mezelf even veruidelijken:
2 partities:
-partitie 1 is NIET toegankelijk voor de computer, bevat truecrypt
-partitie 2 toegankelijk voor de computer, bevat data

Op de 1ste partitie staat dus truecrypt.
Input naar truecrypt gebeurt via een aantal toetsjes op de usbstick.
Truecrypt laat je die 2de partitie encryptere.


Of zou dit teveel rekenkracht nodig hebben?

Een tijdvertraging inbouwen om bruteforcing tegen te gaan heeft niet veel zin zolang het opensource is.

-> Je kent het algoritme (AES, DES of whatever)
-> Je weet dat de pin 4 cijfers heeft dus er zijn maar 10000 verschillende keys om te decrypten
-> Je weet dat er voorspelbare data in zit. (FAT table)

Soldeer gewoon de flash er uit, lees hem in in de PC en laat er een bruteforcer op los. Je hebt maar 10000 verschillende keys dus je zal al snel een key vinden waar plots na decrypten wonder boven wonder een FAT tevoorschijn komt

Zelfs met het systeem hierboven (van SA007) met een Secure key controller is dat nog te doen. Lees eerst de flash uit en sla de data ergens veilig op. Nu kan je pincodes gaan testen en kijken welke key de keycontroller uitspuwt. Dan heb je op het einde weer een lijstje met 10000 mogelijke keys, die je weer kan gebruiken voor een bruteforce.

[ Voor 26% gewijzigd door flux_w42 op 14-03-2008 22:54 ]

flux_w42 schreef op vrijdag 14 maart 2008 @ 22:46:
Een tijdvertraging inbouwen om bruteforcing tegen te gaan heeft niet veel zin zolang het opensource is.

-> Je kent het algoritme (AES, DES of whatever)
-> Je weet dat de pin 4 cijfers heeft dus er zijn maar 10000 verschillende keys om te decrypten
-> Je weet dat er voorspelbare data in zit. (FAT table)

Soldeer gewoon de flash er uit, lees hem in in de PC en laat er een bruteforcer op los. Je hebt maar 10000 verschillende keys dus je zal al snel een key vinden waar plots na decrypten wonder boven wonder een FAT tevoorschijn komt

Zelfs met het systeem hierboven (van SA007) met een Secure key controller is dat nog te doen. Lees eerst de flash uit en sla de data ergens veilig op. Nu kan je pincodes gaan testen en kijken welke key de keycontroller uitspuwt. Dan heb je op het einde weer een lijstje met 10000 mogelijke keys, die je weer kan gebruiken voor een bruteforce.

Dit klopt niet, de pincode is gekoppeld aan de ic die de key genereert en checkt waarna dat hij met de key die beveiligd is met de pincode de falsh chip gaat decrypten. Zonder die pincode mag je doodleuk gaan bruteforcen, een 256Bit aes key kraak je niet zomaar.

Als je maar 10000 verschillende pincodes hebt, heb je dus ook maar 10000 verschillende keys (iedere pin komt overeen met een andere key).

Als je de data uit de flash veilig kan stellen kan je beginnen kijken welke pin bij welke key hoort door een pin in te geven en te kijken welke key de secure key controller je geeft.

Als je 10000 keys hebt waar er 1 zeker van juist is gelden die 2²⁵⁶ - 10000 andere niet meer, en is je beveiliging plot héééél wat minder sterk (of zie ik het verkeerd?)

Het zwakke punt zit hem in de pincode: die is veel te kort en heft de beveiliging van de sterke encryptie zoals AES op aangezien die vertrouwen op een grote sleutel van 128, 196 of 256 bits.
Een 128 bits sleutel onthouden als pincode is nu eenmaal niet echt handig

flux_w42 schreef op vrijdag 14 maart 2008 @ 22:58:
Als je maar 10000 verschillende pincodes hebt, heb je dus ook maar 10000 verschillende keys (iedere pin komt overeen met een andere key).

Als je de data uit de flash veilig kan stellen kan je beginnen kijken welke pin bij welke key hoort door een pin in te geven en te kijken welke key de secure key controller je geeft.

Als je 10000 keys hebt waar er 1 zeker van juist is gelden die 2²⁵⁶ - 10000 andere niet meer, en is je beveiliging plot héééél wat minder sterk

Het zwakke punt zit hem in de pincode: die is veel te kort en heft de beveiliging van de sterke encryptie zoals AES op aangezien die vertrouwen op een grote sleutel van 128, 196 of 256 bits.
Een 128 bits sleutel onthouden als pincode is nu eenmaal niet echt handig

De keys en pincodes zitten in de secure key controller die een juiste key pin koppel bevat. Dus wat is het probleem van een 4 cijferige pin, na 3 pogingen een selfdestruct en je data is weer veilig

ah, ok. Ik dacht dat de pin gewoon een key selecteerde uit de keycontroller. Verkeerde pin = verkeerde key = rommel uitlezen.

Hoe komt de key/pin combinatie in de controller bij het instellen van een pin? Als de keycontroller een echte random key kan aanmaken, na 3 mislukt pogingen zichzelf wist én de chip is waterdicht beveiligd tegen uitlezen, dan is je stick zo sterk als de gebruikte encryptie. Bij AES 256 bits héél sterk dus

Maxim heeft zo'n chips: de DS36xx series, maar die zien er niet goedkoop uit. Zélfs de datasheet geven ze niet aan iedereen (op de officiële site van maxim-ic toch niet), maar ze zijn waarschijnlijk wel ergens op 't internet te vinden

[ Voor 21% gewijzigd door flux_w42 op 14-03-2008 23:26 ]

flux_w42 schreef op vrijdag 14 maart 2008 @ 23:18:
Als de keycontroller een echte random key kan aanmaken, na 3 mislukt pogingen zichzelf wist én de chip is waterdicht beveiligd tegen uitlezen, dan is je stick zo sterk als de gebruikte encryptie.

Dus moet je alsnog de data ergens anders "minder veilig" opslaan om te voorkomen dat je deze belangrijke data verliest.

Als ik kijk naar de titel van dit topic "Echt veilige usb stick." doet dat probleem er niet toe, en is het niet erg dat de data in zijn geheel wordt gewist.

Er zijn ook USB sticks die een floppy én een removable storage tegelijk zijn. Stel dat je er een chippie in bouwt die de "grote" storage pas presenteert zodra het juiste passwoord gegeven wordt? Dan hoef je ook niet te encrypten etc. Het probleem van solderen etc kan je voor huis-tuin- en keuken gebruik toch prima ondervangen door epoxyhars te gebruiken? Samen met een delay en evt selfdestruct werkt dat wel.
Delays gebruik ik ook op mijn FTP servertje. Werkt zeer effectief. Een delay van 15 seconden overigens, en een disconnect na 2 pogingen.

mensen wat een gezeur over die epoxyhars altijd... dat is volgens mij echt niet de bedoeling van dit project... Als de stick die _ferry_ gehacked heeft ook helemaal in epoxyhars zat, dan was het al een heel stuk moeilijker. Koop anders ff enkele van die sticks (_ferry_ had hem geloof ik als relatiegeschenk van een of ander bedrijf ofzo ?) en 'verbouw' ze met je epoxy, dan heb je je veilige stick... Kortom we moeten gewoon een goede manier bedenken voor encryptie en dergelijke...

Ik vraag me af in hoeverre die pincode->hash->key-generatoren bestand zijn tegen brute-forcen? Want men heeft 't nu wel over 'self-destruct' enzo, maar hoe ver gaat dat? Ennuh, werken die dingen dan met een per chip verschillende salt voor de hash ofzo? Want anders zou je theoretisch een paar duizend van die chips kunnen kopen en per chip X maal proberen

Gelukkig kost dat verder ook helemaal geen tijd ofzo

Nah, true, dat zal wel onder het kopje "idiote in praktijk onhaalbare scenario's" vallen.

Maar uiteindelijk zijn die chips ongetwijfeld te hax0r3n zodat ze níet self-destructen?

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 98% gewijzigd door Ruudjah op 01-12-2009 22:35 ]

Dit lijkt een beetje op mijn id. Ik had als id een helft van de sleutel via pin opslaan en de andere helft op zo'n mini sim kaartje zoals in je telefoon. Opzicht is het wel een stuk veiliger, maar alleen als je beide niet bij elkaar bewaart.

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 94% gewijzigd door Ruudjah op 01-12-2009 22:35 ]

DIT BERICHT IS PREVENTIEF VERWIJDERD DOOR DE GEBRUIKER

[ Voor 96% gewijzigd door Ruudjah op 01-12-2009 22:35 ]

Ruudjah schreef op zaterdag 15 maart 2008 @ 16:17:
Misschien een idee om op een non-encrypted partitie van een paar MB TrueCrypt te zetten? Gewoon, als extra security-laag. Heb je in ieder geval op iedere PC waar je toegang wil hebben tot je data TrueCrypt bij de hand.

Truecrypt heeft admin privileges nodig, dus wss op de meeste openbare pc's niet te gebruiken.

Waarom geen fuses zoals op de Xbox360?

'k heb ook eens lopen denken op een eenvoudige maar relatief veilige oplossing, en het idee van SA007 lijkt mij zeker te doen. Het enige knelpunt qua veiligheid is natuurlijk de random keygenerator en de pin opslag + controle IC. Deze mag in géén geval uitgelezen kunnen worden, moet een echte random key kunnen aanmaken bij het instellen van de PIN en moet na 3 verkeerde pogingen zijn key gewoon wissen.



Zolang de pincode & de key veilig opgeslagen zit in deze chip zitten je gegevens veilig in het flashgeheugen. 't probleem is natuurlijk zo'n µC te vinden . Een PIC heeft wel een fuse waarmee je kan instellen dat het inwendige flashgeheugen beveiligd tegen uitlezen maar ik heb zo mijn bedenkingen bij de betrouwbaarheid daarvan

't ziet er zeker en interessant project uit waar ik actief aan wil meehelpen

Pin opslaan? Key opslaan? Why?

flux_w42 schreef op zaterdag 15 maart 2008 @ 19:57:
'k heb ook eens lopen denken op een eenvoudige maar relatief veilige oplossing, en het idee van SA007 lijkt mij zeker te doen. Het enige knelpunt qua veiligheid is natuurlijk de random keygenerator en de pin opslag + controle IC. Deze mag in géén geval uitgelezen kunnen worden, moet een echte random key kunnen aanmaken bij het instellen van de PIN en moet na 3 verkeerde pogingen zijn key gewoon wissen.

[afbeelding]

Zolang de pincode & de key veilig opgeslagen zit in deze chip zitten je gegevens veilig in het flashgeheugen. 't probleem is natuurlijk zo'n µC te vinden . Een PIC heeft wel een fuse waarmee je kan instellen dat het inwendige flashgeheugen beveiligd tegen uitlezen maar ik heb zo mijn bedenkingen bij de betrouwbaarheid daarvan

't ziet er zeker en interessant project uit waar ik actief aan wil meehelpen

Ja ik heb eens gelezen dat door middel van de voeding spanning te laten fluctueren je toch nog de lockbits kan omzeilen. Hoewel ze die beveiliging ook weer hebben verbeterd.

En waarom heb je een random key generator en pin opslag?

Osiris schreef op zaterdag 15 maart 2008 @ 20:00:
Pin opslaan? Key opslaan? Why?

Voor de pin: Hoe kan je weten of de pin juist is als ze nergens terug te vinden is? Desnoods kan je gewoon de MD5 hash van de pin opslaan, een beetje zoals phpBB forums en dergelijke doen.

Voor de key: Hoe kan je de juiste random key gebruiken om je gegevens te decoderen bij een ingave van een juiste pin, als de chip zelf niet weet wat de key is die hij zelf gegenereerd heeft? Zolang de key er aleen maar uit komt bij een juiste pincode is er toch geen probleem?

HammerT schreef op zaterdag 15 maart 2008 @ 20:49:
[...]
En waarom heb je een random key generator en pin opslag?

Als je je pin instelt (bij het eerste gebruik dus) moet de keygenerator een onvoorspelbare random key aanmaken en opslaan in z'n (niet vluchtig) geheugen. Die key kan dan gebruikt worden om de data te encrypten en dan later weer te decrypten. Zolang er geen juiste pin ingegeven is komt de key op géén enkele manier uit de chip.

Als je de keys er hardcoded inplaatst, zijn ze te achterhalen. Als je de keys laat genereren aan de hand van een ingegeven pin zijn ze ook te achterhalen. Als je het hele project trouwens opensource wil maken, dan mag het niet mogelijk zijn om via de broncode van de firmware te voorspellen welke keys er allemaal kunnen gebruikt worden. Vandaar dus het random genereren.

[ Voor 41% gewijzigd door flux_w42 op 15-03-2008 21:06 ]

Ik ben geen EL-er maar ik vind het RAID0 idee van het begin van het topic helemaal geen slecht idee:

SA007 schreef op donderdag 13 maart 2008 @ 14:09:
Plus, hoe wou je datastriping op 2 usb sticks gaan implementeren als je geen software op de computer mag hebben. De oplossing moet makkelijk vervoerbaar zijn en overal moeten werken zonder dat je eerst raid software moet gaan installeren.

Je kan toch een USB stick maken waar je zelf nog handmatig twee flashmodules in kan prikken? Dan laat je de striping afhandelen door een controller op de stick, geen extra software nodig. Of denk ik veel te simpel?

@ Sebazzz: Als de twee flashchips in dezelfde usbstick zitten is het toch geen probleem om de data gewoon weer ineen te puzzelen? Het idee in het begin van dit topic was dat je dan 2 sticks hebt, die je dan op aparte plaatsen bewaard. Dat is moeilijk te doen als alle twee de flashchips in één en dezelfde stick zitten

ja, maar geen hond die dat echt consequent gaat doen, 2 sticks uit elkaar houden. En stel, je laat je setje in de PC steken waar je bent en je vergeet hem/laat hem eventjes alleen, dan ben je de sigaar.

waarom (voor ons niet haalbaar) niet geewoon alles in 1 chip? waar dus 4 pinnetjes voor usb, en een stel voor de pincode toetsen op zitten, meer niet? word pinmodden veel moeilijker van...

AlexanderB schreef op zaterdag 15 maart 2008 @ 23:39:
waarom (voor ons niet haalbaar) niet geewoon alles in 1 chip? waar dus 4 pinnetjes voor usb, en een stel voor de pincode toetsen op zitten, meer niet? word pinmodden veel moeilijker van...

Omdat er 'geen' chip is met encryptie en veilige keygen.

dan maken we/ze die toch?
questie van alle onderdelen op een wafer bakken...?

flux_w42 schreef op zaterdag 15 maart 2008 @ 20:55:
[...]


Voor de pin: Hoe kan je weten of de pin juist is als ze nergens terug te vinden is?

Vraag dat aan TrueCrypt. Zij zijn in staat om m.b.v. een password te genereren nergens opgeslagen key een partitie/file-whatever te decrypten. Hoe/wat weet ik ook niet, maar t lukt wel? Die key hoef je AFAIK nergens op te slaan.

Niet zo moeilijk, aangezien de gegevens zelf versleuteld zijn.
Zie het paswoord niet als een sleutel die een poort opent, want zo werkt het niet.
Elke sleutel zal een antwoord genereren, enkel de juiste sleutel zal een zinnig antwoord genereren (en dat kan je checken).
Zo hoef je de sleutel nergens op te slaan en kan je toch beveiligen, kijk maar eens op wikipedia hoe bijvoorbeeld RSA werkt.

SA007 schreef op zaterdag 15 maart 2008 @ 22:54:
Je kan ook in de fabriek een random key erin zetten, dat boeit verder niet, random generatie is opzch niet nodig.

Btw, waarom de pin hashen? er zijn maar 10000 combinaties, als je die hash heb heb je 3 seconden later de pin....

Als iedere stick een vaste (random) key krijgt van in de fabriek kan je de key wel achterhalen. Je kan eerst geëncrypteerde de data uit het flashgeheugen veiligstellen. Daarna formatteer je de stick en stel je zelf een nieuwe pincode in. Daarna plaats je de originele data terug en kan je deze decrypten door gewoon je nieuwe pin in te geven

Bij iedere nieuwe pin moet een nieuwe randomkey gegenereerd worden, anders is het te kraken.

Over dat hashen: heeft idd niet veel zin, maar 't is gewoon een extra beveiliging ...

Waarom zou je het mogelijk maken om een nieuwe pin in te stellen als je de oude niet weet?

Iemand die zijn pin vergeten is mag in dat geval zijn hele stick in de vuilbak gooien

En echt random maken in software is zoiezo niet mogelijk.

Het moet ook niet 100% random zijn in de echte zin van het woord. Aangezien het tot een zekere mate beveiligd moet zijn, volstaat een eenvoudiger systeem.

Aangezien de stick tijdens het instellen pin in veilige handen is, kan je bijvoorbeelde de tijd tussen het invoeren van de cijfers als random inputdata gebruiken. of je kan een combinatie van gegevens gebruiken. Je kan teller laten lopen die, als de stick in de PC zit zeer snel beginnen optellen. Als de stick verwijder word sla je de waarde van de tellers op. Bij het weer plaatsen van de stick tel je weer voort, ...

Een aanvaller kan NOOIT exact (tot op enkele us) voorspellen hoe lang de stick in zijn hele levensduur spanning heeft gekregen, dus kan hij ook niet voorspellen welke randomdata er gegenereerd zal worden. Volgens mij volstaat zo'n techniek om basis aanvallen af te slaan (ik spreek nu niet over professionele bedrijven die er hopen geld tegen aan gaan gooien ...)

Wat je dan beter kan doen is vanaf de fabriek er 100? random keys inladen, zovaak verander je je pincode toch niet.

100 verschillende keys ingeven van in de fabriek is ook geen optie. Stel 100x een nieuwe pin in en je hebt weer alle 100 keys waarvan één de juiste is. ik gok dat het géén seconde meer duurt voor je de data daarmee ontcijferd hebt

[ Voor 16% gewijzigd door flux_w42 op 16-03-2008 20:11 . Reden: spelfoutjes ]

flux_w42 schreef op zondag 16 maart 2008 @ 20:07:
Iemand die zijn pin vergeten is mag in dat geval zijn hele stick in de vuilbak gooien

Voorzie ergens een 'reset' button die je pin wist EN je flash formatteert... pin weg, gegevens weg, stick terug

Dan ergens iets invoeren dat als er geen pincode staat ingesteld, dat je stick gaat vragen om een pin in te stellen voor je flash terug toegankelijk wordt... Dan nog ergens een menu inbouwen voor pincode wijzigen: 1x oude pin invoeren en 2x de nieuwe.

Hoe wou je iig de pincode in de stick krijgen?

Misschien is het mogelijk om een soort vn USB device te bouwen... Met je stick een cdtje meegeven (progje vanaf de cd draaien, NIET op de pc installeren) waarop een configuratieprogramma staat, die zoekt ff verbinding met het USB device, en je doorloopt een wizard. Wizard finished, device geconfigureerd en klaar voor gebruik.

Ik ga er vanuit dat er een microcontroller met eigen flashgeheugen vlak voor de flashchip zit.

Een nieuwe pincode instellen gaat als volgt:
Er moet een pootje van de uC naar een '1' getilt worden om een pincode in te stellen.
De pincode komt in het RAM terrecht.
Nadat de nieuwe pincode is ingevoerd, worden er willekeurige getallen in de lokale flash geprogrammeerd, en de externe flash wordt dus nu als FAT geformatteerd aan de hand van de pincode in het RAM en de willekeurig gegenereerde flash data.

Spanning eraf -> weg pincode.
Bij een verkeerde pincode is de flash corrupt.
Na 3x de pin fout, wordt de interne flash weer gevuld met random data, waardoor de flash weer corrupt is.

Voor de duidelijkheid, de pincode staat dus niet in de chip.

je moet wel zorgen dat als er een pinnetje naar 1 getilt wordt, je flash ook gewist wordt. Anders is het voor "de hacker" makkelijk om ff je pinnetje hoog te zetten met een pull-up weerstand of iets dergelijks, ff een nieuwe pincode er in en uitlezen die flash. Of zie ik dit te simpel ?

Op het moment dat het 4e cijfer wordt ingevuld, wordt de flash geformatteerd volgens de codering achter de pincode.

Daarvoor blijft de oude data erin staan, en geldt de oude pincode nog. Een nieuwe pincode genereerd alleen maar corrupte data.

twabi2 schreef op zondag 16 maart 2008 @ 16:10:
Niet zo moeilijk, aangezien de gegevens zelf versleuteld zijn.
Zie het paswoord niet als een sleutel die een poort opent, want zo werkt het niet.
Elke sleutel zal een antwoord genereren, enkel de juiste sleutel zal een zinnig antwoord genereren (en dat kan je checken).
Zo hoef je de sleutel nergens op te slaan en kan je toch beveiligen, kijk maar eens op wikipedia hoe bijvoorbeeld RSA werkt.

Inderdaad, je kan eerst het volume encrypten, en dan een woord/zin/whatever encrypten met dezelfde sleutel, en die erbij toevoegen.

Als je dan de sleutel invult, kan je eerst die toegevoegde informatie decrypten, en als die matcht met wat het moet zijn, klopt de sleutel.

Die extra informatie kan bijvoorbeeld een hash van het wachtwoord zijn. Dus dan krijg je een encrypte hash die decrypted hetzelfde moet zijn als de hash van de sleutel.

pcfreaky1991 schreef op zondag 16 maart 2008 @ 20:58:
je moet wel zorgen dat als er een pinnetje naar 1 getilt wordt, je flash ook gewist wordt. Anders is het voor "de hacker" makkelijk om ff je pinnetje hoog te zetten met een pull-up weerstand of iets dergelijks, ff een nieuwe pincode er in en uitlezen die flash. Of zie ik dit te simpel ?

Je kan niet verhinderen dat ze de flash desolderen en gewoon uitlezen met externe apparatuur. Soldaar daarna de flash weer in de stick, voer een reset uit (die de flash wist), stel een nieuwe pin in, soldeer de flash er weer uit en brand de originele data er in, weer insolderen en je hebt een stick waarvan je de pin weet en dus de data kan ontcijferen

Je kan er gewoon niet van onderuit dat je bij iedere nieuwe pin een nieuwe random key nodig hebt. Dat is trouwens het hele punt van beveiliging: gebruik een totaal onbekende en onvoorspelbare key.

De playstation 3 heeft een hardeschijf
Tot nu toe is het nog niemand gelukt om het uit te lezen, behalve de PS3 zelf.
Als je de hardeschijf ervan op een normale pc aansluit krijg je een onbekende partitie, waarvan je ook geen bestanden e.d. kan afhalen.
- Als iemand het wel kan, hoor ik dat graag.

Misschien moeten jullie gewoon geen FAT bestandssysteem gebruiken maar iets anders. Iets wat niet op een andere manier is uit te lezen dan alleen met jou usb stick. (ook niet even het chipje los solderen en uitlezen)

op mijn K750i zit ook z'n passwordonthoud functie. Eerst vul je een mastercode in (bijv hallo). dan de pincode's die je wilt opslaan (bij 5555).

Hij genereert adhv de mastercode de pincode's. als ik hallo invul, krijg ik dus 5555 terug. Maar als ik halal invul, krijg ik bijv 3bg1 terug (ipv 5555). misschien is zoiets handig ?

hmm is toch hetzelfde als hier eerder gezegd de keys: je duwt pincode in en er wordt een overeenkomende key aangemaakt. Key juist, gegevens tonen.

pcfreaky1991 schreef op woensdag 19 maart 2008 @ 20:53:
hmm is toch hetzelfde als hier eerder gezegd de keys: je duwt pincode in en er wordt een overeenkomende key aangemaakt. Key juist, gegevens tonen.

zoiets wel ja, maar ook als de key onjuist is, worden er gegevens getoond, alleen aangepaste (dus 4dg2 ipv 5555)

Hardwarematig is de uitdaging wat moeilijker dan softwarematig. IC's zijn los te solderen en met extra componenten is het ook zo aan te passen dat je geen code hoeft in te voeren.

Wat als er eerst goed gekeken wordt naar 'openmaken = slopen'?
Oftewel de dikke print vervangen door een dun glasplaatje (zo dik als het glas van een kerstbal ofzo) en dat ingegoten in epoxy (wat uitgehard is als iemand anders de stick in handen krijgt). Lijm weghalen = PCB slopen, en er verder voor zorgen dat de IC's niet in een behuizing zitten, maar ook onder een andere klodder lijm, zoiets als in oude rekenmachines.

Resistor schreef op woensdag 19 maart 2008 @ 21:53:
Hardwarematig is de uitdaging wat moeilijker dan softwarematig. IC's zijn los te solderen en met extra componenten is het ook zo aan te passen dat je geen code hoeft in te voeren.

Daarom is het belangrijk dat de data versleuteld wordt opgeslagen.

flux_w42 schreef op zondag 16 maart 2008 @ 22:21:
[...]
Je kan er gewoon niet van onderuit dat je bij iedere nieuwe pin een nieuwe random key nodig hebt. Dat is trouwens het hele punt van beveiliging: gebruik een totaal onbekende en onvoorspelbare key.

Waarom? de key raakt toch niet gecompromitteerd door het veranderen van de pin?

Voor huis-en tuingebruik kun je wel veronderstellen dat het Flash geheugen binnen in een secure microcontroller voldoende veilig is om niet uitgelezen te kunnen worden behalve door software op die controller zelf (tenzij je begint te FIBen, maar wie heeft thuis zo een toestel staan?)

Het is dus voldoende een paar bestaande uit key (voor dataencriptie; 256bit ofzo) en pincode op te slaan in het Flash (of waarschijnlijk EEPROM of FERAM) geheugen van die controller . Wanneer de juiste pincode wordt ingegeven geeft die controller de key dan door aan de encriptiechip (de key kan hier wel uitgelezen worden, maar alleen als voordien de juiste pincode ingegeven is; voor het bedoelde gebruik is dat dus geen veiligheidsrisico). Een pincode veranderen is simpel: verander alleen de waarde van de pincode, maar blijf dezelfde key voor encryptie gebruiken...

Het enige probleem is wat moet gebeuren als 3 foute inlogpogingen ondernomen zijn: de key moet vernietigd worden (of gewoon permanent gedesactiveerd want hij zit toch in veilig geheugen) en mag dus niet meer herbruikt worden. Hopelijks gebeurt zo iets (in tegenstelling tot pincodes veranderen) niet iedere week; als er een 100-tal spare keys voorzien zijn kan de beveiliging dus 100 keer gereset worden (waarbij uiteraard het flash geheugen definitief onleesbaar wordt) vooraleer alle keys opgebruikt zijn en de usbstick 'opversleten' is.

ls470 schreef op donderdag 20 maart 2008 @ 00:48:
[...]


Waarom? de key raakt toch niet gecompromitteerd door het veranderen van de pin?

[...]

Niet direct nee. Maar bij het ingeven van een juiste pin, moet de key controller zijn key doorgeven aan de chip die het flashgeheugen uitleest en de data encrypt/decrypt? Akkoord?

Dus als de stick dezelfde key gebruikt nadat een aanvaller de pin gereset en opnieuw ingesteld heeft kan een aanvaller de key 'afluisteren'. Hij weet immers de juiste pin (die hij zelf heeft ingesteld) dus zal de keycontroller een key vrijgeven die ook gebruikt is om de vorige data te encrypten. Als je een backup van het originele encrypted flashgeheugen hebt, kan je met de key alles gewoon weer netjes lezen

Als je geheime lijstjes met keys begint te gebruiken, is het project niet volledig open source meer. Eéns dat lijstje keys bekend is is trouwens je hele beveiliging van alle sticks om zeep.
Je zou iedere stick een ander lijstje keys kunnen inbakken maar ik vermoed dat dit niet goedkoop is als dat geproduceerd moet worden. Als je 100 sticks maakt heb je 100 verschillende firmwares nodig

[ Voor 23% gewijzigd door flux_w42 op 20-03-2008 09:08 ]

SA007 schreef op donderdag 20 maart 2008 @ 09:54:
In iedere stick een andere (lijst) key(s) zetten moet toch, en daar heb je geen $aantal firmwares voor nodig, gewoon 1 firmware die als optie heeft om (eenmalig) de keys erin te laden, dan hoef je alleen tijdens het testen van de stick tijdens productie ook de keys erin te laden.

Dan vraag ik mij af of het gewoon niet handiger (en veiliger is) om 1x een firmware te schrijven die een random key kan aanmaken.

flux_w42 schreef op donderdag 20 maart 2008 @ 08:57:
[...]
Niet direct nee. Maar bij het ingeven van een juiste pin, moet de key controller zijn key doorgeven aan de chip die het flashgeheugen uitleest en de data encrypt/decrypt? Akkoord?

Inderdaad, maar dan kent de attacker de pincode en kan hij dus toch sowieso aan de data (of de gebruiker is zo dwaas dat hij nog een geldige code ingeeft op een stick waar iemand aan heeft zitten knoeien)

Dus als de stick dezelfde key gebruikt nadat een aanvaller de pin gereset en opnieuw ingesteld heeft kan een aanvaller de key 'afluisteren'.

Zoals ik zei: bij het resetten (niet bij veranderen in normaal gebruik) moet je inderdaad een andere key nemen, maar dat mag maar zeldzaam voorkomen, zodat niet veel reservekeys nodig zijn.

Als je 100 sticks maakt heb je 100 verschillende firmwares nodig

De firmware zelf (code) is dezelfde, het enige dat je moet doen is een aantal random codes meevoorzien. Aangezien testers nu al soortgelijke (veel chips hebben een individueel serienummer) en veel ingewikkeldere (defecten 'herstellen' op geheugenchips door't programmeren van fuses voor redundante bitlijnen/woordlijnen/...) taken doen lijkt het me dat dat geen probleem mag zijn...

Zoals ik zei: bij het resetten (niet bij veranderen in normaal gebruik) moet je inderdaad een andere key nemen, maar dat mag maar zeldzaam voorkomen, zodat niet veel reservekeys nodig zijn.

Ah, ik dacht dat je alleen een andere key nam als er 3 mislukte pogingen gedaan waren om de pin te raden. Zo is het idd wél veilig. Alleen jammer dat je dan 'maar' 100x je pin mag vergeten.
Een stick zou moeten blijven werken tot hij écht kapot gaat, en niet omdat de keys op zijn

Met een random aangemaakte key kan je zo veel resetten als je wil én het blijft veilig.

misschien een functie in je firmware programmeren die ervoor zorgt dat er 100 random keys in je geheugen zitten. En dan als je bijvoorbeeld onder de 80 komt vult hij ze terug aan ofzo

Om je random key te genereren moet je dan factoren gebruiken die niet te beïnvloeden zijn of niet te voorspellen zijn.

Bijvoorbeeld de tijd dat een USB stick ooit al verbonden is geweest met de PC, in miliseconden.
Je kan het nog moeilijker maken door de volgende methode te gebruiken:

Houd ergens in het eprom geheugen twee tellers bij van 128 bits. Van zodra de usbstick voedingsspanning krijgt haalt hij deze twee waarden uit het eprom, zet ze naar het ramgeheugen en vervangt de twee waarden door de MD5 hash van de opgeslage waarden. Zo bekom je weer 2 tellerwaarden van 128 bits (samen dus 256 bits). Zolang de usbstick spanning krijgt via usb telt hij bij allebei de tellers iedere milliseconde één bij. Als de stick uit de pc gehaald word na een onbekende tijd, worden de waarde van de tellers snel weer opgeslagen in het eprom.

Van zodra de stick weer op een pc aangesloten is word alles weer herhaald:

Tellers uit eprom naar ram verplaatsen
tellers vervangen door de MD5 hashen van de tellers
zolang de stick spanning krijgt: per ms de tellers één bijtellen
als de spanning wegvalt: tellers uit ram weer veiligstellen in eprom
...
enz

Zo krijg je door die MD5 hashen te nemen op een onbekend tijdstip (afhankelijk van hoelang de stick ooit al gebruikt is) een redelijk onvoorspelbaare 256 bits code. Die waarde van de tellers kan je dan gebruiken om een 'random' key uit te genereren. Eventueel kan bij het branden van de firmware bijde tellers een willekeurige startwaarde (en verschillende van elkaar) meegegeven worden.

't is natuurlijk niet écht radom, maar het kan wel voldoen voor onze toepassing én het is niet te beïnvloeden.

[ Voor 4% gewijzigd door flux_w42 op 20-03-2008 23:04 ]