Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Linux disk encryptie
In het volgende verhaal staan instructies om Linux Mint op een encrypted partitie te installeren:
http://lowentropymusings.wordpress.com/2012/08/25/installing-linux-mint-13-on-an-encrypted-lvm/
Hierin wordt geadviseerd om de schijf te wissen met nullen:
dd if=/dev/zero of=/dev/mapper/cryptdev bs=1M
Wat voor invloed heeft dat op de veiligheid van de encrypted partitie?
http://lowentropymusings.wordpress.com/2012/08/25/installing-linux-mint-13-on-an-encrypted-lvm/
Hierin wordt geadviseerd om de schijf te wissen met nullen:
dd if=/dev/zero of=/dev/mapper/cryptdev bs=1M
Wat voor invloed heeft dat op de veiligheid van de encrypted partitie?
Reacties (14)
ik denk je dat je het niet helemaal goed begrijpt (of ik meschien niet) maar wat ik begrijp van die tutorial wil die de ongebruikte ruimte wissen en niet de schijf zelf, ik zal het uitleggen
Als je een bestand wist op je harde schijf word alleen de eerste letter van het bestand weggehaald en word de ruimte die het bestand gemaskeerd als bruikbaar zodat een toekomstig bestand de ruimte van het oude bestand kan hergebruiken, maar het bestand zelf is er nog steeds en kan vaak met freeware tooltjes ook weer worden teruggehaald, in de tutorial wil hij die ongebruikte ruimte vullen met nulletjes (computers schrijven met éénen en nullen) zodat er geen sporen meer zijn van de verwijderde bestanden en dus ook niks mee terug te halen is. Het verwijderd dus niet je hele schijf of bestaande bestanden, maar het zorgt er alleen voor dat je oude verwijderde bestanden niet meer terug te halen is
Als je een bestand wist op je harde schijf word alleen de eerste letter van het bestand weggehaald en word de ruimte die het bestand gemaskeerd als bruikbaar zodat een toekomstig bestand de ruimte van het oude bestand kan hergebruiken, maar het bestand zelf is er nog steeds en kan vaak met freeware tooltjes ook weer worden teruggehaald, in de tutorial wil hij die ongebruikte ruimte vullen met nulletjes (computers schrijven met éénen en nullen) zodat er geen sporen meer zijn van de verwijderde bestanden en dus ook niks mee terug te halen is. Het verwijderd dus niet je hele schijf of bestaande bestanden, maar het zorgt er alleen voor dat je oude verwijderde bestanden niet meer terug te halen is
19-02-2013, 10:26 door
Snailer
Het nut ervan ontgaat me eigenlijk (een beetje) daar het mij waarschijnlijker lijkt om juist een random number generator te gebruiken.
/dev/random
http://en.wikipedia.org/wiki//dev/random#Linux (Als je deze schrijf vult met Nullen dan weet zie je gelijk wat beschreven is en niet).
19-02-2013, 10:31 door
SirDice
Door Snailer: (Als je deze schrijf vult met Nullen dan weet zie je gelijk wat beschreven is en niet).
Dat is ook mijn idee. Willekeurige data is dan een betere optie omdat er zo moeilijk te zien is wat willekeurig is en wat versleuteld.Hebben jullie ook de onderbouwing in het topic gelezen?
"There are several reasons I suggest this and not /dev/urandom. First, since you’re encrypting those zero bytes before storing them on disk, they will appear to be random to anyone without the key. Second, it’s considered good practice to zero out partitions before creating filesystems. Third, /dev/urandom can be slow, and you’d probably like to finish installing before they come out with the next release of Mint."
"There are several reasons I suggest this and not /dev/urandom. First, since you’re encrypting those zero bytes before storing them on disk, they will appear to be random to anyone without the key. Second, it’s considered good practice to zero out partitions before creating filesystems. Third, /dev/urandom can be slow, and you’d probably like to finish installing before they come out with the next release of Mint."
19-02-2013, 11:42 door
didrix
Door SirDice:
De nullen worden geschreven naar de versleutelde partitie (/dev/mapper/cryptdev). Versleutelde nullen en versleutelde data zien er hetzelfde uit op de schijf. Maar het kan alsnog geen kwaad om /dev/(u)random te gebruiken, hoewel langzamer, zoals aangegeven in het artikel.Door Snailer: (Als je deze schrijf vult met Nullen dan weet zie je gelijk wat beschreven is en niet).
Dat is ook mijn idee. Willekeurige data is dan een betere optie omdat er zo moeilijk te zien is wat willekeurig is en wat versleuteld.Door yobi: Wat voor invloed heeft dat op de veiligheid van de encrypted partitie?
Je kan niet zien hoeveel data je versleutelde partitie bevat.
19-02-2013, 11:51 door
SirDice
Door didrix:
Ah, dat was niet duidelijk. In dat geval niet nee. Andersom (eerst nullen schrijven en dan encrypten) wel. Naderhand de schijf met nullen vullen heeft niet zo bijster veel zin. Je hebt 't toch net zitten newfs'en en de voorgaande data is niet belangrijk.Door SirDice:
De nullen worden geschreven naar de versleutelde partitie (/dev/mapper/cryptdev). Versleutelde nullen en versleutelde data zien er hetzelfde uit op de schijf.Door Snailer: (Als je deze schrijf vult met Nullen dan weet zie je gelijk wat beschreven is en niet).
Dat is ook mijn idee. Willekeurige data is dan een betere optie omdat er zo moeilijk te zien is wat willekeurig is en wat versleuteld.
19-02-2013, 12:23 door
yobi
De nullen worden inderdaad versleuteld. De vraag is dan ook of het sleutelmateriaal is terug te rekenen? Men weet dat er allemaal nullen zijn opgeslagen.
Zelf zou ik ook de volgende regel uitvoeren (dan maar even wachten):
dd if=/dev/urandom of=/dev/mapper/cryptdev bs=1M
Zelf zou ik ook de volgende regel uitvoeren (dan maar even wachten):
dd if=/dev/urandom of=/dev/mapper/cryptdev bs=1M
Door Anoniem: Als je een bestand wist op je harde schijf word alleen de eerste letter van het bestand weggehaald en word de ruimte die het bestand gemaskeerd als bruikbaar zodat een toekomstig bestand de ruimte van het oude bestand kan hergebruiken, maar het bestand zelf is er nog steeds en kan vaak met freeware tooltjes ook weer worden teruggehaald,
Puntje van orde: Dat is (was?) hoe DOS werkte, als in het FAT bestandssysteem. Ik gebruikte DR-DOS en die had standaard zo'n undeleter aan boord, kon je soms nog maanden later oude meuk terugvinden. Ik weet eigenlijk niet hoe NTFS het doet (naast dat gedoe met de "recycler"), maar unix (en dus ook linux) werkt een beetje anders. Komt er op neer dat het terugvinden meer werk is (klooien met de fs debugger is niet grappig) en minder kans van slagen heeft.Neemt niet weg dat deze actie om overal een keertje overheen te schrijven geen slecht idee is.
Door Anoniem: "Third, /dev/urandom can be slow, and you’d probably like to finish installing before they come out with the next release of Mint."
Dat derde punt is behoorlijk zwak: /dev/random (op linux) werkt met een zgn "entropieverzamelaar" die makkelijk leeg raakt, en dan hangt de leesoperatie tot er weer genoeg "entropie verzameld is". Dat kan idd eindeloos duren als je geen hardware random generator aan boord hebt. En daarom is /dev/urandom verzonnen. Als de auteur dat niet weet, dan uhm. En anders, als de snellere variant ook nog langzaam gaat zijn, dan uhm. Tsja. Hoewel een paar terabyte aan goede qualiteit random data ook wel een beetje een opgave is.Op een systeem als FreeBSD gedragen /dev/random en /dev/urandom zich hetzelfde omdat de random generator erachter beter&sneller is. Je kan 'm nog steeds z'n voorraad entropie uitputten maar je moet er beter je best voor doen. En als je serieus wil gaan versleutelen dan is een hardwarematige versneller wel aan te raden. Moderne intel en AMD CPUs hebben ze, maar bijvoorbeeld ook VIA's C7 cpus met "padlock" feature -- leuk voor een laagverbruikssysteempje.
Door yobi: De nullen worden inderdaad versleuteld. De vraag is dan ook of het sleutelmateriaal is terug te rekenen? Men weet dat er allemaal nullen zijn opgeslagen.
Een essentiele eigenschap van een goed versleutelingsalgorithme is dat het niet mogelijk is om de key terug te rekenen uit een plaintext/ciphertext paar.
Daarom moet je ook altijd een goed versleutelingsalgorithme gebruiken en niet zelf iets bedenken wat "leuk husselt" want dan loop je er tegenaan dat dit wel mogelijk blijkt en je methode in notime gekraakt is.
(zie bijvoorbeeld WEP)
Door yobi: De vraag is dan ook of het sleutelmateriaal is terug te rekenen?
Plug: http://crypto-class.org leert je in welke mate dat kan. Er is ook wel het een en ander aan introductie tot cryptografie te vinden in boekvorm. Helaas is crypto vooralsnog heel erg slecht te "verappliancen" en moet je dus best wel het een en ander weten voor je er veilig mee aan de slag kan, zelfs alleen maar als "simpele gebruikert".Door Anoniem: En daarom is /dev/urandom verzonnen. Als de auteur dat niet weet, dan uhm. En anders, als de snellere variant ook nog langzaam gaat zijn, dan uhm. Tsja.
21:16:06 laptop:~/test/dd$ dd if=/dev/zero of=zero bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 2.73305 s, 196 MB/s
21:16:12 laptop:~/test/dd$ dd if=/dev/urandom of=random bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 36.6327 s, 14.7 MB/s
Zo zwak vind ik dat punt niet. Je kan ongeveer 13 keer nulletjes schrijven in te tijd dat je 1 keer random data kan schrijven. Uiteraard is dit afhankelijk van veel factoren o.a. hardware. Maar er valt dus wel degelijk wat voor te zeggen om vanwege de tijd te kiezen om nulletjes te schrijven.
25-02-2013, 15:15 door
yobi
Misschien een idee om eerst de schijf met een tijdelijke sleutel te crypten, vervolgens de nullen schrijven en dan de paritie opnieuw versleutelen met de definitieve sleutel.
25-02-2013, 16:15 door
KwukDuck
Door Anoniem:
21:16:06 laptop:~/test/dd$ dd if=/dev/zero of=zero bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 2.73305 s, 196 MB/s
21:16:12 laptop:~/test/dd$ dd if=/dev/urandom of=random bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 36.6327 s, 14.7 MB/s
Zo zwak vind ik dat punt niet. Je kan ongeveer 13 keer nulletjes schrijven in te tijd dat je 1 keer random data kan schrijven. Uiteraard is dit afhankelijk van veel factoren o.a. hardware. Maar er valt dus wel degelijk wat voor te zeggen om vanwege de tijd te kiezen om nulletjes te schrijven.
Door Anoniem: En daarom is /dev/urandom verzonnen. Als de auteur dat niet weet, dan uhm. En anders, als de snellere variant ook nog langzaam gaat zijn, dan uhm. Tsja.
21:16:06 laptop:~/test/dd$ dd if=/dev/zero of=zero bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 2.73305 s, 196 MB/s
21:16:12 laptop:~/test/dd$ dd if=/dev/urandom of=random bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 36.6327 s, 14.7 MB/s
Zo zwak vind ik dat punt niet. Je kan ongeveer 13 keer nulletjes schrijven in te tijd dat je 1 keer random data kan schrijven. Uiteraard is dit afhankelijk van veel factoren o.a. hardware. Maar er valt dus wel degelijk wat voor te zeggen om vanwege de tijd te kiezen om nulletjes te schrijven.
Ik denk dat er iets anders mis is, mijn snelheden zitten voor zowel /dev/zero als /dev/urandom tussen de 90~95MB/s.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
