Harddiskencryptie TrueCrypt gekraakt

[Bor]

Een interessant nieuwtje trok mijn aandacht: Passware, een commercieel bedrijf wat software aanbied om o.a. wachtwoorden te kraken / achterhalen of te omzeilen claimed de harddisk encryptie van Truecrypt te kunnen omzeilen.

Een Amerikaans bedrijf beweert dat het de volledige harde schijf versleuteling van TrueCrypt kan omzeilen, zonder het gebruik van brute-force aanvallen. De Passware Kit Forensic haalde eerder al het nieuws met een aanval op Microsoft's BitLocker. Ondanks de sensationele kop van het persbericht, waarin staat dat met TrueCrypt versleutelde schijven binnen minuten zijn te kraken, is de 'aanval' niet zo eenvoudig uit te voeren.

Trots
Passware, dat de software aanbiedt, zou op verzoek van opsporingsdiensten de forensische toolkit hebben aangepast. Die is nu in staat om het geheugen van in beslag genomen computers via FireWire uit te lezen. De software geeft gebruikers zo toegang tot in het geheugen opgeslagen encryptiesleutels. De machine moet in dit geval wel aan staan op het moment van inbeslagname.

"Opsporingsdiensten vroegen om het ontsleutelen van TrueCrypt schijven en we hebben een praktische en effectieve methode ontwikkeld om snel versleutelde gegevens te verkrijgen", aldus Passware president Dmitry Sumin. "We zijn trots om als eerste met een commerciële oplossing te komen die justitie de mogelijkheid geeft om BitLocker en TrueCrypt encryptie van in beslag genomen computers te omzeilen." Al in 2008 demonstreerden onderzoekers dat het mogelijk is om encryptiesleutels uit het geheugen te halen.

Bron: security.nl

Met deze ontwikkeling lijkt de TrueCrypt harddisk encryptie techniek op dit moment niet meer betrouwbaar voor versleuteling van harddisks. De vraag is nu: hoe dient deze zwakheid te worden opgelost?

Voor mij is dit weer een bewijs dat je nooit te veel moet vertrouwen op technische beveiligingsmaatregelen, deze continu dient te controleren en vooral ook te zorgen voor aanvullende andere maatregelen.

Maken jullie gebruik van TrueCrypt harddisk versleuteling?

[ Voor 7% gewijzigd door Bor op 03-04-2010 19:29 ]

[gambieter]

Bor de Wollef schreef op zaterdag 03 april 2010 @ 19:28:
Maken jullie gebruik van TrueCrypt harddisk versleuteling?

Hm, ik versleutel niet hele harde schijven, maar heb een paar volumes gemaakt voor de data die ik open na opstarten met een (lang, cijfers + letters) wachtwoord. Als ik hibernate laat ik ze echter open, omdat je toch moet inloggen voor access.

Ik ben benieuwd wat hier verder uit gaat komen,

[begintmeta]

Wat doen ze eigenlijk? Ik neem naar aanleiding van het bericht aan dat ze iets met het RAM uitspoken. Dat RAM gevoelig is en makkelijk uit te lezen (zeker ook via Firewire) is al lang bekend. En Truecrypt is gericht op beveiliging van gegevens op disks, niet in RAM. Ik denk niet dat er nieuwe aanvallen oid bedacht zijn, alleen zijn bepaalde dingen eventueel makkelijker beschikbaar voor geïnteresseerden.

Zie ook
http://www.truecrypt.org/docs/?s=unencrypted-data-in-ram
en
http://www.truecrypt.org/docs/?s=physical-security

Wil je ook (frozen) ram-aanvallen tegengaan moet je veel meer hard en softwarematige beveiligingen gaan toepassen. Uiteindelijk is je computer dan een smartcard...

[ Voor 4% gewijzigd door begintmeta op 03-04-2010 19:46 ]

[jan99999]

Ze kunnen er alleen achter komen indien je ingelogd ben op je harddisk(die encrypted is), dan kunnen ze via firwire achter je wachtwoord komen. Dus indien pc uit staat gebeurd er niks.
Dus niks van kraken. Dit zal met veel software zijn indien je ingelogd ben dan is ergens op je pc de wachtwoord actief, dus dit zal vaak gaan en is niks nieuws.

[ Voor 6% gewijzigd door jan99999 op 03-04-2010 19:46 ]

[LuckY]

Ja ik gebruik truecrypt met een full disk encryptie. Maar mijn firewire staat uit, en er zijn wel andere manieren om het te omzeilen, immers als je laptop gelocked is, kan je een rechtstreekse DMA attack op windows uitvoeren om zo het password te pakken, dan kan je inloggen en de image trekken voor forensisch onderzoek.

Als ik mijn laptop vervoer staat die uit, mocht ik iets illegaal op mijn pc hebben en ik kijk door mijn deur kijkgat, kan ik altijd nog mijn laptop uitzetten... voor de rest staat die 9/10 keer uit als ik niet thuis ben.

Ik ben eerlijk gezegd banger voor de evil-maid aanval dan deze aanval.

Tevens wordt in deze methode niet echt truecrypt gekraakt, immers dat is bijna niet te doen, want elke laptop kan zijn eigen algoritme kiezen
Maar wel een leuk artikel voor een discussie

[Bor]

jan99999 schreef op zaterdag 03 april 2010 @ 19:46:
Ze kunnen er alleen achter komen indien je ingelogd ben op je harddisk(die encrypted is), dan kunnen ze via firwire achter je wachtwoord komen. Dus indien pc uit staat gebeurd er niks.
Dus niks van kraken. Dit zal met veel software zijn indien je ingelogd ben dan is ergens op je pc de wachtwoord actief, dus dit zal vaak gaan en is niks nieuws.

Niets nieuws wil ik dit aboluut niet noemen. Het blijkt namelijk mogelijk om het wachtwoord blijkbaar ergens uit het geheugen uit te lezen en te gebruiken. Het was tot voor kort niet bekend dat dit bij rueCrypt mogelijk was. Het feit dat de procedure via firewire gaat maakt het wat mij betreft nog interessanter. Ik vraag mij af hoe men firewire gebruikt om de beveiliging te omzeilen en of dit in principe ook mogelijk is met bv USB.

[Kompaan]

Via Firewire kan je direct je geheugen aanspreken, via USB niet.


Deze "truuk" die ze hier uithalen is volgens mij ook niet specifiek aan TrueCrypt... Alle full disk encryption moet een key in het geheugen hebben om te kunnen decrypten. Of je moet aan een tpm gaan natuurlijk...

[LuckY]

Bor de Wollef schreef op zaterdag 03 april 2010 @ 19:50:
[...]


Niets nieuws wil ik dit aboluut niet noemen. Het blijkt namelijk mogelijk om het wachtwoord blijkbaar ergens uit het geheugen uit te lezen en te gebruiken. Het was tot voor kort niet bekend dat dit bij rueCrypt mogelijk was. Het feit dat de procedure via firewire gaat maakt het wat mij betreft nog interessanter. Ik vraag mij af hoe men firewire gebruikt om de beveiliging te omzeilen en of dit in principe ook mogelijk is met bv USB.

Verdiep je eens in DMA

En hier heb je er nog een filmpje over, hoe ze met DMA snel je laptop kunnen unlocken. Dit kan volgens mij ook gewoon over USB.

If an attacker can physically access the computer hardware and you use it after the attacker has physically accessed it, then TrueCrypt may become unable to secure data on the computer.* This is because the attacker may modify the hardware or attach a malicious hardware component to it (such as a hardware keystroke logger) that will capture the password or encryption key (e.g. when you mount a TrueCrypt volume) or otherwise compromise the security of the computer. Therefore, you must not use TrueCrypt on a computer that an attacker has physically accessed. Furthermore, you must ensure that TrueCrypt (including its device driver) is not running when the attacker physically accesses the computer. Additional information pertaining to hardware attacks where the attacker has direct physical access is contained in the section Unencrypted Data in RAM.

jan99999 schreef op zaterdag 03 april 2010 @ 19:46:
Ze kunnen er alleen achter komen indien je ingelogd ben op je harddisk(die encrypted is), dan kunnen ze via firwire achter je wachtwoord komen. Dus indien pc uit staat gebeurd er niks.
Dus niks van kraken. Dit zal met veel software zijn indien je ingelogd ben dan is ergens op je pc de wachtwoord actief, dus dit zal vaak gaan en is niks nieuws.

Mits het schoon is afgesloten alsdus de Truecrypt links van begintmeta in "Harddisk encrypte TrueCrypt gekraakt"

Inherently, unencrypted master keys have to be stored in RAM too. When a non-system TrueCrypt volume is dismounted, TrueCrypt erases its master keys (stored in RAM). When the computer is cleanly restarted (or cleanly shut down), all non-system TrueCrypt volumes are automatically dismounted and, thus, all master keys stored in RAM are erased by the TrueCrypt driver (except master keys for system partitions/drives — see below). However, when power supply is abruptly interrupted, when the computer is reset (not cleanly restarted), or when the system crashes, TrueCrypt naturally stops running and therefore cannot erase any keys or any other sensitive data. Furthermore, as Microsoft does not provide any appropriate API for handling hibernation and shutdown, master keys used for system encryption cannot be reliably (and are not) erased from RAM when a computer hibernates, is shut down or restarted.**

[begintmeta]

Bor de Wollef schreef op zaterdag 03 april 2010 @ 19:50:
Niets nieuws wil ik dit aboluut niet noemen. Het blijkt namelijk mogelijk om het wachtwoord blijkbaar ergens uit het geheugen uit te lezen en te gebruiken. Het was tot voor kort niet bekend dat dit bij rueCrypt mogelijk was.

Het is denk ik toch echt niets nieuws, de links die ik plaatste (en de algemene redeneringen erachter) zijn al lager bij TrueCrypt en elders bekend en public.

Het feit dat de procedure via firewire gaat maakt het wat mij betreft nog interessanter. Ik vraag mij af hoe men firewire gebruikt om de beveiliging te omzeilen en of dit in principe ook mogelijk is met bv USB.

AFAIK (maar IANAH) zijn er vooralsnog geen met firewire vergelijkbare problemen met USB gevonden.

@LuckY: Smartcards&readers zijn tegenwoordig niet meer zo duur en worden vaak prima ondersteund, en anders zijn er opties met usb-keys oid te bedenken. Maar helemaal veilig krijg je het nooit als iemand fysieke toegang kan hebben.

[SH4D3H]

Bor de Wollef schreef op zaterdag 03 april 2010 @ 19:50:
[...]


Niets nieuws wil ik dit aboluut niet noemen. Het blijkt namelijk mogelijk om het wachtwoord blijkbaar ergens uit het geheugen uit te lezen en te gebruiken. Het was tot voor kort niet bekend dat dit bij rueCrypt mogelijk was. Het feit dat de procedure via firewire gaat maakt het wat mij betreft nog interessanter. Ik vraag mij af hoe men firewire gebruikt om de beveiliging te omzeilen en of dit in principe ook mogelijk is met bv USB.

Als je de volumes in gebruik hebt, is het toch logisch dat de sleutel ook ergens beschikbaar moet zijn. Dat deze sleutel blijkbaar makkelijk leesbaar in het geheugen staat is wellicht 'nieuws', maar dat de sleutel in het geheugen staat niet natuurlijk.

Als de PC gewoon uit staat op het moment van de 'inval', is je data nog steeds veilig.

[ Voor 45% gewijzigd door SH4D3H op 03-04-2010 19:59 ]

[Bor]

SH4D3H schreef op zaterdag 03 april 2010 @ 19:58:
[...]

Dat deze sleutel blijkbaar makkelijk leesbaar in het geheugen staat is wellicht 'nieuws', maar dat de sleutel in het geheugen staat niet natuurlijk.

Zeker, wat mij wel verbaast is dat er voor zover bekend alleen firewire nodig is om de sleutel daadwerkelijk te verkrijgen. Zou deze aanval sporen op het systeem nalaten? Doet TrueCrypt bv iets aan timestamping ahdv access datum en tijd?

[Equator]

Och, wat een oude methode.. Op zo'n manier is de encryptie van (nu McAfee) Safeboot ook al een keer 'gekraakt'. DMA access en de sleutel stond leesbaar (voor zover je dat leesbaar noemt) in het memory.

Daar is overigens toen geen echte ruchtbaarheid aan gegeven.

Dat TrueCrypt ook vergeten is om de sleutel encoded/encrypted in het geheugen weg te schrijven is jammer.

[Onbekend]

Equator schreef op zaterdag 03 april 2010 @ 20:39:
Dat TrueCrypt ook vergeten is om de sleutel encoded/encrypted in het geheugen weg te schrijven is jammer.

Ik denk dat ze dat wel gecodeerd wegschrijven, maar dat die encryptie is gekraakt waardoor ze nu ook de data zelf uit kunnen lezen.

[BamSlam_]

Ben ik blij dat ik een laptop zonder firewire-poort bezit

Enne.. als de politie binnenvalt dus meteen de stekker uit je PC trekken!

[ Voor 40% gewijzigd door BamSlam_ op 03-04-2010 20:49 ]

[begintmeta]

Equator schreef op zaterdag 03 april 2010 @ 20:39:
...

Dat TrueCrypt ook vergeten is om de sleutel encoded/encrypted in het geheugen weg te schrijven is jammer.

Krijg je dan niet snel sowieso al snel een soort security by obscurity met de huidige hardware? Ofwel, zou dat niet ook onzinnig zijn?

Een TPM-module smartcard of andere oplossing voor een gescheidenere en veiligere opslag van sleutels/challenge-response aangelegenheden & RAM toegang biedt eventueel wel iets meer veiligheid.

[ Voor 27% gewijzigd door begintmeta op 03-04-2010 21:02 ]

[serkoon]

Wat heeft het voor zin om een sleutel encrypted op te slaan in het geheugen als je de sleutel voor die encryptie ook in je geheugen moet bewaren? Wil je de sleutel waarmee de sleutel wordt gecodeerd ook weer encrypten?

Waar het in dit topic om gaat is simpel: disk encryptie werkt tegen diefstal van disk of systeem, -alleen- als dat systeem uit staat. Staat het systeem aan, dan is de sleutel per definitie te achterhalen. TrueCrypt beschermt niet tegen een attack waarbij een volume gemount is en het systeem draaiend in handen van de attacker komt.

Het enige dat nieuw is, is dat er een bedrijf een programma gemaakt heeft dat de TrueCrypt encryptiesleutel uitleest, zodat opsporingsdiensten relatief eenvoudig TrueCrypt encrypted disks kunnen decrypten. Dit uiteraard mits ze een draaiend systeem in handen krijgen.

[LuckY]

BamSlam_ schreef op zaterdag 03 april 2010 @ 20:46:
Ben ik blij dat ik een laptop zonder firewire-poort bezit

Enne.. als de politie binnenvalt dus meteen de stekker uit je PC trekken!

Waardoor de data nog in het ram staat, en hun snel het ram kunnen bevriezen en je key hebben.
Het volume moet netjes afgesloten worden, dan worden de keys verwijderd.

[Verwijderd]

Die attack is echt al zo oud als de weg naar Rome. Dit is trouwens niet specifiek voor TrueCrypt. Elke encryptie moethode is vatbaar voor een cold boot attack. Dit komt omdat de encryptie sleutel altijd in het geheugen moet worden bewaart. Wanneer je je pc uitzet is het geheugen altijd nog enekele minuten uit te lezen, spray je hem om met stikstof dan nog veel langer. Vervolgens kun je hier de sleutel uit halen.

Het nieuws is nu dat er een commerciële tool voor is welke het via Firewire doet. Dit komt doordat Firewire DMA (direct memory access) heeft. Wie zo stom is om wel full disk encryption toe te passen, maar vervolgens DMA voor externe poorten toestaat vraagt er ook zelf om.

Je kunt wel je geheugen insmeren met hars zodat je hem niet op tijd lost krijgt voor een cold boot attack. Een aantal bullet-proof hosting providers doen dit.

Equator schreef op zaterdag 03 april 2010 @ 20:39:
...

Dat TrueCrypt ook vergeten is om de sleutel encoded/encrypted in het geheugen weg te schrijven is jammer.

De sleutel hiervoor moet vervolgens ook in het geheugen staan, dus dit zou een nutteloze extra feature zijn. Misschien wel goed als marketing paartje though.

[ Voor 18% gewijzigd door Verwijderd op 03-04-2010 20:59 ]

[Nvidiot]

Let wel: als je laptop geen firewire heeft kun je alsnog kwetsbaar zijn voor deze aanval, door middel van een PCMCIA / Express Card kaartje met een firewire poort. Windows heeft hier standaard drivers voor. Kaartje inpluggen en je hebt alsnog een werkende firewire poort!

[Wouter.S]

serkoon schreef op zaterdag 03 april 2010 @ 20:52:
TrueCrypt beschermt niet tegen een attack waarbij een volume gemount is en het systeem draaiend in handen van de attacker komt.

Als het volume gemount is en het systeem komt draaiend in handen van een attacker kan die toch ook gewoon copy-pasten vanaf dat volume? Geen nood voor firewire-hacks lijkt me zo.

Verder is er in mijn ogen helemaal niets gekraakt. De enige manier om een de bestanden die beveiligd zijn te verkrijgen is als je de pc die aan staan weet te bemachtigen. Dit is toch helemaal niet kraken maar gewoon uitbuiten van de toestand van het systeem. Als ze je met een pistool dwingen het correcte wachtwoord in te geven (niet van het fake volume...) zullen ze ook aan je data geraken, hebben ze de beveiliging dan ook gekraakt ?...

[BamSlam_]

Nvidiot schreef op zaterdag 03 april 2010 @ 21:01:
Let wel: als je laptop geen firewire heeft kun je alsnog kwetsbaar zijn voor deze aanval, door middel van een PCMCIA / Express Card kaartje met een firewire poort. Windows heeft hier standaard drivers voor. Kaartje inpluggen en je hebt alsnog een werkende firewire poort!

Heb het nog even gechecked, maar mijn laptop heeft ook geen PCMCIA / Express Card-slot (serieus, Acer Aspire 5715Z).

Wouter.S schreef op zaterdag 03 april 2010 @ 21:06:
Als het volume gemount is en het systeem komt draaiend in handen van een attacker kan die toch ook gewoon copy-pasten vanaf dat volume? Geen nood voor firewire-hacks lijkt me zo.

Schaakmat. Tenzij het zaakje gelocked is en alleen kan worden geunlocked door de gebruiker of een administrator.

[ Voor 28% gewijzigd door BamSlam_ op 03-04-2010 21:10 ]

[Bor]

Wouter.S schreef op zaterdag 03 april 2010 @ 21:06:
[...]


Als het volume gemount is en het systeem komt draaiend in handen van een attacker kan die toch ook gewoon copy-pasten vanaf dat volume? Geen nood voor firewire-hacks lijkt me zo.

Als het systeem draait maar het OS bv gelocked is kom je niet erg ver tenzij je op een andere manier direct access weet te verkrijgen.

[serkoon]

Je kunt wel je geheugen insmeren met hars zodat je hem niet op tijd lost krijgt voor een cold boot attack. Een aantal bullet-proof hosting providers doen dit.

Dat heeft ook alleen maar zin als de attacker zo stom is om het systeem uit te zetten zonder eerst fysiek toegang tot het geheugen te hebben verschaft. Tamperdetectie en vervolgens vernietiging van de sleutels lijkt me effectiever

[ Voor 4% gewijzigd door serkoon op 03-04-2010 21:19 ]

[Verwijderd]

Wouter.S schreef op zaterdag 03 april 2010 @ 21:06:
[...]


Als het volume gemount is en het systeem komt draaiend in handen van een attacker kan die toch ook gewoon copy-pasten vanaf dat volume? Geen nood voor firewire-hacks lijkt me zo.

Je moet je laptop natuurlijk ook nooit ongelockt achter laten

[Verwijderd]

serkoon schreef op zaterdag 03 april 2010 @ 21:18:
[...]

Dat heeft ook alleen maar zin als de attacker zo stom is om het systeem uit te zetten zonder eerst fysiek toegang tot het geheugen te hebben verschaft. Tamperdetectie en vervolgens vernietiging van de sleutels lijkt me effectiever

Dat is absoluut effectiever, alleen is security altijd een afweging tussen kosten en baten. De vraag is waar je je tegen wilt beschermen en hoeveel resources dat type attacker heeft.

[serkoon]

Verwijderd schreef op zaterdag 03 april 2010 @ 21:21:
Dat is absoluut effectiever, alleen is security altijd een afweging tussen kosten en baten. De vraag is waar je je tegen wilt beschermen en hoeveel resources dat type attacker heeft.

Het is, zover ik weet (en ik weet niet zoveel), standaard procedure bij overheden om systemen draaiende mee naar het lab te nemen om ze daar te analyseren. Een beetje hars zal daar niet echt een probleem zijn..

[begintmeta]

Komt dan altijd weer bij me op...

[Verwijderd]

serkoon schreef op zaterdag 03 april 2010 @ 21:35:
[...]

Het is, zover ik weet (en ik weet niet zoveel), standaard procedure bij overheden om systemen draaiende mee naar het lab te nemen om ze daar te analyseren. Een beetje hars zal daar niet echt een probleem zijn..

Sommige instanties moet je ook niet tegen je hebben

Bij ons op de opleiding (security) leerden we over 3 type attackers:
- de buitenstaander die er baat bij heeft om jou systeem binnen te dringen.
- de werknemer die boos is (ontslagen werknemer bijv).
- de grote instanties als CIA en de maffia.

De eerste is gevaarlijk, maar nog lang niet zo gevaarlijk als de tweede (die heeft immers als werknemer bepaalde privilege's en kan gemakkelijker social engineering toepassen). De laatste categorie doe je werkelijk helemaal niks aan, als die jou gegevens willen dan krijgen ze die, goedschiks of kwaadschiks.

Dingen als het geheugen insmeren met hars helpen nooit tegen alle type aanvallers, het vergroot alleen wel de complexiteit van een aanval. Je beschermt je dan wel tegen een heel ander type attacker.

[ Voor 9% gewijzigd door Verwijderd op 03-04-2010 22:00 ]

[serkoon]

Verwijderd schreef op zaterdag 03 april 2010 @ 21:58:

Sommige instanties moet je ook niet tegen je hebben

True. Bij bulletproof hosting denk ik aan criminelen die hun botnet masters hosten. Overheden zijn dan hun adversaries.

Bij ons op de opleiding (security) leerden we over 3 type attackers:
- de buitenstaander die er baat bij heeft om jou systeem binnen te dringen.
- de werknemer die boos is (ontslagen werknemer bijv).
- de grote instanties als CIA en de maffia.

Ik ken het onderscheid als:
- Standaard buitenstaander, maar ook insider die je systemen wil hacken voor de lol, niet specifiek of, in geval van insider uit wraak.
- Criminelen of concurrenten die je bedrijfsgeheimen willen bemachtigen.
- Overheden of (eventueel door overheden betaalde) terroristen

Dingen als het geheugen insmeren met hars helpen nooit tegen alle type aanvallers, het vergroot alleen wel de complexiteit van een aanval. Je beschermt je dan wel tegen een heel ander type attacker.

Je beschermt je zelf er niet tegen (mijn) type 1, want die gaan niet fysiek bij je langs. Type 2 misschien, maar eigenlijk met name type 3 zal fysiek systemen meenemen. En die hebben juist genoeg resources om geen last van je bescherming te hebben. Ik vraag me dus af of het uberhaupt nuttig is.

[Nvidiot]

Ook type 3 heeft geen ongelimiteerde resources. Het hangt er dus vanaf wat er op je laptop staat dat zo ernstig is dat ze daar veel moeite voor gaan doen. Voor kinderporno o.i.d. zullen ze wellicht de firewire truuk nog proberen, maar als dat niet werkt en je hebt je RAM chips vastgesmolten in hars verwacht ik dat ze het opgeven. Is het de laptop van een spion, dan zullen ze wellicht meer moeite doen.

[webcamjan]

Geheugen uitlezen kan zolang het toestel onder spanning blijft. leuk zeg.

Maar wat nu als ik mijn systemen op (en staan ze op) een apparte spannings lijn heb staan welke middels een radiografisch signaal onderbroken kan worden dmv vaan een zender in mijn broekzak. Na de inval mag nergens meer aankomen en moet ik in een hoekje staan zodat "de mannen" hun werk kunnen doen, en daar sta ik dan met de handen in de zakken te niksen. ik ben gelijk geboeid.? ook een fluitmelodie herkenning kan dit. riedel de riedel.

Ploef.......................................... stroom uit voor ze hun pack konden aansluiten.

En toen.? Ik stond daar maar te niksen met of zonder boeien.

Bedoel beetje nadenkend mens zorgt dat zijn spullen zo zijn ingericht dat het op dit soort dingen is voorbereid.
Net als mensen die geloven dat data backuppen van thuis in een datacentra safe is,, duh ook daar kan een vliegtuig op storten en dan.? data weg.
Data vloeren gemaakt in oude kantoor panden bedoel hoe safe is dat is tegen mollest van buiten.?

Kortom bij alles is de regel hoever wil je gaan voor en om je doel te bereiken.?

[Verwijderd]

Je kunt altijd nog een cold boot attack doen he, data blijft nog ong 10 minuten aanwezig in het geheugen.

Verder is een gescheiden stroom circuit nogal een dure ondernemening, je kunt beter gewoon DMA voor FireWire uitzetten, dat is goedkoper en gemakkelijker.

Daarnaast ga jij er gelijk van uit dat je je gegevens versleuteld heb om uit handen van justitie te blijven. Dit is natuurlijk bij lang niet iedereen het geval. Meeste mensen versleutelen hun data zodat deze niet zomaar in slechte handen kan vallen.

[ Voor 74% gewijzigd door Verwijderd op 07-04-2010 07:43 ]

[LuckY]

webcamjan schreef op woensdag 07 april 2010 @ 04:36:
Geheugen uitlezen kan zolang het toestel onder spanning blijft. leuk zeg.

Maar wat nu als ik mijn systemen op (en staan ze op) een apparte spannings lijn heb staan welke middels een radiografisch signaal onderbroken kan worden dmv vaan een zender in mijn broekzak. Na de inval mag nergens meer aankomen en moet ik in een hoekje staan zodat "de mannen" hun werk kunnen doen, en daar sta ik dan met de handen in de zakken te niksen. ik ben gelijk geboeid.? ook een fluitmelodie herkenning kan dit. riedel de riedel.

Ploef.......................................... stroom uit voor ze hun pack konden aansluiten.

En toen.? Ik stond daar maar te niksen met of zonder boeien.

Obstructie van de rechtsgang? en wat als ze je meenemen en je fouilleren dan vinden ze de afstandsbediening...
Maar ze kunnen nog steeds snel je geheugen bevriezen, waardoor ze de data eruit kunnen halen zoals karmose zegt.

Bedoel beetje nadenkend mens zorgt dat zijn spullen zo zijn ingericht dat het op dit soort dingen is voorbereid.
Net als mensen die geloven dat data backuppen van thuis in een datacentra safe is,, duh ook daar kan een vliegtuig op storten en dan.? data weg.

Hoezo, de backup is weg de data bestaat nog en dan kan je zelf actie te ondernemen om een andere backup te maken.

Data vloeren gemaakt in oude kantoor panden bedoel hoe safe is dat is tegen mollest van buiten.?
Kortom bij alles is de regel hoever wil je gaan voor en om je doel te bereiken.?

Data vloeren zijn gemaakt voor het makkelijker wegwerken van kabels, voor de airflow en voor wateroverlast.

en die regel tjah, dat is gewoon common sense

[Equator]

Verwijderd schreef op zaterdag 03 april 2010 @ 20:57:
[...]
De sleutel hiervoor moet vervolgens ook in het geheugen staan, dus dit zou een nutteloze extra feature zijn. Misschien wel goed als marketing praatje though.

Hardcoded algoritmes, of gewoon een e.o.a. obscuur encoding regeltje. Stukje obscurity welliswaar maar zeker niet onmogelijk. Andere pakketten zijn hier niet kwetsbaar, dus moet er een oplossing zijn. Ook al is deze gewoon nog niet bekend

Het is en blijft lastig natuurlijk.

[RedHat]

Ik weet dat een hoop pedofielen TrueCrypt gebruiken. Dat heb ik ooit eens gezien bij Alberto Stegeman. Dus ik hoop eigenlijk wel op een 'doorbraak' zodat een hoop pedofielen alsnog veroordeeld kunnen worden.

[Rukapul]

Equator schreef op donderdag 08 april 2010 @ 09:23:
[...]

Hardcoded algoritmes, of gewoon een e.o.a. obscuur encoding regeltje. Stukje obscurity welliswaar maar zeker niet onmogelijk. Andere pakketten zijn hier niet kwetsbaar, dus moet er een oplossing zijn. Ook al is deze gewoon nog niet bekend

Het is en blijft lastig natuurlijk.

Dit is een van de weinige punten waarbij open source een handicap biedt. Verbergen van sleutels berust per definitie op een tamper-proof systeem. Bij software komt dit neer op obfuscatie en daarbij geldt over het algemeen hoe meer obfuscatie en onduidelijkheid hoe groter de potentiele tamper-proofness. Met de broncode ernaast is het makkelijker zoeken.

RedHat schreef op donderdag 08 april 2010 @ 09:26:
Ik weet dat een hoop pedofielen TrueCrypt gebruiken. Dat heb ik ooit eens gezien bij Alberto Stegeman. Dus ik hoop eigenlijk wel op een 'doorbraak' zodat een hoop pedofielen alsnog veroordeeld kunnen worden.

Er zijn meer manieren om bewijs te vergaren. Mensen maken veel fouten.

Ik zou vooral niet terug willen naar de tijden met verplicht zwakke systemen, key escrow, etc.

[ Voor 24% gewijzigd door Rukapul op 08-04-2010 09:34 ]

[begintmeta]

Equator schreef op donderdag 08 april 2010 @ 09:23:
... Andere pakketten zijn hier niet kwetsbaar, dus moet er een oplossing zijn. ...

Welke zijn dat/hoe weet je dat ze niet kwetsbaar zijn?

[Verwijderd]

De oplossing is simpel, nooit je passwords laten onthouden en altijd dismounten als je weggaat.
Dit kan ook met een hotkey.

[Verwijderd]

begintmeta schreef op zaterdag 03 april 2010 @ 21:40:
[afbeelding]

Komt dan altijd weer bij me op...

Hidden truecrypt container in een gewoon truecrypt volume?
Dan vertel je het paswoord. Hebben ze nog niks en kunnen niet bewijzen dat je illegale zooi hebt.

[begintmeta]

Shroomy, een standaard voorbeeld (ff wikipedia geplagieerd voor't gemak) is:

1. Alice is the wife of jealous Bob. She wants to communicate with her secret lover Carl. She creates two keys, one intended to be kept secret, the other intended to be sacrificed. She passes the secret key (or both) to Carl.
2. Alice constructs a harmless message M1 about boring math stuff for Carl (intended to be revealed to Bob in case of discovery) and a burning love letter M2 to Carl. She constructs a cipher-text C out of both messages M1, M2 and emails it to Carl.
3. Carl uses his key to decrypt M2 and possibly M1 (in order to know the fake message, too).
4. Bob finds out about the email to Carl, becomes suspicious and forces Alice to decrypt the message.
5. Alice uses the sacrificable key and reveals the message M1 about boring math stuff to Bob. Since Bob does not know the other key, he has to assume that there is no other message M2.

Het probleem is dat Bob in 5 niet hoeft aan te nemen dat er geen M2 is (zeker niet als hij ooit van dergelijke verbergende methoden heeft gehoord) . Hij kan doorgaan met dwingen tot hij het om een of andere reden beu wordt.

De deniability van plausible deniability-gebruik wordt steeds kleiner.

[ Voor 5% gewijzigd door begintmeta op 08-04-2010 10:06 ]

[Equator]

begintmeta schreef op donderdag 08 april 2010 @ 09:43:
[...]

Welke zijn dat/hoe weet je dat ze niet kwetsbaar zijn?

Omdat ik af en toe contact heb met cryptologen die dergelijk kwetsbaarheden ontdekken.

Zelf werk ik hier met Utimaco. 1 van de weinig NBV goedgekeurde (DeVe en Stg: Confi volgens VIR-BI) En uit naam van mijn functie is het van belang dat ik het nieuws een beetje bijhou

Verwijderd schreef op donderdag 08 april 2010 @ 09:46:
De oplossing is simpel, nooit je passwords laten onthouden en altijd dismounten als je weggaat.
Dit kan ook met een hotkey.

Het gaat hier om full-disk Encryptie. De decryption key staat na de authentication in readable format in memory.

[ Voor 28% gewijzigd door Equator op 08-04-2010 10:43 ]

[begintmeta]

Equator schreef op donderdag 08 april 2010 @ 10:42:
Omdat ik af en toe contact heb met cryptologen die dergelijk kwetsbaarheden ontdekken.

Weet jij/zij toevallig ook hoe dat (met dezelfde functionaliteit en hardware) in elkaar zit?

Zelf werk ik hier met Utimaco. 1 van de weinig NBV goedgekeurde (DeVe en Stg: Confi volgens VIR-BI) En uit naam van mijn functie is het van belang dat ik het nieuws een beetje bijhou

Dit True-Crypt probleem is op zich geen nieuws natuurlijk (en ook niet per se beperkt tot TrueCrypt), weet je hoe het product dat je gebruikt (PrivateDisk(?)) de encryptiesleutel wel veilig kan houden?

Ik was altijd in de veronderstelling dat je hardware(modificatie) nodig zou hebben om het een en ander te verhinderen. (zou het alleen in cpu-cache houden van alle sleutelgerelateerde zaken wellicht wat kunnen betekeen tegen bepaalde aanvallen?)

[ Voor 9% gewijzigd door begintmeta op 08-04-2010 12:16 ]

[Equator]

begintmeta schreef op donderdag 08 april 2010 @ 11:18:
[...]

Weet jij/zij toevallig ook hoe dat (met dezelfde functionaliteit en hardware) in elkaar zit?

Wat bedoel je precies?

[...]

Dit True-Crypt probleem is op zich geen nieuws natuurlijk (en ook niet per se beperkt tot TrueCrypt), weet je hoe het product dat je gebruikt (PrivateDisk(?)) de encryptiesleutel wel veilig kan houden?

Nee, zoals ik al eerder meldde, had SafeBoot hier ook 'last' van en is het daarin opgelost.
Hoe Utimaco SafeGuard Easy, of Enterprise dat doet kan ik je niet vertellen. PrivateDisk is geen FDE

Ik was altijd in de veronderstelling dat je hardware(modificatie) nodig zou hebben om het een en ander te verhinderen. (zou het alleen in cpu-cache houden van alle sleutelgerelateerde zaken wellicht wat kunnen betekeen tegen bepaalde aanvallen?)

Dat is een vraag die meer aan een goede devver gevraagd kan worden, daar weet ik gewoon te weinig van. De sleutel moet in memory beschikbaar zijn voor de filterdriver. Of daar nog iets van restricties in aan te brengen zijn weet ik niet. Wellicht heeft de architectuur van IEEE1394 gewoon geen last van dergelijke beperkingen en kan het altijd al het geheugen uitlezen.

[begintmeta]

Equator schreef op donderdag 08 april 2010 @ 12:33:
Wat bedoel je precies?

Nou ja, ik vraag me af hoe je de sleutel niet in je RAM wil hebben tijdens de decryptie, als je normale hardware gebruikt. Mij lijkt dat noodzakelijk om de aanval waar we het over hadden, bij gelijke functionaliteit en hardware, te weerstaan.

...
Nee, zoals ik al eerder meldde, had SafeBoot hier ook 'last' van en is het daarin opgelost.
Hoe Utimaco SafeGuard Easy, of Enterprise dat doet kan ik je niet vertellen. PrivateDisk is geen FDE

Ik zou het, vanwege bovengenoemde reden, erop houden dat het niet echt is opgelost zolang het me niet wordt uitgelegd hoe het is opgelost. Ik kan me voorstellen dat je bijvoobeeld alle key-gerelateerde zaken uit het geheugen wist zodra de computer gelockt wordt, maar dan zou de funcionaliteit veranderen. Maar goed, ik ken die programma's niet zo goed.

Wel nog wat gevonden mbt het cache-verhaal

[Equator]

begintmeta schreef op donderdag 08 april 2010 @ 13:46:
[...]

Nou ja, ik vraag me af hoe je de sleutel niet in je RAM wil hebben tijdens de decryptie, als je normale hardware gebruikt. Mij lijkt dat noodzakelijk om de aanval waar we het over hadden, bij gelijke functionaliteit en hardware, te weerstaan.

[...]

De DEK (Data Encryption Key) wil je niet direct leesbaar in je RAM hebben staan omdat het dan uit te lezen is (zie de reden van dit topic )
Er moet een manier zijn waarmee dit probleem verholpen kan worden.

Ik zou het, vanwege bovengenoemde reden, erop houden dat het niet echt is opgelost zolang het me niet wordt uitgelegd hoe het is opgelost. Ik kan me voorstellen dat je bijvoobeeld alle key-gerelateerde zaken uit het geheugen wist zodra de computer gelockt wordt, maar dan zou de funcionaliteit veranderen. Maar goed, ik ken die programma's niet zo goed.

De Filterdriver (welke je nodig hebt om je OS de mogelijkheid te geven om zonder problemen de versleutelde data te laten benaderen) heeft toegang tot een sleutel nodig. Dus de sleutel uit het RAM gooien op het moment van een screen-lock lijkt me niet zo handig. Het OS zou dan een niet benaderbare disk zien, en de meeste OS'en vinden dat niet leuk.

Overigens heeft de NBV, of zijn duitse variant de BSI welke meer weet van de oplossing, anders zouden ze geen certificering krijgen. Een belangrijk onderdeel daarvan is namelijk inzage in de broncode.
En wij (overheid) vertrouwen de NBV erin dat zij hun werk goed doen.

offtopic:
Dat is dus de reden dat de NBV nooit het blackberry verhaal gaat certificeren voor Departementaal Vertrouwelijk, want RIM geeft een (voor hun onbeduidende ) NL toko echt niet zomaar inzage in de broncode.

[ Voor 9% gewijzigd door Equator op 08-04-2010 15:11 ]

[begintmeta]

Equator schreef op donderdag 08 april 2010 @ 15:07:
...
De DEK (Data Encryption Key) wil je niet direct leesbaar in je RAM hebben staan omdat het dan uit te lezen is (zie de reden van dit topic )
Er moet een manier zijn waarmee dit probleem verholpen kan worden.

Naar die manier ben ik erg benieuwd. (ik kan me wel dingen voorstellen met een min of meer onafhankelijke TPM chip die de sleutels&encryptie op zich neemt, niet echt iets anders)

De Filterdriver (welke je nodig hebt om je OS de mogelijkheid te geven om zonder problemen de versleutelde data te laten benaderen) heeft toegang tot een sleutel nodig. Dus de sleutel uit het RAM gooien op het moment van een screen-lock lijkt me niet zo handig. Het OS zou dan een niet benaderbare disk zien, en de meeste OS'en vinden dat niet leuk.

Ik ben dan ook zoals gezegd benieuwd waar die sleutel dan blijft.

Overigens heeft de NBV, of zijn duitse variant de BSI welke meer weet van de oplossing, anders zouden ze geen certificering krijgen. Een belangrijk onderdeel daarvan is namelijk inzage in de broncode.
En wij (overheid) vertrouwen de NBV erin dat zij hun werk goed doen.

Bij certificeringen is het altijd belangrijk te kijken wat precies gecertificeerd wordt, wat zijn de randvoorwarden die gesteld worden? Zijn die producten die je noemt inderdaad veilig wanneer bij gemounte volumes het RAM wordt uitgelezen? Ik ben nog nooit ergens een oplossing tegengekomen op normale hardware (alleen informatie over veiligheidsproblemen), wat is voor jou de aanleiding te denken dat die wel bestaat?

[ Voor 10% gewijzigd door begintmeta op 08-04-2010 16:36 ]

[serkoon]

Er bestaat geen oplossing behalve obfuscation. De key is nodig om te decrypten, dus moet het in geheugen aanwezig zijn om die decryptieslag uit te voeren. Weet je in de brei aan assembly te vinden waar dat gebeurt, dan kun je de sleutel achterhalen.

[begintmeta]

leek me ook (oplossing zou denk ik wel in hardware kunnen liggen, encryptie niet in RAM, maar b.v. in encryptie'black box'/tpm/ess)

[ Voor 84% gewijzigd door begintmeta op 08-04-2010 21:56 ]

[serkoon]

Ja, dat is inderdaad het idee van TPM-chips (en ook HSMs). Je slaat keymateriaal op in een tamper-resistant chip of device en laat die het werk doen. Zodoende kun je dus niet met de firewire-attack rechtstreeks de key uitlezen.

Overigens lost dat nog steeds het fundamentele probleem niet op. Als je met firewire naar RAM kunt schrijven, kun je ook gewoon het diskencryptieproduct patchen om alle disksectors te lezen en decrypten en de gedecodeerde data op die manier uitlezen.

[begintmeta]

Ja, firewire is sowieso uit den boze. Om dergelijke zaken echt tegen te gaan zou de hele computer eigenlijk een soort smartcard moeten worden, en zelfs dan zullen er altijd wel problemen blijven.

Is het trouwens niet zo dat de meeste TPM chips nog geen symmetrische encryptie doen?