PDA

Bekijk Volledige Versie : Full disk encryptie voor klant



Erik
23/12/08, 13:56
Beste collega's, wat kunnen jullie mij vertellen over de volgende situatie:

Een klant vraagt om full disk encryptie op een server, zoals dat gedaan kan worden met Truecrypt. De hoster kan bij deze (virtual) server komen voor softwarematig onderhoud. Maar door simpelweg afsluiten (power down) van de server kan de klant een situatie creeren waarin niemand meer bij de data op die server kan komen, tenzij de klant het wachtwoord afgeeft. De hoster zal niet altijd op de hoogte kunnen zijn van wat er op/met deze server gebeurd, aangezien er een vast onderhoudschema zal zijn.

Kan een hoster iets dergelijks aanbieden, als een klant hier om vraagt? Of is de hostende partij verantwoordelijk voor het toegankelijk zijn van een dergelijke server indien instanties e.d. daarom vragen?

Wido
23/12/08, 14:21
Waarom niet? Als de klant zijn data veilig wenst te stellen kan dat toch? Je moet hem alleen op het gevaar wijzen dat de hoster niet zo maar een crash recovery kan doen.

Wanneer er dan een instantie komt die bij de data wil moet je hen helaas afwijzen, maar dat zou ik sowieso doen, want welk recht hebben ze om zo maar de data op te eisen? Privacy kennen we toch nog wel?

En je kan dan ook gewoon zeggen, ik wil best meewerken, maar alle data is encrypted. Dus met een correct bevel kan je dan de klantgegevens afstaan en kunnen ze daar verder mee.

Ik raad je aan de XS4All film Privacy Matters eens te kijken.

Erik
23/12/08, 14:24
Hoi Wido, bedankt voor je reactie en de tip. Die film wilde ik nog kijken, maar dat is er bij ingeschoten. Vanavond even tijd vrij maken ;-)

MMaI
24/12/08, 13:23
http://www.privacymatters.nl/

Phu
24/12/08, 14:16
wij hebben een 5 tal dedicateds draaien van een semi overheids instelling
hier draait Safeboot op.

Redelijk veilig encrypty die je niet zomaar kan kraken.

Erik
24/12/08, 14:56
Ok, goed om te weten dat dit ook daadwerkelijk toegepast wordt binnen de hostingwereld.

ICTRecht
24/12/08, 18:40
Juridisch lijkt me hier weinig mis mee. Ik ken geen wettelijke eisen dat je toegang moet kunnen geven tot gegevens van een klant. Als je het kunt, en er ligt een bevel, dan moet je het afgeven. Als de klant bijvoorbeeld bij jou een reserve-wachtwoord in depot legt voor "je weet maar nooit", ben je verplicht dat wachtwoord aan de officier van justitie te geven als hij met een bevel komt.

Ik zou wel even extra duidelijk uitwerken hoe het moet gaan als de server crasht of de klant het wachtwoord vergeten is. Dit om discussie te voorkomen.

Arnoud

patattewiel
25/12/08, 14:29
Buiten alle juridische zaken, lijkt het me vooral voor klanten interessant. Ik geloof wel dat je er echt een markt voor kan krijgen. Gezien dat het open source is, heb ik daar meer vertrouwen in dan in bijvoorbeeld backup online van kpn of internlnet. Drie maanden terug kwam toch naar voren dat er een deel van de lijn niet ge encrypt is, ik kan helaas het bericht daarvan even niet meer vinden.

Goed plan dus.

Apoc
27/12/08, 20:53
Buiten alle juridische zaken, lijkt het me vooral voor klanten interessant. Ik geloof wel dat je er echt een markt voor kan krijgen. Gezien dat het open source is, heb ik daar meer vertrouwen in dan in bijvoorbeeld backup online van kpn of internlnet. Drie maanden terug kwam toch naar voren dat er een deel van de lijn niet ge encrypt is, ik kan helaas het bericht daarvan even niet meer vinden.

Goed plan dus.

Wat heeft locale disk encryptie te maken met een backup oplossing? Dat zijn twee totaal verschillende zaken.

Mijns inziens heeft lokale encryptie vrij weinig zin, tenzij de schijven fysiek getransporteert worden (waar in dit geval dus geen sprake van is). Dat bijvoorbeeld een USB stick (voor zakelijke of gevoelige doeleinden) altijd geencodeerd zou moeten worden, dat spreekt geheel voor zich. Echter voor schijven die zich in een datacentrum bevinden (en dus niet fysiek getransporteert worden), haalt het niet heel erg veel uit.

Het punt is vooral dat de encodering en de decodering op de server zelf zal plaatsvinden, en dat ook de en/decryptie sleutel op de server zelf aanwezig zal moeten zijn (anders kan de server de data zelf ook niet uitlezen). De server zal de data zelf constant moeten kunnen decoderen. Feitelijk komt dat er op neer als iemand een server meeneemt (diefstal of inbeslagname), die persoon theoretisch op dezelfde wijze als de server zelf de data zal kunnen uitlezen. Uiteraard zal die persoon daar wel kaas van gegeten moeten hebben, maar je moet er dan natuurlijk ook wel vanuit gaan dat iemand die in staat is om zo'n server mee te nemen, ook in staat zal zijn om dat te doen.

Om een lang verhaal kort te maken; om jezelf te beschermen tegen personen die niet bar veel verstand van zaken hebben, kan het effectief zijn. Maar buiten dat, zal het niet heel erg veel waarde toevoegen.

Als je data transporteert (bijvoorbeeld bij fysiek transport van een opslagmedium, of bij transport over het internet dmv SSL), dan is encryptie zeer doeltreffend. Dit heeft dan ook vooral te maken met het feit dat als op dat moment de data onderschept wordt, de encryptie en decryptie (en versleuteling) niet aanwezig zullen zijn. Echter bij diefstal uit een datacentrum of inbeslagname ligt dat anders. In dat opzicht kun je beter gewoon zorgen dat de fysieke beveiliging ter plaatse in orde is.

Om terug te komen op het juridische aspect; dat zal inderdaad geen probleem zijn. Buiten wat Arnoud al noemde (extra duidelijke afspraken), zou ik daarnaast ook aan de klant duidelijk maken dat je geen garantie kunt bieden over de encryptie/decryptie (i.v.m. het bovenstaande).

jeroen2496
28/12/08, 13:47
Maar als je de sleutel invoerd bij het opstarten, dan is hij toch niet direct aanwezig op de server? Ja vast ergens in het geheugen, maar na een reboot zal hij die opnieuw vragen....toch?

Apoc
28/12/08, 21:16
Maar als je de sleutel invoerd bij het opstarten, dan is hij toch niet direct aanwezig op de server? Ja vast ergens in het geheugen, maar na een reboot zal hij die opnieuw vragen....toch?

Dan zou je dus bij elke reboot het password handmatig in moeten voeren - lijkt me geen goed plan (of althans niet erg handig). Ook zou je daarnaast data kunnen aftappen terwijl de server draait (al moet ik erkennen dat dat niet makkelijk zal zijn).

t.bloo
28/12/08, 23:38
mijn servers rebooten eens in het jaar ofzo (behalve in Grafix ;))
dan kun je best even via de serial console het password ingeven?

Phu
28/12/08, 23:51
De encrypty draait door
het idee is als je een losse schijf hebt deze niet zomaar zonder key of programma de data kan uitlezen.

Apoc
29/12/08, 19:52
De encrypty draait door
het idee is als je een losse schijf hebt deze niet zomaar zonder key of programma de data kan uitlezen.

Klopt, dat is ook de reden dat iemand in dat geval niet een losse schijf zal meenemen maar de hele machine.

Zoiah
29/12/08, 20:01
Mijns inziens heeft lokale encryptie vrij weinig zin, tenzij de schijven fysiek getransporteert worden (waar in dit geval dus geen sprake van is). Dat bijvoorbeeld een USB stick (voor zakelijke of gevoelige doeleinden) altijd geencodeerd zou moeten worden, dat spreekt geheel voor zich. Echter voor schijven die zich in een datacentrum bevinden (en dus niet fysiek getransporteert worden), haalt het niet heel erg veel uit.

Het punt is vooral dat de encodering en de decodering op de server zelf zal plaatsvinden, en dat ook de en/decryptie sleutel op de server zelf aanwezig zal moeten zijn (anders kan de server de data zelf ook niet uitlezen). De server zal de data zelf constant moeten kunnen decoderen. Feitelijk komt dat er op neer als iemand een server meeneemt (diefstal of inbeslagname), die persoon theoretisch op dezelfde wijze als de server zelf de data zal kunnen uitlezen. Uiteraard zal die persoon daar wel kaas van gegeten moeten hebben, maar je moet er dan natuurlijk ook wel vanuit gaan dat iemand die in staat is om zo'n server mee te nemen, ook in staat zal zijn om dat te doen.

Ik heb een aantal klanten die dit doen, op twee verschillende manieren maar komt beide op het zelfde neer, de key is niet opgeslagen op de HDD.

1. KVM-over-IP naar server en klop wachtwoord in bij het booten.
2; Onversleuteld host systeem die geboot wordt en vervolgens mount je je versleutelde diskfile/partitie/etc. en start je je guest.

Dit is zeker niet feilloos (afhankelijk van je hardware kan je via firewire geheugen uitlezen. Of, veel BIOSen clearen niet het geheugen, dus je reset de machine hard en boot van een USB disk die geheugen inhoud dumpt, etc.), maar het is dus wel mogelijk om bij een gewone diefstal van machine, HDD, etc. de data veilig te houden.

HCiZiZ
02/01/09, 21:01
Volgens mij gaat het Erik vooral om het juridische aspect hier, niet of je het wel of niet aan een klant kan aanbieden. Vandaar ook dit subforum misschien? :)

Als de OVJ aan je vraagt of je de data aan hem kan geven, heb je misschien een probleem omdat je de encrypted data niet kan decrypten en dus nutteloos is. Dit in samenhang met de wet dat ISP's de data moeten bewaren.

Volgens mij heeft ICTRecht het hier bij het juiste eind, de data heb je, alleen kun je er natuurlijk niet aan doen dat de data versleuteld is... De "sleutel" zullen ze toch bij de klant moeten opvragen.

rensariens
09/01/09, 00:16
Het punt is vooral dat de encodering en de decodering op de server zelf zal plaatsvinden, en dat ook de en/decryptie sleutel op de server zelf aanwezig zal moeten zijn (anders kan de server de data zelf ook niet uitlezen). ..................

Om een lang verhaal kort te maken; om jezelf te beschermen tegen personen die niet bar veel verstand van zaken hebben, kan het effectief zijn. Maar buiten dat, zal het niet heel erg veel waarde toevoegen.

Dat is niet helemaal juist. Sleutels moeten inderdaad in het geheugen beschikbaar zijn, als je dit geheugen beschermd tegen sidechannel-attacks heeft het weldegelijk toegevoegde waarde. Op de HD zelf de keys opslaan is wel dodelijk, verkort de duur van het vinden van de key dramatisch. Truecrypt is iets waar zelfs de veiligheidsdiensten (in NL, NSA = onbekend) zeer veel moeite mee hebben. Een slecht gekozen key of het bewaren van deze key zijn de enige mogelijkheden om de schijf te decrypten.

Apoc
09/01/09, 00:40
Dat is niet helemaal juist. Sleutels moeten inderdaad in het geheugen beschikbaar zijn, als je dit geheugen beschermd tegen sidechannel-attacks heeft het weldegelijk toegevoegde waarde.

Dat klopt, maar ik had het over normale doorsnee hardware. Ik zou er naast kunnen zitten, maar het beschermen tegen sidechannel attacks is volgens mij niet iets wat je met standaard geheugen gemakkelijk kan doen. Je zal die sleutel toch constant moeten transporteren door een BUS van het moederbord. Die sleutel moet toch ergens gecombineerd worden met "het slot" (de geencodeerde data).


Truecrypt is iets waar zelfs de veiligheidsdiensten (in NL, NSA = onbekend) zeer veel moeite hebben.

Mag ik vragen waar je die wijsheid vandaan hebt? Ik kan me voorstellen dat men iedereen graag laat geloven dat ze moeite hebben om dat te kraken (dat bevordert het gebruik ervan, en maakt het voor hen alleen maar makkelijker).

Ik wil absoluut niet beweren dat het makkelijk te kraken is, maar ik vraag me wel af hoe je dan weet dat het zeer lastig te kraken is door dergelijke experts.

rensariens
09/01/09, 00:42
Mag ik vragen waar je die wijsheid vandaan hebt?



Universiteit van Amsterdam, System and Network Engineering. Een tip als iemand hier in deeltijd wil bijleren ;) Zitten daar mensen die veel van dit onderwerp weten en ook in de praktijk vanuit CERT teams bezig zijn met dit soort zaken.

Apoc
09/01/09, 00:44
Volgens mij gaat het Erik vooral om het juridische aspect hier, niet of je het wel of niet aan een klant kan aanbieden. Vandaar ook dit subforum misschien?

Het lijkt me voor dezelfde klant toch van belang om bijvoorbeeld te weten dat de key bij elke reboot opnieuw ingevoerd moet worden, en of al die extra moeite uiteindelijk wel zin heeft. De oorspronkelijke vraag (of het juridisch gezien mag) is reeds beantwoord, dus het is dan geen probleem om dieper op de discussie in te gaan.

rensariens
09/01/09, 00:49
Het lijkt me voor dezelfde klant toch van belang om bijvoorbeeld te weten dat de key bij elke reboot opnieuw ingevoerd moet worden. Is er geen mogelijkheid tot het openzetten van een mogelijkheid tot SSL verbinding vanaf een specifiek adres om deze key in te voeren? Lijkt me ieder geval in theorie mogelijk, weet niet of iemand hier al wat voor ontwikkeld heeft.

Apoc
09/01/09, 00:56
Universiteit van Amsterdam, System and Network Engineering. Een tip als iemand hier in deeltijd wil bijleren ;)

Daar heb ik inderdaad al eens eerder goede verhalen over gehoord. Maar over dat bijleren; volgens mij zal je dan toch eerst je bachelor moeten halen, want als ik me niet vergis is dat een master?


Zitten daar mensen die veel van dit onderwerp weten en ook in de praktijk vanuit CERT teams bezig zijn met dit soort zaken.

Tja, CERT. Daar heb ik sowieso niet veel goeds over te zeggen, al heb ik er redelijk beperkte ervaringen met ze. De mensen bij CERT waar ik mee heb gesproken zou ik zelf niet als "experts" benoemen, maar er lopen daar natuurlijk wel een stuk meer personen rond dan de inspecteurs waar ik contact mee heb gehad.

rensariens
09/01/09, 01:01
Daar heb ik inderdaad al eens eerder goede verhalen over gehoord. Maar over dat bijleren; volgens mij zal je dan toch eerst je bachelor moeten halen, want als ik me niet vergis is dat een master?

Klopt, is een master. Met een HBO opleiding en wat werkervaring kan je het ieder geval doen gezien enkele medestudenten ook zo binnen waren gekomen.




Tja, CERT. Daar heb ik sowieso niet veel goeds over te zeggen, al heb ik er redelijk beperkte ervaringen met ze. De mensen bij CERT waar ik mee heb gesproken zou ik zelf niet als "experts" benoemen, maar er lopen daar natuurlijk wel een stuk meer personen rond dan de inspecteurs waar ik contact mee heb gehad.

Zijn verschillende teams, is niet een groep. Weet ieder geval dat er genoeg kennis aanwezig is over encryptie, wordt veel aandacht aan geschonken tijdens deze master.

J.Haagmans
11/01/09, 15:33
Klopt, is een master. Met een HBO opleiding en wat werkervaring kan je het ieder geval doen gezien enkele medestudenten ook zo binnen waren gekomen.
Met een HBO opleiding heb je je bachelor, dus dan kun je gewoon aan een universitaire master beginnen.

rensariens
12/01/09, 01:01
Met een HBO opleiding heb je je bachelor, dus dan kun je gewoon aan een universitaire master beginnen.

Ik bedoelde dat er enkele waren zonder HBO diploma (niet afgemaakt). Zin klopt inderdaad niet ;)

J.Haagmans
12/01/09, 13:59
Ik bedoelde dat er enkele waren zonder HBO diploma (niet afgemaakt). Zin klopt inderdaad niet ;)
Ik snap 'm :)