{"id":182443,"date":"2026-07-02T22:53:28","date_gmt":"2026-07-02T20:53:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/problemy-s-ochistkoj-klyuchej-shifrovaniya-diska-iz-ozu-pri-perehode-linux-v-zhdushhij-rezhim"},"modified":"2026-07-02T22:53:28","modified_gmt":"2026-07-02T20:53:29","slug":"problemy-s-ochistkoj-klyuchej-shifrovaniya-diska-iz-ozu-pri-perehode-linux-v-zhdushhij-rezhim","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/problemy-s-ochistkoj-klyuchej-shifrovaniya-diska-iz-ozu-pri-perehode-linux-v-zhdushhij-rezhim","title":{"rendered":"Problemi nella pulizia delle chiavi di crittografia del disco dalla RAM durante la modalit\u00e0 di sospensione di Linux.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Durante il porting dello strumento cryptsetup-suspend per NixOS \u00e8 stato rilevato un errore nel sotto-sistema di crittografia del disco LUKS (Linux Unified Key Setup), a causa del quale, a partire dal kernel Linux 6.9 (commit problematico), rilasciato a maggio 2024, la pulizia delle chiavi di crittografia dalla memoria volatile ha smesso di funzionare quando il sistema entra in modalit\u00e0 sospensione. <\/p>\n
Lo strumento cryptsetup-suspend \u00e8 utilizzato in Debian per il blocco automatico delle partizioni LUKS prima di entrare in modalit\u00e0 sospensione. Si presuppone che, in caso di furto del laptop messo in modalit\u00e0 sospensione, l'attaccante non avr\u00e0 accesso ai dati, poich\u00e9 sar\u00e0 necessario inserire una password al risveglio per riottenere l'accesso ai dati crittografati. A causa di un errore nel kernel Linux, dopo il blocco della partizione LUKS mediante il comando «cryptsetup luksSuspend», le chiavi non venivano rimosse dalla memoria RAM e rimanevano visibili tramite \/proc\/keys, consentendo a un attaccante di estrarle, ad esempio, con il metodo «cold boot» e utilizzarle per accedere ai dati. <\/p>\n
L'assenza di una pulizia delle chiavi \u00e8 stata riscontrata durante il debug di uno stato di race, che ha causato problemi nel passaggio alla modalit\u00e0 di attesa. L'errore \u00e8 emerso dopo il refactoring nel kernel 6.9, che legava le chiavi al thread chiamante e avrebbe dovuto eliminarle al suo completamento, ma in realt\u00e0 rimanevano in memoria. \u00c8 stato proposto un patch a una riga da includere nel kernel di Linux, che risolve l'errore riscontrato. <\/p>\n
Questa patch non \u00e8 stata accettata nel kernel, poich\u00e9 \u00e8 stata rilevata una mancanza: la patch funziona solo per dispositivi di archiviazione fisici, ma non per dispositivi virtuali loop. Invece di correggere il problema lato kernel, gli sviluppatori dello strumento cryptsetup hanno proposto una soluzione alternativa per la cancellazione delle chiavi. Questa modifica \u00e8 gi\u00e0 stata accettata e far\u00e0 parte del rilascio di cryptsetup 2.8.7. <\/p>\n