In questo articolo viene mostrato quanto sia facile bypassare le passphrase ATA del BIOS e termina con il fatto che l'utilizzo dell'API SED (self-Encryption Disk) dei dischi all'interno del sistema operativo non darebbe un impatto sulle prestazioni. Su Windows questa API si chiama Microsoft eDrive. Vedi qui e qui .
Qualcuno sa se Linux può comunicare direttamente con il livello SED, quindi Linux gestisce la passphrase?
Risposte:
Ho trovato GPL'd sedutil che consente di gestire i SED a "livello SED":
msed - Gestisci unità con crittografia automatica
Questo programma e la relativa immagine di autorizzazione pre-avvio consentono di abilitare il blocco nei SED conformi allo standard TCG OPAL 2.00 sulle macchine bios.
L' autore di msed ha collaborato con Drive Trust Alliance per creare una soluzione aziendale GPL:
Sto unendo le forze con Drive Trust Alliance (Drive-Trust-Alliance su GitHub) per offrire alla community i migliori strumenti SED open source possibili.
Non so se questo stia davvero rispondendo alla domanda che volevi. Tuttavia ho usato le informazioni su questa pagina: https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
Ho avuto un SSD con crittografia automatica. Ho usato il comando hdparm per impostare una password utente, una password principale e impostare la capacità della password principale su "massimo" in modo che una password principale non possa essere sbloccata o disabilitata, ma solo cancellare. (Il mio BIOS non mi ha permesso di impostare una password principale o la modalità principale. Questo è davvero insicuro in quanto il produttore (Dell) ha la password principale e probabilmente qualsiasi rappresentante del servizio può ottenerla.)
Un buon BIOS / UEFI dovrebbe sbloccare il driver e bloccarlo in modo che la password non possa essere disabilitata dal sistema operativo. Se il firmware lascia l'unità bloccata, potrei vedere come la password potrebbe essere disabilitata.
Tuttavia, tutto ciò presuppone che il firmware delle unità non sia privo di backdoor o sicurezza. L'articolo che citi sembra implicare che questo è comune. Mi chiedo quanto "facile" sia il livello di bios da sconfiggere poiché l'articolo afferma che l'unità deve essere già sbloccata. L'articolo non diceva se la sicurezza dell'unità era bloccata o meno.
Se non ti fidi del firmware delle unità, non vedo come nessuna delle funzionalità della password ATA possa aiutarti. Per beneficiare ancora dell'azionamento HW, è necessario accedere al motore AES stesso ed essere in grado di programmare autonomamente la chiave AES.
era: {Non conosco una simile API di livello HW. Sarei interessato se qualcuno avesse un riferimento.}
Scusa, avrei dovuto leggere tutti i tuoi riferimenti prima di rispondere. Gli standard in questione sono TCG Opal 2.0 e IEEE-1667. Sembra che il 1667 passi a un protocollo di risposta alla sfida sullo scambio di password in chiaro di ATA. Tuttavia, mi sembra che le password siano ancora memorizzate nell'unità e dovresti comunque fidarti del firmware dell'unità.