Menu
Volledige schijfversleuteling: sterkste bestrijding van bewaking, aanval en diefstal van uw apparaten

Volledige schijfversleuteling: sterkste bestrijding van bewaking, aanval en diefstal van uw apparaten

Een van uw sterkste tegenmaatregelen tegen bewaking, aanvallen en diefstal van uw apparaten is ervoor te zorgen dat de gegevens erop veilig zijn. Echt, de enige manier om dat in deze tijd te doen, is ervoor te zorgen dat ze volledig versleuteld zijn met de schijf. Volledige schijfversleuteling verwijst naar het in een apparaat plaatsen van een harde schijf en deze als geheel versleutelen, zodat alle bestanden die erop staan ​​worden omgezet in een onleesbare vorm (versleuteld) en niet toegankelijk zijn zonder het wachtwoord om ze te ontsleutelen. Sommige apparaten, zoals apparaten met iOS, doen dit standaard. Andere, zoals Macbooks en pc's met Linux, moeten deze functies hebben ingeschakeld en ingesteld. Om te beginnen duik ik meteen in FileVault2, wat de OSX is die is ingebouwd in Full Disk Encryption, omdat ik dit op mijn primaire computer gebruik.

Zie: Bestandscoderingssoftware op Privacy-Tools.nl

FileVault2

Inheems in alle versies van Lion en hoger, is FileVault2 de vooruitgang op de originele FileVault die alleen de thuismap versleutelde. Het gebruikt 128-bits AES in XTS-modus om de schijf te coderen en wordt sterk aanbevolen bij het opzetten van een nieuwe computer met Yosemite of hoger. Goede strategie hier van een deel van Apple om er een speciale sectie over op te nemen in de Initial Computer Setup wanneer je OSX voor het eerst instelt. Wanneer u FileVault2 voor de eerste keer instelt, moet u een wachtwoord hebben voor het huidige beheerdersaccount en gebruikt u een generator voor willekeurige getallen (met ongeveer 320 bits willekeur beschikbaar na de eerste keer opstarten) om een ​​herstelsleutel te maken. Ik zou aanraden deze herstelsleutel niet bij Apple op te slaan, ook al geven ze je de mogelijkheid om dit te doen; met behulp van 3 beveiligingsvragen en antwoorden voor herstelverificatie van deze sleutel. In plaats daarvan zou ik aanraden om het tijdelijk op een stuk papier te schrijven totdat je het in een gecodeerde vorm (7zip met wachtwoord beveiligd archief) kunt bewaren in zoiets als je Tresorit Drive. Nadat u deze sleutel veilig hebt bewaard, brandt/versnippert u het papier waarop u de sleutel oorspronkelijk heeft opgeschreven. Op basis van enkele bevindingen in dit artikel: https://www.cl.cam.ac.uk/~osc22/docs/cl_fv2_presentation_2012.pdf, gebruikt FileVault2 PBKDF2 x SHA256 en 41.000 herhalingen van het wachtwoord. Dit voorkomt bruteforcering van het wachtwoord vanwege de vertraging bij het controleren van het gehashte wachtwoord met het wachtwoord dat op het systeem is opgeslagen. Er lijkt ook geen limiet te zijn aan de wachtwoordlengte, dus je zou in theorie één 100 tekens lang kunnen maken zonder andere problemen dan vertraging voordat de codering wordt ontsleuteld. Het is onbekend, maar onwaarschijnlijk, of Apple een achterdeur heeft geïmplementeerd in FileVault2. Als je een Mac hebt, raad ik je ten zeerste aan om volledige schijfversleuteling in te schakelen om je bestanden veilig te houden.

LUKS

Afkorting van Linux Unified Key Setup, LUKS is de volledige schijfcoderingsoplossing die door veel op Linux/GNU gebaseerde besturingssystemen wordt gebruikt. Meestal gebruikt het AES 256-bit-codering in CBC-modus met SHA256 voor hashing, maar dat kan indien nodig worden bewerkt om andere modi zoals XTS uit te voeren en de sleutelgrootte van het AES-algoritme te verkleinen tot 128-bit. Net als FileVault2 voor OSX heeft LUKS geen tekenlimiet voor de wachtwoorden/wachtzinnen en ik heb dit getest met een wachtwoordzin van 212 tekens die bestaat uit letters, cijfers, spaties en symbolen. Het aantal iteraties voor LUKS wordt bepaald door het CPU-vermogen van de machine. Voor langzamere computers kan dit lager zijn dan gewenst, zodat het kan worden opgegeven met de opdracht cryptsetup. Het commando zou zijn: cryptsetup luksFormat -i 15000 en ik zou ervaren gebruikers aanraden de waarde in te stellen op niet minder dan 20.000. Voor serieuze personen zou het verstandig zijn om dat aantal boven de 70.000 te houden met een wachtwoordzin van meer dan 40 tekens. LUKS is ook volledig open source en samen met het consistente gebruik binnen Linux-distributies is het een zeer vertrouwde keuze voor FDE.

VeraCrypt

Toen TrueCrypt in 2014 stierf, werd er veel gepraat over de beveiligingsproblemen waar de ontwikkelaars op hun website over hadden kunnen praten. Waren er echt veiligheidsproblemen? Hebben ze een Nationale Veiligheidsbrief gekregen die een achterdeur oplegt in een updateversie die moet worden vrijgegeven? Niemand wist echt iets dat verder ging dan speculatie en veel mensen werden moe. Voor Mounir Idrassi betekende dat dat alle beveiligingsproblemen in de TC 7.1a-release moesten worden opgelost en opgelost in een vork van het project genaamd VeraCrypt. Het wordt door velen beschouwd als de officiële upgrade naar TrueCrypt omdat het open source is, en er is een code-audit voltooid in oktober 2016 (zie: https://ostif.org/the-veracrypt-audit-results/). Ik ben een groot voorstander van VeraCrypt omdat het een aantal serieuze verbeteringen biedt aan de algemene beveiliging van TrueCrypt, terwijl het ook eigen functies toevoegt die het programma echt veel veiliger maken om te gebruiken.

Om te beginnen hebben ze RIPMD-160 verwijderd omdat het maar 160 bits op de hash was en vervangen door SHA-512, wat natuurlijk de opvolger is van SHA-256. Ze verhoogden ook het aantal standaard herhalingen in de eerste releases tot 500.000 herhalingen van het wachtwoord, wat een serieuze, serieuze verbetering is ten opzichte van de 1000 die TrueCrypt bood. Onlangs hebben ze een functie geïmplementeerd die een PIM-waarde wordt genoemd, wat staat voor Personal Iterations Multiplier en die ons niet alleen een derde verificatiestap geeft om naast uw wachtwoordzin en sleutelbestanden te decoderen, maar ons ook in staat stelt om onze iteratietelling op een unieke maar veilige manier te specificeren . Wanneer u een PIM-waarde voor systeemcodering opgeeft, neemt u uw PIM-waarde en vermenigvuldigt deze met 2048. Voor containergebaseerde codering neemt u 15000 en voegt u deze toe aan uw PIM-waarde maal 1000. Dit betekent dat u een PIM van 999 kunt opgeven en een iteratie telt meer dan een miljoen voor een versleutelde container. Een serieuze beveiliging voor uw bestanden om in te rusten.

VeraCrypt heeft ook enkele grafische verbeteringen aangebracht ten opzichte van TrueCrypt, wordt consequent bijgewerkt en bevat kleine tweeks om de bruikbaarheid te verbeteren, zoals het toevoegen van een willekeurigheidsmeter aan het "beweeg je muisscherm" om de willekeurige entropie die je verwerft weer te geven. Dit is, naast de recente audit, veelbelovend voor de tech-industrie. We hebben nu een zeer solide coderingsprogramma waarop we kunnen vertrouwen om onze informatie en gegevens veilig te houden.

Vanaf oktober 2016 heeft VeraCrypt enkele nieuwe algoritmen geïmplementeerd voor zowel codering als hashing, wat een positieve stap voorwaarts is. Camelia en Kuznyechik zijn toegevoegd als coderingsalgoritmen, maar staan ​​op zichzelf en kunnen niet worden gekoppeld zoals de oorspronkelijke drie, en Streebog is toegevoegd als een hash-algoritme. In de toekomst zou het leuk zijn om een ​​algoritme voor codering te zien met Camelia en Serpent als een team. Op die manier zijn we in staat om de extra beveiliging van twee coderingsalgoritmen op een trapsgewijze manier te krijgen, zonder afhankelijk te zijn van AES.

VeraCrypt-coderingsalgoritmen:

  • Serpent
  • AES
  • TwoFish
  • Camellia
  • Kuznyechik

VeraCrypt Hash-algoritmen:

  • SHA-256
  • SHA-512
  • Whirlpool
  • RIPMD-160
  • Streebog

iOS-apparaten

Mobiele Apple-apparaten van Apple met iets hoger dan versie 8.0 zijn standaard beveiligd met volledige apparaatcodering, ook wel 'Gegevensbescherming' genoemd in uw toegangscode-instellingen. Er is echter een grote sprong voorwaarts van de 5C naar de 5S en vanaf nu alle apparaten die TouchID hebben. Om te beginnen zou u zich moeten opfrissen over de recente gebeurtenissen tussen Aple en de FBI. Ik heb links hierover verderop in de krant geplaatst, maar het zou gemakkelijk genoeg moeten zijn om online te zoeken. Als u een van de genoemde apparaten boven 5S (6, 6S, 7, enz.) Heeft, beschikt u over de beste codering die Apple momenteel voor hun apparaten biedt. Je iPhone heeft een hardwarechip aan de binnenkant genaamd Secure Enclave die alle codering en de vertragingen tussen wachtwoordpogingen beheert. Alle versies van iOS boven 8 maken op een unieke manier gebruik van 256-bits AES-versleuteling van het volledige apparaat, waardoor alle gegevens buiten het vergrendelingsscherm worden beschermd. Deze gegevens op de hierboven vermelde apparaten zijn beveiligd met behulp van een kortstondige sleutel die bij het opstarten wordt gegenereerd en die verstrengeld is met de unieke UUID van uw apparaat om de codering uit te voeren. Uw toegangscode beschermt deze sleutel. Standaard wordt een 4-cijferige numerieke code voorgesteld bij het instellen van een toegangscode/TouchID, maar gebruikers hebben de mogelijkheid om veel langere, alfanumerieke toegangscodes in te schakelen voor meer veiligheid. Dit is iets wat ik zou aanraden om te doen.

Uw apparaat maakt ook gebruik van PBKDF2, zoals hierboven beschreven, met een iteratietelling die hoog genoeg is om een ​​vertraging van 80 ms te genereren bij het invoeren van de toegangscode (key stretching). Dit, samen met een paar andere beveiligingsfuncties, voorkomt effectief bruteforce-aanvallen op een apparaat met een toegangscode die langer is dan 11 tekens. De andere beveiligingsfuncties zijn onder meer een vergrendeling na 5 mislukte toegangscodepogingen en elke poging daarna kan de functie voor het wissen van gegevens worden ingeschakeld om uw apparaat na 10 mislukte pogingen te wissen, en het verplicht stellen van uw toegangscode om in te voeren in plaats van TouchID te gebruiken wanneer u uw apparaat uitschakelt. apparaat of als u het vergrendelscherm binnen 48 uur niet hebt omzeild.

Naast de codering op apparaatniveau die als zeer veilig wordt beschouwd (maar nog niet 100%), heeft Apple correct gecodeerde iCloud-back-ups in 9.3 gepusht die de toegangscode van het apparaat gebruiken om de back-up te coderen. Daarvoor was Apple in staat iCloud-back-ups uit te geven wanneer hij een bevel kreeg en een gebruiker kon echt niet als volledig veilig worden beschouwd, tenzij ze deze back-ups op het apparaat hadden uitgeschakeld. Maar nu wordt al uw informatie veilig geback-upt naar iCloud en hebt u nog steeds de mogelijkheid om volledige back-ups naar uw computer te versleutelen. Dit gezegd zijnde, zou ik gebruikers willen waarschuwen om geen back-up te maken van applicaties die gevoelige informatie opslaan in iCloud. U hebt 2 coderingsmodi die uw apparaatback-ups naar iTunes beschermen als u volledige schijfcodering op uw computer gebruikt, maar slechts één verdedigingslinie met iCloud.

Zie: Bestandscoderingssoftware op Privacy-Tools.nl