Nieuwe versie Bitlocker negeert hardwarematige encryptie op ssd's

De nieuwe versie van Windows 10 vertrouwt in de toekomst niet meer standaard de hardware-based encryptie van ssd's. Bitlocker accepteert in de standaardinstellingen niet langer de hardwarematige versleuteling in de schijven.

De veranderingen zitten in update KB4516071 van Windows 10. Daarin wordt niet specifiek beschreven wat de reden voor de aanpassing is. In beveiligingskringen wordt echter gespeculeerd dat het komt doordat ssd-fabrikanten de beveiliging van hun schijven niet goed op orde hebben. Daardoor zou het mogelijk zijn de schijfencryptie relatief eenvoudig te omzeilen. Vorig jaar omzeilden onderzoekers van de Radboud Universiteit bijvoorbeeld die encryptie. Microsoft wil de beveiliging nu zelf overnemen.

Hoewel Bitlocker standaard in Windows 10 Pro zit, werkt dat op voorgaande versies van het besturingssysteem niet standaard als een ssd hardwarematig versleuteld is. Met de nieuwe update negeert Bitlocker die encryptie en versleutelt het die schijf standaard softwarematig.

Dat zou mogelijk zijn doordat moderne pc's inmiddels genoeg cpu-snelheid hebben om zulke softwarematige versleuteling snel uit te voeren zonder dat de computer daarmee traag wordt. Gebruikers die van hardware- naar software-encryptie willen gaan op hun schijf, zullen die eerst moeten ontsleutelen en dan opnieuw versleutelen. Ook kunnen gebruikers nog steeds hardware-encryptie instellen als ze dat willen; het is alleen de standaardinstelling die Microsoft nu wijzigt.

Reacties (112)

[Gamebuster]

Hoe zet je volledige schijf-encryptie aan op Windows 10?

Ik dacht dat Windows 10 (Home) niet kwam met schijf-encryptie.

[Reactie gewijzigd door Gamebuster op 22 juli 2024 18:28]

[kiang]

• Je hebt Windows Pro nodig
• Je hebt een TPM module nodig, of moet je instellingen aanpassen, maar dan is je setup minder veilig

Op OEM laptops kan Bitlocker wel aanstaan op Win10 Home, bvb op de Dell XPS 15. Bij zelfsbouw heb je Pro nodig.

[Reactie gewijzigd door kiang op 22 juli 2024 18:28]

[henk717]

Op Recente AMD moederborden kun je ook gebruik maken van de Platform Security Processor als je dit activeert in het UEFI (BIOS) Menu. Je kunt op die manier de AMD CPU een TPM laten emuleren binnen zijn eigen gescheiden ARM chip en hebt daarna geen TPM meer nodig op de desktop PC.

[himlims_]

pro / edu / enterprice

[kiang]

edu en enterprise kan je niet zomaar zelf kopen

[henk26]

Werkt ook op Windows Enterprise met een pincode i.c.m. een TPM chip.

[Gamebuster]

Mijn Surface Pro 6 met Windows 10 Home heeft inderdaad ook schijf-encryptie, zie ik nu! Toch weer een aangename verassing.

[MrHarry]

zo niet werkte veracrypt ook goed!

[gabba25]

Nog steeds belachelijk deze pro eis voor bitlocker. Encryptie zou voor iedereen moeten zijn. Op iOS en Android werkt het toch ook gewoon?

[Maurits van Baerle]

Op macOS staat FileVault ook standaard aan.

[Lounge Deluxe]

Dit is geen standaard instelling, FileVault dient handmatig aangezet te worden.

https://support.apple.com/nl-nl/HT204837

[Gamebuster]

Of het nu standaard aan staat of niet - als je een nieuwe mac open klapt, krijg je meteen de vraag of je FileVault wil inschakelen of niet.

Tenminste, de laatste keer dat ik een nieuwe mac had wel.

[Reactie gewijzigd door Gamebuster op 22 juli 2024 18:28]

[xfj]

Op Fedora en Ubuntu ook trouwens. Maar ik snap ook wel dat een OS bouwer wilt verdienen aan meer functies. Mensen werken niet gratis!

[toro]

Nee op Fedora en Ubuntu is het optioneel tijdens de installatie aan te zetten.

[jeroen3]

Ik denk dat het voor de gemiddelde home gebruikers meer een bron van frustratie is als de bestanden onherstelbaar zijn als het wachtwoord vergeten is. Wat heel veel gebeurd.

[satya]

En dat in de professionele enterprise omgeving bij de zaak je encryptie sluiten niet wordt opgeslagen

[Blokker_1999]

In een enterprise omgeving is het niet moeilijk om de unlock keys centraal op te slaan.

[satya]

Dat lukt ze bij ons kennelijk normaal gesproken wel als je je binnen het domein bevind, een of andere registersleutel oid die op de centrale omgeving wordt opgeslagen.

[Dennism]

Bij een normale implementatie wordt de sleutel gewoon weggeschreven in de Active directory / Azure AD bij het aanzetten van Bitlocker.

[Yggdrasil]

Wat probeer je te zeggen?

[satya]

Welke frustratie den je dat het je oplevert als je zakelijke laptop voor de zoveelste keer opnieuw ingericht moet worden om je werkt te kunnen doen, en de zaak de code niet bij blijkt te houden. Die bitlocker komt er mij te vaak zomaar doorheen zetten.

[Dennism]

Vziw wordt bitlocker nooit standaard aangezet en is altijd een actie van of wel de gebruiker of wel geforceerd door het IT beleid van de organisatie. Ik heb nog nooit meegemaakt dat dit zomaar aangezet wordt bij default instellingen.

[2bad4u]

Volgens mij gaat de Bitocker alleen aan als je daadwerkelijk inlogged met een MS-Account, daarin wordt ook je Bitlocker sleutel opgeslagen. Als je hem handmatig zonder MS-Account aanzet dan krijg je hem in beeld zodat je hem kan opslaan buiten de laptop of overschrijven (niet aan te raden )

[StefanTs]

Als er veel tijd zit in inrichten doen ze iets niet goed. Maar als ze je recovery key niet hebben gaat er sowieso iets fout. Je lijkt op bitlocker af te geven maar het probleem ligt bij de organisatie. (lees: ICT afdeling)

Maar het kan ook dat je iets compleet anders probeert te zeggen, iets meer aandacht voor taalgebruik zou je goed doen.

[Yggdrasil]

Oh, ik snap het. Er stond "sluiten" i.p.v. "sleutel" in je tekst dus klopte de zin niet.

Nee, dat ze de code niet bijhouden is inderdaad stom. Je systeembeheerder moet het zelf aanzetten en dan is het weinig moeite om die tekstfile met key op te slaan. Ik doe dat bij ons altijd, waardoor het na bijv. een bios-update weer ge-unlocked kan worden. Verder vraagt Bitlocker hier nooit om de key.

Dell heeft standaard een programma geïnstalleerd staan dat automatisch bios-updates doet en dat leverde dan problemen op want dan moest de medewerker de sleutel komen vragen. Die updates hebben we dus uitgezet en doen we af en toe handmatig.

[the_shadow]

En dat in de professionele enterprise omgeving bij de zaak je encryptie sluiten niet wordt opgeslagen

Hoezo niet wordt opgeslagen? Als je in je thuisomgeving Bitlocker aan zet, dan kan je de key op laten slaan in je Microsoft Account, in een bedrijfsomgeving moet je beheerder er voor zorgen dat de key opgeslagen wordt in de Active Directory. Kleine moeite om het in GPO's te configureren, scheelt een hoop gedoe.

[satya]

Klopt, maar gaat kennelijk niet altijd goed.

[Dennism]

Volgens mij wordt bitlocker bij het installeren van updates helemaal niet uitgezet. Bij het installeren van upgrades (OS of Firmware) wordt het vaak wel aangeraden, maar noodzakelijk is het vziw niet. Je kan er dan echter wel tegenaan lopen dat je na de upgrade je recovery key moet invoeren.

Verder komt Windows 10 Home gewoon met Drive Encryption (het heet alleen daar geen bitlocker), de hardware moet echter wel voldoen aan bepaalde specs (bijv. er moet een TPM aanwezig zijn). Alle MS Surfaces met Windows 10 Home hebben dat en bieden dus de optie tot drive encryption.

[Reactie gewijzigd door Dennism op 22 juli 2024 18:28]

[rene_fb]

Volgens mij wordt bitlocker bij het installeren van updates helemaal niet uitgezet.

Normaal niet nee, meen ik.
Maar ik heb het op de zaak in de afgelopen 2 jaar, één keer meegemaakt dat voor een update bitlocker uitgeschakeld werd, en na de update weer ingeschakeld.
Nu weet ik uiteraard niet of dit een Windows-eis was, of dat dit door de centrale IT zo besloten werd ivm weet ik wat voor reden...

Edit:
Zie ook onder. Kan best zijn dat dit een uefi update betrof IPV Windows.

[Reactie gewijzigd door rene_fb op 22 juli 2024 18:28]

[Dennism]

Weet je ook toevallig wat voor update dat was, dan is de reden vaak vrij makkelijk te achterhalen? Bij zaken als bijv. firmware / bios /. uefi updates wordt dit vrijwel altijd standaard gedaan omdat je anders na de update de recovery key moet invoeren.

[rene_fb]

Daar zeg je iets heel belangrijks.
Laat dat zo'n 1,5 jaar geleden zijn...
Het kan inderdaad zijn dat het geen Windows update was, maar een uefi update ten tijde van Meltdown/Spectre.

[Kewne]

Als je Bitlocker in TPM-only mode zonder PIN hebt staan (Drive Encryption of de volwaardige) was dit tot 1803 wel het geval. Er werd er bij iedere feature upgrade automatisch een "suspension" gedaan, oftewel het wegschrijven van een cleartext key op de schijf om deze na de upgrade weer te clearen. Dit is in 1803 aangepast zodat Bitlocker een poging waagt om het anders te doen, maar het is voor zo ver ik weet nog steeds niet volledig dicht tenzij je handmatig setup.exe /BitLocker ForceKeepActive draait. Een error forceren (foute values in TPM PCRs krijgen) is niet zo lastig.

Het is nog steeds best lastig om hier een aanval van te maken. Je moet een PC die in het midden van een feature update zit stelen, of een gestolen laptop (waarschijnlijk zonder login) forceren een feature update binnen te halen.

[Dennism]

Weet je zeker dat dit niet door een applicatie komt die op incorrecte wijze de file assiciations aanpast? Veel applicaties doen dat namelijk nog steeds door een registry setting aan te passen en dat is niet meer supported. Daardoor triggered die applicatie een reset van de file associations. Zie bijv. deze blog: https://devblogs.microsoft.com/oldnewthing/?p=96175

Ook bij telemetry settings lijkt dit te gebeuren, gebruik je supported settings dan blijven je instellingen gewoon bewaard na een update of upgrade. Gebruik je non-supported zaken om dit uit te zetten dan worden er inderdaad nog wel eens zaken gereset naar settings die wel supported zijn.

[GeoBeo]

Weet je zeker dat dit niet door een applicatie komt die op incorrecte wijze de file assiciations aanpast? Veel applicaties doen dat namelijk nog steeds door een registry setting aan te passen en dat is niet meer supported. Daardoor triggered die applicatie een reset van de file associations. Zie bijv. deze blog: https://devblogs.microsoft.com/oldnewthing/?p=96175

Ook bij telemetry settings lijkt dit te gebeuren, gebruik je supported settings dan blijven je instellingen gewoon bewaard na een update of upgrade. Gebruik je non-supported zaken om dit uit te zetten dan worden er inderdaad nog wel eens zaken gereset naar settings die wel supported zijn.

Bedankt voor de hulp. Maar ik begrijp dat het zo werkt. En ik heb inmiddels een work around om ondanks deze Windows bug toch Windows te kunnen updaten zonder steeds handmatig alles terug te moeten zetten (file associations backup genereren en instellen in group policy dism /online /Export-DefaultAppAssociations etc) + scripts die alle settings forceren naar hoe ik ze wil hebben.

Maar dat dit nodig is, is ronduit belachelijk. Ik heb er als gebruiker totaal geen boodschap aan dat sommige (oude) apps de file associations nog op de "verkeerde" manier zetten en daardoor de boel in de soep loopt. Ik kan daar als gebruiker niets aan veranderen en dus ook niets aan oplossen. En al kon ik dat wel: ik ga echt niet door m'n 100'en apps spitten om te kijken welke degene zijn die het verkeerd doen.

Dit is een bug. Een technologisch probleem. Een bug die geïntroduceerd is door Microsoft en opgelost moet worden door Microsoft.

De gebruiker (of app maker) de schuld geven van een OS probleem... Nee. Gewoon nee.

Met Windows Home is mijn work around overigens niet eens mogelijk en encryptie dus blijkbaar ook niet.

PS: ik geloof er helemaal niets van dat deze bug er niet bewust ingelaten wordt. Het is immers vanuit Microsoft gezien gewoon en feature dat telemetry "per ongeluk" weer aan gaat en file associtations "per ongeluk" gerest worden naar "toevallig" Microsoft apps als Paint 3D.

[Reactie gewijzigd door GeoBeo op 22 juli 2024 18:28]

[Dennism]

Het is alleen geen bug, dit is gewoon by design. Dit is geïmplementeerd om o.a. applicaties aan te pakken die files assiciations hijacken. Het klopt dus ook volledig wanneer je zegt dat dit er bewust in zit. De file associations worden zeer bewust gereset door MS wanneer een legacy applicatie de settings aanpast op een manier die niet meer gesupport wordt in Windows 10.

Het is dan ook vreemd dit een OS probleem te noemen, dit is puur en alleen een probleem van applicatie vendoren die hun software niet voor elkaar hebben en te lang blijven hangen op methodes die al jaren depricated zijn, het was al tijden bekend dat deze aanpassing eraan zat te komen. Dat applicatie ontwikkelaars daar dan niet naar handelen in gewoon simpelweg luiheid. Daar kun je lastig MS de schuld van geven, dat zou betekenen dat MS hun OS nooit meer zou kunnen aanpassen omdat de wijze uit het verleden ooit toegestaan is, maar heden ten dage gewoon voor beveiligingsproblemen kan zorgen wanneer malafide toepassingen gewoon file associations aan kunnen passen.

En ja, dat is gewoon een probleem van die legacy app vendor, die zal dat toch echt moeten oplossen. Of je moet inderdaad gaan werken met een implementatie zoals deze via Dism, deze gebruik je ook om dit soort zaken organisatie breed uit te rollen.

Hetzelfde met telemetry, gewoon uitzetten via de supported manieren, werkt prima. Ook dit zal zeer waarschijnlijk geen bug zijn, maar gewoon by design.

[Reactie gewijzigd door Dennism op 22 juli 2024 18:28]

[Dennism]

Geloof je dit werkelijk? Vindt je het zelf dan niet ironisch dat Microsoft zelf "by design" file associations hijacked, wanneer andere applicaties dit proberen? Hoe is dit een oplossing van het hijacken van file associations

Het eind resultaat voordat deze design change bestond was dat heel soms een programma file een paar associations hijacked.

Het eind resultaat na deze design change is dat wanneer 1 programma 1 file association hijacked, ALLE associations gehijacked worden naar Microsoft apps.

Sure dat is by design, maar hoe kun je dit goedpraten? Hoe is dit een verbetering vanuit de gebruiker gezien?

De redenatie erachter snap ik volledig, ik vind het zelf ook niet altijd prettig, want een boel dev's zijn te lui om hun applicaties fatsoenlijk te programmeren en dat mag ik als engineer dan weer gaan oplossen bij bijvoorbeeld VDI, RDS of andere implementaties

Ik snap echter volledig waarom ze kiezen voor een reset naar eigen tools, daar hebben ze immers zelf invloed op. Het zijn tools waarvan ze weten dat deze geen misbruik maken van een bepaalde file association. Opzich is dat vrij logsich.

Ik ben het met je eens dat het in sommige gevallen een beetje een paardenmiddel is.
Maar het design erachter steun ik in principe wel, als immers iedere 3rd party ontwikkelaar niet zo krampachter zou blijven vasthouden aan legacy code en gewoon de moderne implementaties voor dit soort zaken zou toepassen zou mijn werk op bepaalde vlakken weer een stuk simpeler worden.

Zie bovenstaande. Verder hoezo depricated? Microsoft introduceert bewust incompatibiliteit door deze verandering. Wat als ik een oud stuk software wil gebruiken? Hoezo gaat Microsoft er vanuit dat alle bruikbare software nog onderhouden wordt?

Ten tijde van Windows 7 is al aagegeven dat file associations aanpassen via bijvoorbeeld het registry niet meer supported zou zijn in de toekomst. Maar dat dit (destijds) via default programs (individueel) geregeld moest gaat worden. Vanaf dat moment wisten applicatie developers al dat dit eraan zat te komen.

Je draait nu echter de zaak om, Microsoft hoeft er helemaal niet vanuit te gaan dat iedere applicatie ontwikkeld blijft worden en dat doen ze ook niet. Microsoft kan echter ook niet stil blijven staan en maar iedere legacy implementatie blijven supporten. Ze geven tijdig aan dat zoiets aangepast wordt en daarna is het aan de 3rd party ontwikkelaars om dit mee te nemen bij nieuwe versie's.

Microsoft kan niet iedere veroudere legacy applicatie maar blijven supporten, zeker als de originele developer zelf geen support meer bied. Als je als gebruiker veel oude software gebruikt die niet meer gesupport wordt door de originele developer dan kan je inderdaad wel eens tegen ongemakken aanlopen.

Legacy app vendor? Oude (freeware) apps hebben geen vendor en hebben die ook nooit gehad, dus die kan dat ook niet oplossen.

Excuses, daar had ik ontwikkelaar neer moeten zetten, niet vendor

Dit is echt de wereld op z'n kop. Telemetry is per definitie een security risk. Telemetry is in mijn ogen een legale expoit/lek die actief gebruikt wordt om mijn privacy te lekken naar Microsoft.

Hoe kan het uitzetten van telemetry (een data lek) in godsnaam nog meer extra security risico's zorgen?! Ik volg de redenering totaal niet. En dat het voorkomen van "verkeerd" uitzetten van telemetry "by design is" maakt dit alleen nog maar kwalijker.

Wat is dit voor wereld, waarin het voorkomen van "verkeerd uitzetten" van een "actief datalek" gezien kan worden als een security feature?

Ik heb nergens aangegeven dat het inzake telemetry dit ook een security feature is. Ik geef alleen aan dat ze daar dezelfde systematiek hanteren, namelijk instellingen aanpassen op manieren zoals officieel support door Microsoft en niet op unsupported wijze.

De achterliggende gedachte snap ik mogelijk wel, unsupported changes kunnen voor allerhande problemen zorgen. Want wat gebeurt er, als bij een volgende upgrade of update zo'n unsupported change (hoeft niet met telemetry te maken te hebben, kan iedere willekeurige unsupported change zijn) voor problemen zorgt krijgt MS weer de wind van voren dat de update / upgrade het systeem "kapot" heeft gemaakt. Ik snap dus best dat MS zoveel mogelijk van deze unsupported changes tegen wil gaan en ervoor wil zorgen dat beheerders zaken via een supported implementatie aan of juist uitzetten.

[Reactie gewijzigd door Dennism op 22 juli 2024 18:28]

[GeoBeo]

[...]
De redenatie erachter snap ik volledig, ik vind het zelf ook niet altijd prettig, want een boel dev's zijn te lui om hun applicaties fatsoenlijk te programmeren en dat mag ik als engineer dan weer gaan oplossen bij bijvoorbeeld VDI, RDS of andere implementaties

Ik snap echter volledig waarom ze kiezen voor een reset naar eigen tools, daar hebben ze immers zelf invloed op. Het zijn tools waarvan ze weten dat deze geen misbruik maken van een bepaalde file association. Opzich is dat vrij logsich.

Ik ben het met je eens dat het in sommige gevallen een beetje een paardenmiddel is.
Maar het design erachter steun ik in principe wel, als immers iedere 3rd party ontwikkelaar niet zo krampachter zou blijven vasthouden aan legacy code en gewoon de moderne implementaties voor dit soort zaken zou toepassen zou mijn werk op bepaalde vlakken weer een stuk simpeler worden.


[...]


Ten tijde van Windows 7 is al aagegeven dat file associations aanpassen via bijvoorbeeld het registry niet meer supported zou zijn in de toekomst. Maar dat dit (destijds) via default programs (individueel) geregeld moest gaat worden. Vanaf dat moment wisten applicatie developers al dat dit eraan zat te komen.

Je draait nu echter de zaak om, Microsoft hoeft er helemaal niet vanuit te gaan dat iedere applicatie ontwikkeld blijft worden en dat doen ze ook niet. Microsoft kan echter ook niet stil blijven staan en maar iedere legacy implementatie blijven supporten. Ze geven tijdig aan dat zoiets aangepast wordt en daarna is het aan de 3rd party ontwikkelaars om dit mee te nemen bij nieuwe versie's.

Microsoft kan niet iedere veroudere legacy applicatie maar blijven supporten, zeker als de originele developer zelf geen support meer bied. Als je als gebruiker veel oude software gebruikt die niet meer gesupport wordt door de originele developer dan kan je inderdaad wel eens tegen ongemakken aanlopen.


[...]


Excuses, daar had ik ontwikkelaar neer moeten zetten, niet vendor


[...]


Ik heb nergens aangegeven dat het inzake telemetry dit ook een security feature is. Ik geef alleen aan dat ze daar dezelfde systematiek hanteren, namelijk instellingen aanpassen op manieren zoals officieel support door Microsoft en niet op unsupported wijze.

De achterliggende gedachte snap ik mogelijk wel, unsupported changes kunnen voor allerhande problemen zorgen. Want wat gebeurt er, als bij een volgende upgrade of update zo'n unsupported change (hoeft niet met telemetry te maken te hebben, kan iedere willekeurige unsupported change zijn) voor problemen zorgt krijgt MS weer de wind van voren dat de update / upgrade het systeem "kapot" heeft gemaakt. Ik snap dus best dat MS zoveel mogelijk van deze unsupported changes tegen wil gaan en ervoor wil zorgen dat beheerders zaken via een supported implementatie aan of juist uitzetten.

Ze hadden er ook voor kunnen kiezen de file associations alleen te resetten voor de file extension die verkeerd gezet is door een app. Ze hadden er ook voor kunnen kiezen het verkeerd zetten van de file associtation onmogelijk te maken (waarom het toestaan verkeerde associations weg te schrijven in het registry? Dit kun je gewoon blokken, dan heeft de gebruiker nergens last van). Nu laten ze eerste de fout tijden lang toe en blokkeren hem pas ten tijde van een update. Wut?!

Ze hadden er ook voor kunnen kiezen de association te resetten naar "geen app", zodat je als gebruiker de volgende keer dat je zo'n file opent zelf kunt kiezen welke app je wilt gebruiken. Ze hadden er ook voor kunnen kiezen de laatste geldige associations terug te zetten in plaats van Microsoft default apps.

Stuk voor stuk allemaal technisch mogelijk, even veilig en veel beter design waar de gebruiker er geen enkele last van heeft.

Of kort gezegd: als een app op een verkeerde manier een association probeert te wijzigen, gebeurt er in bovenstaande voorstellen *niets*, in plaats van dat alles dan by design (stilzwijgend) gereset wordt naar iets dat de gebruiker in 90% van de gevallen niet wil gebruiken.

Het is een verschrikkelijk ontwerp IMO.

[Reactie gewijzigd door GeoBeo op 22 juli 2024 18:28]

[Rolfie]

Legacy app vendor? Oude (freeware) apps hebben geen vendor en hebben die ook nooit gehad, dus die kan dat ook niet oplossen.

Dan is de applicatie technisch gezien dus niet Windows 10 geschikt. Als er daarna compatibiliteit ontstaat voor die applicatie, is dat geen Windows 10 probleem, maar een applicatie probleem.

Persoonlijk baal ik ook heel erg van deze feature, maar het werkt zoals het ontworpen is.

[Justin0017]

Daar heb ik zelf geen last van. Alleen Windows Defender springt steeds weer aan, maar daar hebben we weer registersleutels voor.

[ASS-Ware]

• Je hebt Windows Pro nodig
• Je hebt een TPM module nodig, of moet je instellingen aanpassen, maar dan is je setup minder veilig

Je kan bitlocker gewoon zonder tpm gebruiken.

[Reactie gewijzigd door ASS-Ware op 22 juli 2024 18:28]

[keranoz]

Er zijn best wel veel condities waar je systeem aan moet voldoen om hardware matige encryptie te gebruiken. Ik heb hier een tijd mee zitten stoeien op mijn werk laptop (een Dell Precision) i.c.m. een Samsung NVMe SSD.

1) BIOS moet het ondersteunen
2) Het moet aan staan op de SSD zelf. In het geval van Samung moet je dit met Magician doen en 1x booten vanaf een geprepareerde USB stick.
3) Afhankelijk van het systeem moet je BIOS SATA mode of op AHCI of op RAID staan.
4) Als je geen TPM hebt moet je in de group policy editor 'require additional authentication on startup' aanzetten. (in computer configuration/administrative templates/windows componnents/bitlocker drive encryption/operating system drives zo uit m'n hoofd)
5) In de group policy editor zou ik 'revert to software encryption' (o.i.d.) ook uitzetten.
6) Om te kijken of Bitlocker hardware encrpytion gaat gebruiken, kan je cmd als admin openen en dan 'manage-bde -status' uitvoeren. Hij output dan encryption informatie voor alle disks in het systeem. Bij Protection Status staat of hardware encryption, of een encryptie methode zoals XTS-AES 128. Als er geen hardware encryption staat wordt software encryption gebruikt.

Bij m'n werk laptop kreeg ik het niet aan de praat. Op m'n PC thuis (die d.m.v. een BIOS mod kan booten vanaf een NVMe SSD op een PCI adapter op een Gigabyte Z87 moederbord uit 2014!) werkt het wel.

edits: typos

[Reactie gewijzigd door keranoz op 22 juli 2024 18:28]

[DataGhost]

Ik mis alleen even het stukje waarom je dit per se in hardware wilt gebruiken op een consumenten-SSD onder dit artikel, gecombineerd met het "vorige" artikel. Mijn CPU doet 18 GB/s AES dus een echt grote impact heeft dat nou ook weer niet. Dan zit je straks niet met het gezeik dat je drive te unlocken is door iemand die gewoon de wachtwoord-check bypasst in de firmware van de drive.

Ik gebruik zelf op zowel m'n desktop als m'n laptop softwarematige bitlocker icm een TPM.

[Reactie gewijzigd door DataGhost op 22 juli 2024 18:28]

[OxWax]

Zo kan het wel mits ...

Device encryption requirements:

-Trusted Platform Module (TPM) version 2 with support for Modern Standby.
TPM must be enabled.
-Unified Extensible Firmware Interface (UEFI) firmware style.
-https://www.windowscentral.com/how-enable-device-encryption-windows-10-home

https://www.windowscentra...ncryption-windows-10-home

[Reactie gewijzigd door OxWax op 22 juli 2024 18:28]

[tom.cx]

Dat is helaas correct. Alleen vanaf Pro heb je schijf-encryptie.

[Gamebuster]

Teleurstellend... zeker omdat Microsoft's eigen "Pro" apparaten gewoon met Home geleverd worden, zoals de Surface Pro 6*. Een upgrade naar Pro kost gewoon veel geld, terwijl schijf-encryptie echt een standaard feature zou moeten zijn op een ieder apparaat, laat staan een pro-apparaat.

*Je hebt ook zakelijke versies van de Surface Pro die met Windows 10 Pro komen, maar mijn stelling is dat alle Surface "Pro" modellen met Windows 10 Pro zouden moeten komen.

Blijkbaar komt mijn Surface Pro 6 met Windows 10 Home met schijf-encryptie. Bedankt @NegativeFreak voor de tip om te zoeken op "Bitlocker"

[Reactie gewijzigd door Gamebuster op 22 juli 2024 18:28]

[Yggdrasil]

Desalniettemin helemaal mee eens dat een model van Microsoft dat Pro in de naam heeft gewoon standaard Windows Pro moet krijgen. Wij moeten al die dingen nu upgraden omdat ze aan een AD domein gekoppeld moeten worden.

Maar ja, Microsoft is op het gebied van segmentatie al langer de weg kwijt, o.a. te zien aan het feit dat het onmogelijk is om Candy Crush en vrienden niet meegeïnstalleerd te krijgen op je zakelijke PC, of dat je (zoals ze recent hebben ingesteld) bij de setup van een nieuwe PC gedwongen worden een Microsoft account te gebruiken.

[Dennism]

Bestel je dan niet gewoon de verkeerde Sku? Volgens mij heb je namelijk bijv. de Surface pro 6 en de Surface Pro 6 for Business. De eerste komen Windows 10 home, de "For Business" Sku's met Windows 10 Pro.

Verder ben ik trouwens nog geen zakelijke systemen tegen gekomen waarbij ik moet inloggen met een MS account, dat is allemaal gewoon optioneel bij de laptops die wij uitleveren aan klanten (en wordt volgens mij ook nooit gebruikt).

[Yggdrasil]

Dat zou kunnen. We wisten niet dat er meerdere edities waren van de Surface Pro 6 met i5. Veel winkels verkopen alleen de Home versie. In de toekomst ga ik er zeker op letten.

Wat betreft de MS account, als wij Win 10 Pro configureren krijgen we toch echt de vraag om in te loggen met een MS account. In release 1903 is de optie om een lokale account te maken helemaal verdwenen, tenzij je geen internetverbinding hebt! Je kunt niet teruggaan (bijv. om alsnog Wifi uit te schakelen) als je eenmaal in het account setup scherm bent. Zelfs rebooten helpt niet want je Wifi credentials worden onthouden. Ook het invullen van een foutief e-mailadres, dat vroeger nog wel eens werkte, helpt nu niet meer. Je moet dus tijdens setup niet verbinden met Wifi of dock totdat je voorbij die account stap bent. Als je dat per ongeluk wel al gedaan had, is de enige optie om buiten bereik van je Wifi te gaan staan en na een reboot opnieuw te proberen.

[Dennism]

Hier de specs Surface 6 voor bedrijven (en de normale Surface 6): https://www.microsoft.com...ivetab=pivot:techspecstab

Grappig, dat ben ik echt nog nooit tegen gekomen. Zal er de volgende keer eens op letten als ik weer eens een standalone machine uit moet rollen. Het grootste gedeelte van onze uitrol gaat via tools als SCCM en dan wordt de machine automatisch al in het klant domain gehangen.

Ik lees trouwens in dat artikel eigenlijk precies het omgekeerde dan dat jij leest:

Enkele quotes:

On the other hand, Microsoft’s May 2019 Update (version 1903) appears to be much, much friendlier to local accounts.

En:

If you choose to decline and “continue with a limited setup,” you can proceed directly to the local account setup.

Even better, if you do end up on the Microsoft account screen, there’s a big “Offline account” (or local account) option down in the lower left-hand corner. Hurray! That’s what we wanted all along.

[Reactie gewijzigd door Dennism op 22 juli 2024 18:28]

[ASS-Ware]

Wat betreft de MS account, als wij Win 10 Pro configureren krijgen we toch echt de vraag om in te loggen met een MS account. In release 1903 is de optie om een lokale account te maken helemaal verdwenen

Wat een onzin.
Het is niet verdwenen, maar verstopt.

Quote:
Over time, Microsoft has tacitly encouraged you ever more to create a Microsoft account, but it’s never actually blocked you from creating a local one. It comes damn close in the October 2018 Update, however.

[Yggdrasil]

Nou sorry dat ik je boos heb gemaakt hoor!

Ik heb het verkeerd verwoord, maar het is dus zo goed verstopt dat we onze Surface Pro buiten op de stoep voor het bedrijfspand moesten configureren. Het alternatief was een reinstall. Ik ga die werkwijze van Microsoft niet goed praten.

[wilfredk]

je wordt niet gedwongen om een microsoft acount te gebruiken ze hebben alleen de optie om een lokale acount te gebruiken in een net iets andere kleur letters onderaan de pagina verstopt

[Yggdrasil]

In de nieuwste release is de optie helemaal verdwenen, tenzij je geen internetverbinding hebt. Je moet dus tijdens setup niet verbinden met Wifi of dock totdat je voorbij die account stap bent.

[ASS-Ware]

In de nieuwste release is de optie helemaal verdwenen, tenzij je geen internetverbinding hebt. Je moet dus tijdens setup niet verbinden met Wifi of dock totdat je voorbij die account stap bent.

Klopt niet, je kan nog steeds de boel opzetten met lokale accounts.

[wilfredk]

na net een nieuwe instalatie gedaan te hebben heb ik gemerkt dat de optie inderdaad nog beter verborgen is.

nu moet je "per ongeluk" een verkeerde gebruikers naam en wachtwoord invullen en dan krijg je alsnog de optie...

bron: windows instalatie.. ehrm terwijl ik dit typ

[SED]

" bij de setup van een nieuwe PC gedwongen worden een Microsoft account te gebruiken."
Dat is niet juist. Je kunt nog steeds een local account aanmaken alleen is het wat beter verstopt.
De simpelste oplossing is installeren zonder internet verbinding, dan komt de local optie vanzelf en desgewenst later het account te activeren.
Voor pro installatie is dat zelfs niet nodig omdat je gebruik kunt maken van diverse tools die deze installatiestappen overslaan bij uitrol.

[Yggdrasil]

Zonder internetverbinding werkt inderdaad. Alleen kwamen we er laatst te laat achter. We hadden al verbonden met onze Wifi, waardoor die optie niet meer verscheen. De simpelste oplossing bleek toen om buiten te gaan staan met de Surface Pro (buiten bereik van onze kantoor-Wifi) waarna de optie beschikbaar werd. Nu we dit van tevoren weten zullen we natuurlijk eerst de setup voltooien voordat we inloggen op Wifi.

Ik ben helaas niet bekend met die diverse tools. We zijn een klein bedrijf dat niet veel met Microsoft doet. Wat zou je hiervoor aanraden?

[SED]

Ik zou hier beginnen:
https://docs.microsoft.co...yment-scenarios-and-tools

Wil je alternatieven dan is dit een aardig begin:
http://techgenix.com/deploying-windows-images/

[Berlinetta]

Windows 10 Home niet nee.

https://support.microsoft...turn-on-device-encryption

[Helium-3]

Ja inderdaad, bitlocker is (was?) exclusief voor Windows 10 pro. Vandaar ook dat ik die versie heb aangeschaft. Klein foutje van de auteur van het artikel, of is bitlocker tegenwoordig standaard bij home?

[Yggdrasil]

Niet standaard, maar het is op sommige Home devices wel geactiveerd. Bijv. de Surface apparaten.

[NegativeFreak]

Heb je helemaal gelijk in. Het zit pas in Windows 10 Pro.
Typ in je start menu gewoon "Bitlocker" en de optie Bitlocker beheren komt tevoorschijn, vanuit daar kun je het aanzetten.

https://support.microsoft...turn-on-device-encryption
"Let op: BitLocker is niet beschikbaar in Windows 10 Home."

[Verwijderd]

Windows 10 Home schijnt onder bepaalde voorwaarden Bitlocker wel te ondersteunen.
Uit https://www.zdnet.com/article/windows-10-which-user-account-type-should-you-choose/ (die stelt dat jouw installatie-account een Microsoft account zou moeten zijn, zie ook https://www.zdnet.com/art...ocal-account-option-gone/, mijn bron voor het onderstaande):

On PCs designed for Windows 10, signing in with a Microsoft account automatically enables full-disk encryption for the system drive, even on systems running Home edition.

Echter de Microsoft pagina waar dat artikel naar verwijst, ontkent dit weer.

Maar in https://docs.microsoft.co...ption-overview-windows-10 lees ik:

With Windows 10, Microsoft offers BitLocker Device Encryption support on a much broader range of devices, including those that are Modern Standby, and devices that run Windows 10 Home edition.

Op andere pagina's zie ik ook vermeld worden dat de computer over een TPM chip zou moeten beschikken.

Ik heb zelf geen Home versie van W10, dus weet niet precies hoe het zit. Is er wellicht iemand die W10 Home heeft, niet op een Surface, maar wel met Bitlocker?

[Reactie gewijzigd door Verwijderd op 22 juli 2024 18:28]

[ELD]

" Vorig jaar wisten onderzoekers van de Radboud Universiteit bijvoorbeeld die encryptie te omzeilen"

Voor een beperkte selectie van SSD's en afhankelijk van de specifieke configuratie.

[Berlinetta]

Ik denk dat het sowieso beter is om software encryptie te gebruiken, dan hoef je niet elke configuratie te testen.

Volgens mij heeft de i5 en i7 AES-NI encryptie.

Edit: "Alle Intel en AMD CPUs an de laatste paar jaar (vanaf Haswell) hebben AES-NI, zelfs Atom en Core i3"

Thanks @DarkJack

[Reactie gewijzigd door Berlinetta op 22 juli 2024 18:28]

[DarkJack]

Alle Intel en AMD CPUs an de laatste paar jaar (vanaf Haswell) hebben AES-NI, zelfs Atom en Core i3

[RedPixel]

Ho ho, ze hebben destijds willekeurig een aantal populaire SSDs gepakt, en wisten bij allemaal de encryptie te omzeilen.

[ELD]

Ho ho, ze hebben destijds willekeurig een aantal populaire SSDs gepakt, en wisten bij allemaal de encryptie te omzeilen.

Ik zou het paper nog eens lezen, want dit klopt niet.

[Reactie gewijzigd door ELD op 22 juli 2024 18:28]

[kodak]

Waar maar je uit op dat het willekeurig was? Dat lijkt namelijk niet in de paper of in de aankondiging van de universiteit te staan.

[Helium-3]

Dat die ssds getest zijn, betekent natuurlijk niet automatisch dat de gebreken zich verhouden tot die kleine selectie ssds. Ik ga er bovendien vanuit dat Microsoft niet 'zomaar' een beslissing als deze uitvoert, dus er zal waarschijnlijk goede motivatie achter zitten.

[Reactie gewijzigd door Helium-3 op 22 juli 2024 18:28]

[bjp]

leuk. Nu was je in de problemen als je een van de gekrakte SSDs had. Al de rest van veilig.

Nu is iedereen in de problemen als het softwarematig ding gekraakt is.

[KirovAir]

Nu is iedereen in de problemen als het softwarematig ding gekraakt is.

In de praktijk is dat niet zomaar mogelijk (mits je implementatie in orde is). Bij hardware fabfrikanten is dit vaak niet in orde blijkbaar. Microsoft daarentegen is softwareboer en heeft tegenwoordig op security zo veel ervaring dat een correctie implementatie vrijwel zeker is. Het is niet voor niks dat de Xbox One / 360 nagenoeg onkraakbare consoles zijn. (De 360 is weliswaar gekraakt, maar aanvalspunten in de hardware. De software is nog niemand doorheen gekomen.)

[Reactie gewijzigd door KirovAir op 22 juli 2024 18:28]

[segil]

Ik weet niet hoe het zit met andere merken, maar mijn Crucial MX300 SSD is een SED (Self Encrypting Disk) en disk encryption staat gewoon altijd aan. Of je het wilt gebruiken of niet. Alle data wordt encrypted opgeslagen. Enige verschil tussen wel/niet gebruiken is dat de encryption keys wel/niet gebruikt moeten worden voor toegang tot de disk.

Daarom ook dat het enablen van Bitlocker op deze SED 1 seconde duurt, aangezien encryption reeds actief is.

Dus als voortaan Bitlocker alleen nog software matige encryption ondersteunt, wordt voortaan alle data 2x encrypted opgeslagen op mijn disk.

Overigens was het nog wel een gedoe om deze disk goed te laten samen werken met Bitlocker, zie mijn artikel hierover.

[Reactie gewijzigd door segil op 22 juli 2024 18:28]

[OxWax]

Hier interessante uitleg er over die MX300 :

Many SSDs Don’t Implement Encryption Properly
Even if you enable BitLocker encryption on a system, Windows 10 may not actually be encrypting your data. Instead, Windows 10 may be relying on your SSD to do it, and your SSD’s encryption may be easily broken.

That’s the conclusion from a new paper by researchers at Radbound University. They reverse engineered the firmwares of many solid-state drives and found a variety of issues with the “hardware encryption” found in many SSDs.

The researchers tested drives from Crucial and Samsung, but we definitely wouldn’t be surprised if other manufacturers had major issues. Even if you don’t have any of these specific drives, you should be concerned.

For example, the Crucial MX300 includes an empty master password by default. Yes, that’s right—it has a master password set to nothing, and that empty password gives access to the encryption key that encrypts your files. That’s crazy.

https://www.howtogeek.com...t-your-ssd-on-windows-10/

[segil]

Bedankt voor het artikel, dat is goed om te weten! Ik had juist een SED gekocht vanwege de hardware encryptie, maar of dat nu nog zo'n slimme keuze was.....

[Yggdrasil]

Ik geloof dat bestaande hardware-encryptie niet wordt vervangen, dus in jouw geval gaat er geen software-encryptie toegepast worden zodoende dus ook geen dubbele encryptie.

[segil]

In het artikel staat toch dat standaard h/w encryption genegeerd wordt, dus dat zou betekenen als ik Bitlocker inschakel, alsnog 2x encyption plaats vindt. Tenzij je afwijkt van de standaard.

[Yggdrasil]

"Changes the default setting for BitLocker when encrypting a self-encrypting hard drive. Now, the default is to use software encryption for newly encrypted drives. For existing drives, the type of encryption will not change."
Bron: https://support.microsoft...ndows-10-update-kb4516071

[segil]

ja op die fiets, snap het. Als ik m'n disk opnieuw installeer, dan wordt het wel 2x encryption.

[PDZ]

Bitlocker ondersteunt nog steeds hardwarematige encryptie, er verandert dan ook niets aan je bestaande setup. Het is alleen de standaardinstelling die wordt gewijzigd, daar de hardwarematige encryptie op de meeste SSD's een wassen neus blijkt te zijn.

[CARLiCiOUS]

Speciaal voor jou: een live demo van een MX300 die wordt gekraakt

[segil]

top

[computerjunky]

Nou voor mijn thuis gebruik wil ik hemelaal niets met encryptie te maken hebben.
Ik heb geen gevoelige data maar wil niet het risico lopen alles kwijt te zijn als mijn windows het loodje legt dus die hele bitlocker en alle andere encryptie mogen ze houden.
Ik wil gewoon mijn drives in een andere pc kunnen hangen en kunnen backuppen.

Ik ken al meerdere gevallen van mensen die door een defecte windows niet meer bij hun data konden omdat windows het leuk geencrypt had en je er dus niet meer bij kon.
Als ze mijn data al stelen nemen ze mijn pc ook mee dus worst case heb ik er alleen zelf last van en best case heb ik er ook last van. het is een loss loss situatie.

[Verwijderd]

Tja dan hebben die mensen dus bewust de melding genegeerd om hun recovery key te bewaren. Ik heb echt nog nooit meegemaakt dat mensen hun data niet meer konden benaderen omdat hun PC kapot was. Maar ja, er was dan ook wel een recovery key voor handen...

[computerjunky]

Tja alleen raakt er wel eens wat zoek na een jaar of 6.

En dat terwijl voor 99% encryptie thuis helemaal niet interessant is maar wel her en der aangesmeerd word en helaas zelfs standaard in windows zit waar onwetende mensen nog wel eens wat aan en uit zetten omdat ze iets op prut sites of het nieuws of van andere mensen horen.

Er word altijd de kant van veiligheid en data protectie aangestipt maar de kant dat je zonder key gewoon alles kwijt ben word genegeerd.

[kodak]

Het toepassen van diskencryptie voor consumenten is geen aansmeren te noemen en wel degelijk relevant. Veel gebruikers hebben gevoelige gegevens over zichzelf, familie, zzp-gebruik en niet te vergeten persoonsgegevens van vrienden/kennissen/relaties op hun systeem staan. Die gegevens wil je niet in verkeerde handen hebben als je device zoek raakt. Omdat het risico op verlies/diefstal altijd aanwezig is en de gegevens niet opslaan vaak geen optie is blijft encryptie over in combinatie met een externe backup.

Als het excuus is dat je als gebruiker je sleutels tot de data kan kwijtraken dan heeft de gebruiker duidelijk niet begrepen hoe waardevol die sleutels zijn. Dat is niet de schuld van de encryptie.

Dat de lokale disk versleuteld is en je de sleutel kan kwijtraken is geen ramp als je een fatsoenlijke backup maakt, waar oplossingen voor bestaan die zelfs een klein kind nog kan begrijpen. Als je het dan nog voor elkaar krijgt om ook dan niet meer bij je gegevens te kunnen dan is afschuiven echt te goedkoop.

[computerjunky]

Zzp gebruik is niet prive en moet wat mij betreft minimaal op een aparte drive gedaan worden.


Verder stelt encryptie geen hol voor als get gehele apparaat gestolen is of kwijt raakt tenzij het bomvol protectie zit waardoor er niet eens ingeligd kan worden (dus meer als windows logon want dat is zo te omzeilen).

De enige realistische manier waarop data dus buitgemaakt wird is een hack en daar is een simpele consument simpelweg niet boeiend genoeg voor.

En nee veek gebruikers snappen totaal de waarde van die keys niet en dus is het niet standaard maar aan te bevelen.
Encryptie is binnen een paar jaar van niet bestaand voor thuisgebruik tot standaard aangesmeerd zonder enige educatie vam de gebruikers.
Nou weten wij tweakers het wel omdat we het onderzoeken maar voor de overige 99% geld dat niet.


Backup is nog zon ding 99‰ doet niet aan backups omdat ze ook daarvan de waarde niet beseffen.

[SED]

k ken al meerdere gevallen van mensen die door een defecte windows niet meer bij hun data konden omdat windows het leuk geencrypt had en je er dus niet meer bij kon.
Daarom moet je de key ook altijd goed bewaren als je dat zelf doet. Zonder key is inderdaad alles weg of beter onbereikbaar geworden.

[HollowGamer]

Je kan ook vraagtekens op het gebied van veiligheid bij Bitlocker zetten, als ik ten tijde van het stoppenzetten van Truecrypt de berichten moet geloven. Alles is beter dan geen encryptie, alleen een backdoor maakt dit principe dus weer ongedaan.

Ik heb een tijdje Bitlocker gedraaid zonder TPM, maar dat is gewoonweg niet te doen (niet meer willen booten na updates, data corruptie, etc.). Op Linux vind ik Luks veel fijner en kan je heel gemakkelijk sleutels in/toevoegen, makkelijk booten met een USB als er problemen zouden zijn en heb ik tot nu toe weinig last van performance gemerkt - iets dat ik op Windows dus wel merkte.

Ik ben tevens (ook) geen fan van encryptie op hardwarelaag niveau. Het is simpelweg niet te controleren en implementaties schijnen inderdaad echt bedroevend te zijn, met meestal data verlies als gevolg. Tegenwoordig zijn CPUs snel genoeg en kan elke zakelijke onderneming prima met software encryptie draaien. Het liefst zie ik ook thuisgebruikers het toepassen, maar dat lijkt me enkel als we eindelijk het gewoon gaan verplichten, zoals nu ook op Android gaat gebeuren als het goed is.

[Reactie gewijzigd door HollowGamer op 22 juli 2024 18:28]

[cdwave]

Moderne CPUs (onder andere Intel en ARM) hebben AES instructies waarmee de crypto een stuk sneller en zuiniger gedaan kan worden. Dat is ook veel praktischer in gebruik dan volledige hardware implementatie, omdat je de software threading en synchonisatie kunt gebruiken voor het afhandelen van gelijktijdige toegang.
Ook zonder die extra's is AES encryptie prima te doen op een CPU.

Encryptie op hardware blijft beter beperkt tot TPM modules enzo die alleen key management en challenge/response doen. Daar heeft het toegevoegde waarde.

[cruysen]

Je kan ook vraagtekens op het gebied van veiligheid bij Bitlocker zetten, als ik ten tijde van het stoppenzetten van Truecrypt de berichten moet geloven.

En hoe zit het dan met VeraCrypt?
Dit is toch z'n beetje de opvolger van Truecrypt?

[HollowGamer]

Op beide zijn audits uitgevoerd en ook lekken gevonden. De verdere status weet ik van beide niet, maar daarvoor kun je tegenwoordig CVE opvragen als het goed is.

[segil]

Zover ik weet is nooit iets bewezen van een backdoor in Bitlocker. Verder werkt Bitlocker prima met een pincode (zonder TPM), ook na updates.

[HollowGamer]

Het is niet bewezen inderdaad, maar niemand kan zomaar die code inzien zonder een geldig verzoek aan MS. We moeten ze dus maar op hun woord geloven, dat vind ik tegenover andere opensource varianten wel een minpunt.

[SED]

Luks is niet de beste keuze:
https://0x00sec.org/t/bre...asswords-luks-devices/811

[HollowGamer]

Wat ik zo begrijp uit het artikel kan het met andere encryptie technieken ook, als je maar toegang hebt tot het geheugen (ook in cold boot) waar het wachtwoord eerst in is ingeladen. Diezelfde methode zal dus ook wel werken met Bitlocker.

Uiteindelijk is alles te kraken, dat maakt Luks niet perse minder onveilig.

[Reactie gewijzigd door HollowGamer op 22 juli 2024 18:28]

[SED]

luks is gekraakt bitlocker niet.
aan jou de keuze.

[lennardrk]

Ik gebruik al een tijd de softwarematige encryptie van bitlocker. Persoonlijk merk ik geen verschil in performance met of zonder encryptie op een m.2 ssd.

[CAPSLOCK2000]

Lastig en een beetje jammer. Ingebouwde encryptie zou een stuk sneller en fijner kunnen werken dan alles overlaten aan je CPU. Ik begrijp het wel, want ik heb al iets te vaak gezien dat hardware-encryptie toch niet zo goed blijkt te werken. De encryptie zelf is meestal wel OK, maar de rest van de hardware moet ook gebouwd zijn voor veiligheid en daar schort het vaak aan. Er zijn ontzettend veel zijstraten waarlangs er informatie kan lekken die afbreuk doet aan de veiligheid van de crypto.

[the_shadow]

Er zijn ontzettend veel zijstraten waarlangs er informatie kan lekken die afbreuk doet aan de veiligheid van de crypto.

Met BitLocker of andere full-drive encryptie heb je hoe dan ook alleen maar veiligheid op het moment dat het systeem uit staat (data at rest). Wanneer het geboot is en ingelogd kan je gewoon bij de gegevens (d.m.v. malware). Ieder scenario heeft z'n eigen mitigerende maatregels om te voorkomen dat data in verkeerde handen komt.

[Verwijderd]

Ik snap je comment niet helemaal. Het is toch overduidelijk dat drive encryptie daarvoor wordt gebruikt?

[iDEOwen]

Wat ik eigenlijk bizar vind is dat anno 2019 je niet op elke Windows 10 computer Encryptie aan kan zetten (zowel Bitlocker of 'Device Encryption'). Elke telefoon tegenwoordig (iOS & Android) bieden deze optie aan (en niet te vergeten alle Macs sinds 10.7). En dan maakt het even niet uit of het nu hardware/software encryptie is.

[TijsZonderH]

Ik kan hier met mijn hoofd ook nog steeds niet bij.

[Verwijderd]

Ik zou hier eigenlijk graag een achtergrondartikel over willen indien mogelijk.

[locke960]

De gemiddelde Windows 10 Home gebruiker maakt geen backups en zou geen updates installeren als het systeem het niet af zou dwingen. Diezelfde gebruiker gaat waarschijnlijk ook zijn encryptiesleutel niet exporteren en, als hij dat wel doet, niet veilig opbergen.

Op dat moment kan encryptie een probleem worden. Hetzij door dataverlies, omdat de gebruiker de sleutel niet meer heeft, of omdat de data toch gestolen wordt omdat de gebruiker de sleutel niet veilig heeft opgeborgen. Door verkeerd omgaan met de tool is er een vorm van schijnveiligheid ontstaan.
Diezelfde gebruiker gaat echter wel via twitter op Microsoft schelden als het mis gaat.

Overigens, lijkt het er op dat Windows 10 Home wel device encryption (subset van Bitlocker) ondersteunt, mits je hardware het ondersteund en je een Microsoft Account gebruikt om in te loggen. Dan wordt je key op de Microsoft servers geback-upped.

[Reactie gewijzigd door locke960 op 22 juli 2024 18:28]

[dj.verhulst]

jammer ik denk dat het wel een goede zaak is dat dit soort dingen makkelijk te gebruiken is.
als je laptop/pc gestolen worden met niet zo eenvoudig bij je spullen kunnen, neem wel een cloud back up of doe iets met een NAS of usb opslag , want sleutel weg = is alles weg.

[spoor12b]

Zoals een andere Tweaker ook al schreef: de meeste moederborden ondersteunen helaas niet de juiste EFI commando's om Bitlocker met Edrive te laten werken met een nvme ssd. Ondanks de risico's zou ik dit graag thuis gebruiken omdat hardwarematige encryptie veel minder belastend is voor de SSD.

Ook met een recent Asus X399 bord werkt het dus gewoon niet...

Zie ook deze thread voor meer info: https://us.community.sams...dware-encrypt/td-p/330809