Vraag:
Is de laptop "veilige slaap" -modus theoretisch mogelijk?
Peter Rankin
2017-05-26 19:05:38 UTC
view on stackexchange narkive permalink

Voor laptops met volledige schijfversleuteling of thuismapversleuteling is een van de risico's als deze wordt gestolen in de slaapstand, dat de coderingssleutel in het geheugen wordt opgeslagen en kan worden gelezen als een aanvaller weet hoe. Voor mij lijkt het erop dat besturingssystemen in theorie een 'veilige slaap'-optie zouden moeten hebben, waarbij de sleutel uit het geheugen wordt gewist voordat de slaapstand wordt geactiveerd, en bij hervatting moet de gebruiker een wachtwoord opgeven om de coderingssleutel te ontgrendelen , zoals door een koude laars. Alle processen, behalve het vergrendelingsscherm, zouden niet doorgaan totdat de coderingssleutel in het geheugen is hersteld.

Ik realiseer me dat dit zou betekenen dat de computer geen geplande taken kan uitvoeren in de slaapstand, maar de meeste gebruikers zouden dat waarschijnlijk niet doen dat kan me niks schelen. En misschien zouden bestuurders of andere obstakels ervoor zorgen dat dit niet realistisch is.

Zijn er redenen waarom een ​​"veilige slaap" -optie niet gemakkelijk kan worden geïmplementeerd?

Ik vind het persoonlijk een raadsel waarom Microsoft deze functie niet adverteert in de Windows-familie, omdat (zoals aangegeven door de antwoorden) zelfs een beginnende kernelprogrammeur gemakkelijk de sleutel uit RAM kan wissen voordat hij de CPU vertelt om te gaan slapen
Dit bestaat al met Apple's FileVault 2 (tot op zekere hoogte): https://security.stackexchange.com/a/34597/64411
Zolang de computer vergrendeld is bij het hervatten, wat maakt het dan uit of de sleutel in het ram is?De aanvaller kan de computer niet ontgrendelen en vervolgens root-toegang krijgen om de sleutel te krijgen.
U hoeft niet in te loggen om de inhoud van het geheugen te lezen.DMA is mogelijk via verschillende interfaces zoals PCIe, Firewire en ExpressCard.
@DylanKnoll Moderne op Windows gebaseerde besturingssystemen zullen DMA van die interfaces blokkeren wanneer het systeem is vergrendeld of een gebruiker niet actief is aangemeld.
Windows 10 en (ik neem aan) Server 2016 doen dat wel.Eerdere versies zijn kwetsbaar.Windows 7 en 8.1 worden nog steeds ondersteund en op grote schaal geïmplementeerd.
Vijf antwoorden:
peterh - Reinstate Monica
2017-05-26 19:49:57 UTC
view on stackexchange narkive permalink

Ja. Het zou gemakkelijk haalbaar kunnen zijn, hoewel het kernelondersteuning vereist om dit correct te doen.

In het geval van suspend-to-RAM moet de sleutel uit het RAM worden verwijderd en in het geval van suspend-to-disk , vanuit het RAM en ook vanaf de schijf (of het kan versleuteld op de schijf worden opgeslagen).

Er moet ook een minimale invoer worden verstrekt om de sleutel / herverificatiegegevens in de vroege opstart- / ontwaakfase te krijgen.

Ik zie geen technische obstakels; de waarschijnlijke reden dat het tot nu toe niet ontwikkeld was, was het gebrek aan interesse. Scenario's waarbij directe RAM-toegang van een werkende laptop een reëel beveiligingsrisico vormt, zijn zeer zeldzaam.

Ik denk niet dat het nodig is om de sleutel van de schijf te verwijderen, omdat de geheugendump op de schijf wordt gecodeerd, daarom is de sleutel vereist om de sleutel te krijgen.
@wizzwizz4 Tricky :-) Juist.Ik heb het bericht bijgewerkt.Bedankt.
En dan is deze minimale input de sleutel tot de sleutel, en die moet ergens opgeslagen worden.
@Mindwin het lijkt erop dat u antwoordt op een verwijderde opmerking.
@wizzwizz4 de sleutel kan worden opgehaald met dezelfde opstartverificatie, zoals TPM- of BitLocker-wachtwoord
@usr-local-ΕΨΗΕΛΩΝ De sleutel zou nodig zijn om de kopie van de sleutel op te halen die is opgeslagen in de geheugendump van het geheugen met de sleutel op de met een sleutel versleutelde harde schijf.
Je zei zelf in de allereerste opmerking: de sleutel is samen met de geheugendump versleuteld.De kernel moet er dus alleen voor zorgen dat het fysieke RAM-geheugen geen spoor van de sleutel in platte tekst bevat, die kan worden hersteld wanneer deze weer tot leven komt met dezelfde opstartverificatie, bijv.hardware verifiëren en de TPM vragen
Ik geloof dat Linux dit kan doen als je dm-crypt gebruikt op je slaapstandvolume.
@chrylis Je moet de sleutel in het systeem injecteren tijdens de wakeup-reeks, voor zover ik weet, is daar geen in-kernel-ondersteuning voor.Als je dit vanuit de gebruikersruimte doet, kun je niet meer wakker worden.
@chrylis Op Linux kan het werken door de inloggegevens op te halen in de vroege opstartscripts en vervolgens de kernel opnieuw te starten met het kexec-mechanisme, waarbij ze de inloggegevens verstrekken.Dit zou alleen een herstart van de slaapstand naar de schijf mogelijk maken, maar het zou werken.Het zou geen erg grote patch zijn in de initramfs van welke Linux-distributie dan ook.
@peterh Misschien zag ik een hack die Grub gebruikte om naar de wachtwoordzin te vragen?
@chrylis Voor zover ik weet, doodt het wakeup-proces alles in de actieve kernel.Hoe sla je de sleutel op zonder kernelondersteuning?Trouwens, hoe kun je zelfs de lvm (of een dm-crypt) -volume starten?
@peterh https: // wiki.archlinux.org / index.php / GRUB # Boot_partition
@chrylis Het is bedoeld om het systeem op te starten vanaf een crypto-apparaat en niet om het eruit te ontwaken.
Voor zover ik weet, is de slaapstandherstelsequentie in wezen hetzelfde als de opstartvolgorde, alleen wordt de normale stroom vroegtijdig verlaten.Deze setup trekt het FDE-ingangspunt naar Grub, zodat de kernel toegang heeft tot cryptosleutels op bootstrap.Ik heb het zelf nooit gebruikt, maar ik noemde het als een mogelijke setup die ik heb gezien.
@chrylis Voor zover ik weet, vindt deze "vroege exit" plaats voordat de gebruikersruimte was gestart.En de LVM-init kan alleen plaatsvinden vanuit de gebruikersruimte.Wat is "FDE"?
ISMSDEV
2017-05-26 19:10:47 UTC
view on stackexchange narkive permalink

Dit zou het geval zijn voor het kiezen van slaapstandopties in plaats van slaapstand. Slaap moet het geheugen actief houden, wat een snelle start mogelijk maakt; in de slaapstand is de machine niet helemaal uitgeschakeld.

In de slaapstand wordt het geheugen naar de schijf geschreven zodat de computer de stroom kan verwijderen. Hierdoor wordt op zijn beurt ook de coderingssleutel verwijderd. Daarom moet u in de slaapstand de opstartdecryptiesleutel invoeren.

Als beveiliging belangrijker is dan de snelheid van 'opstarten' met slaapstand, ga dan naar de slaapstand.

Een van de risico's als het wordt gestolen in de slaapstand, is dat de coderingssleutel wordt in het geheugen opgeslagen en kan worden gelezen als een aanvaller weet hoe.

Het is waarschijnlijker dat de aanvaller niet de moeite neemt om de coderingssleutel te herstellen. Ze zouden op dit punt proberen toegang op OS-niveau te krijgen als ze probeerden uw gegevens te stelen.

Als het besturingssysteem de coderingssleutel wist voordat het sluimerde, zou zelfs toegang op OS-niveau een aanvaller niet helpen, aangezien het besturingssysteem zelf de coderingssleutel niet kent zonder het wachtwoord bij een koude start, correct?
Ja klopt, maar in slaap wordt de sleutel niet gewist zoals u zegt.De aanvaller in dit voorbeeld dat ik bedoelde, zou proberen in te loggen op Windows om bij uw gegevens te komen, waarom zou u zich in dit stadium bezighouden met de coderingssleutel?Het is al gedecodeerd.Aan de andere kant, als het besturingssysteem de sleutel in slaapstand wist, zou het zonder de coderingssleutel zijn en kan het niet veel doen.Mogelijk zijn dingen nog steeds niet versleuteld in het hoofdgeheugen, wat niet ideaal is als de laptop niet wordt gebruikt.Het besturingssysteem zou ook helemaal niets naar de schijf kunnen lezen / schrijven.
@ISMSDEV De vraag was of het mogelijk is, niet of het momenteel wordt gedaan, en het verwijderen van de sleutel uit het geheugen is zeker mogelijk.
@Solomonoff'sSecret: Het geciteerde deel van de vraag gaat over hoe de zaken er momenteel voor staan.De vraag zegt dat de aanvaller momenteel de coderingssleutel kan lezen als hij / zij weet hoe;ISMSDEV zegt alleen dat een meer realistische aanval is om het besturingssysteem normaal te gebruiken, in plaats van iets speciaals te doen om de inhoud van RAM te extraheren.(Dat is natuurlijk een kanttekening. Ik denk niet dat het een essentieel onderdeel van dit antwoord is.)
h22
2017-05-27 11:59:47 UTC
view on stackexchange narkive permalink

Beveiligde gevoelige gegevens (zoals teksten van de bekeken e-mails) kunnen overal in het RAM staan, het is niet voldoende om alleen een coderingssleutel te bewaren (als u al in deze richting gaat).

versleutelde RAM is wellicht mogelijk, maar vereist ontwikkelingen in de hardwarelaag. RAM is willekeurige toegang, elke cel moet op elk moment kunnen worden gelezen. Dit beperkt de keuze van cijfers. Maar het kan mogelijk zijn om een ​​zeer grote sleutel te gebruiken die tijdens de slaap is versleuteld met het cijfer van uw keuze.

Fis
2017-05-26 20:18:52 UTC
view on stackexchange narkive permalink

Het hangt ervan af hoe de enc / dec-sleutel wordt verkregen. Als de sleutel bijvoorbeeld is opgeslagen op TPM en de NVRAM-lezen wordt vergrendeld zodra de sleutel is ontzegeld en gelezen door het besturingssysteem, is er geen optie om deze opnieuw te lezen tot de volgende keer opnieuw wordt opgestart. Ik zou zeggen dat de slaapmodus in dit geval niet kan worden beschouwd als hard of soft reboot.

Een andere coderingssoftware kan het gebruikerswachtwoord gebruiken om de enc / dec-sleutelopslag op de schijf te openen en de encryptie te verkrijgen / dec-toets eruit, dus in dat geval zou het geen probleem zijn.

Overigens is het tegenwoordig met DDR3 erg moeilijk om de sleutel uit het geheugen te halen.Er waren enkele onderzoeken op internet over het koelen van geheugenmodules en deze op een andere pc te lezen, maar zonder succes.We hebben dit ook zonder succes getest.en met DDR4 is het volkomen onmogelijk.
Zeer interessant over DDR4.Heeft u een bron die dit bevestigt?
Ik weet niet zeker of het nog steeds hetzelfde document is dat ik in het verleden heb gelezen, maar probeer dit document, het ziet er goed uit: https://web.eecs.umich.edu/~taustin/papers/HPCA17-cold boot.pdf
Volgens de krant - "... DDR4 scramblers bieden nog onvoldoende bescherming tegen kou opstartaanvallen.We beschrijven een proof-of-concept-aanval die uitpakt geheugenresidente AES-sleutels, inclusief schijfversleutelingssleutels. "
Ik ben er vrij zeker van dat het in ieder geval heel erg moeilijk zal zijn :)
In het geval dat de sleutel afkomstig is van een TPM, laat u het besturingssysteem IO opschorten en de sleutel in het geheugen versleutelen voordat u opschort.Vervolgens, bij het hervatten, voordat u IO hervat, vraagt u om het wachtwoord om de sleutel te ontgrendelen.
:) Hoewel het interessant kan klinken, heb je het probleem gewoon een stap verder verplaatst.Met welke sleutel versleutelt u de sleutel in het geheugen?Waarschijnlijk met een andere sleutel opgeslagen in het geheugen of hard gecodeerd in de software zelf.
@fis Het ziet er niet erg moeilijk uit.De scrambler is ontworpen met het oog op gegevensintegriteit, niet met beveiliging.Het scambling is eenvoudig XOR.Als je XOR een 0 hebt, krijg je de sleutel.Ze zochten gewoon door het geheugen om te vinden wat waarschijnlijk gecodeerde nullen zijn, en gebruikten dat als de sleutel.
peterph
2017-08-04 02:59:43 UTC
view on stackexchange narkive permalink

Zoals @ h22 aangeeft, moet u het RAM-geheugen versleutelen tijdens de slaapstand. Eigenlijk is het dat of het afsluiten van programma's die mogelijk gevoelige informatie in het geheugen hebben geladen en het vrijgemaakte geheugen wissen en het ontkoppelen van alle bestandssystemen die de gevoelige informatie bevatten (en clear alle caches die mogelijk betrokken zijn). Welk soort verstoort iemands workflow en maakt opschorting naar RAM op zijn best een betwistbaar punt (qua comfort).

Dus als je aan de veilige kant wilt blijven, moet je opschorten naar schijf - de codering in deze geval is een opgelost probleem. Een alternatief is het versleutelen van de ram bij opschorten en ontsleutelen bij hervatten - maar dat zou je in de volgorde van opschorten naar schijf brengen (qua tijd en stroom).



ⓘ
Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...