Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Im UEFI HDD-Passwort gesetzt - ist die SSD jetzt verschlüsselt oder nicht?
Moin Leute, ich habe eine vermutlich etwas dumme Frage... ich mach's mir einfach und verschlüssel' meine Thinkpad-SSD (vermeintlich) indem ich im BIOS einfach das HDD-Passwort setze.
Wie verifiziere ich denn danach, ob die Platte tatsächlich verschlüsselt ist?
Auf dem Rechner läuft Debian Bookworm und es handelt sich um ein X390. Kann ich das aus dem laufenden System heraus irgendwie erkennen?
Ich verstand das BIOS-HDD- Passwort bislang so, dass nur der Zugriff bzw. Zugang auf die HDD per Passwort und dann eben nur auf einem Lenovo System möglich ist, dürfte aber letztlich auf das gleiche hinauslaufen.
Wenn ich die Geschichte richtig verstehe, blockiert ein HDD-Passwort lediglich den Zugriff auf die HDD. Eine Verschlüsselung findet nur dann statt, wenn die HDD-Hard- und Firmware dieses Feature mit an Bord haben.
Du kannst ins Datenblatt der SSD schauen, ob es sich um ein Self-Encrypting-Drive handelt. In ThinkPad Produktbeschreibungen taucht dazu häufig das Stichwort OPAL2 Standard auf.
Direkt überprüfen kannst Du es imho nicht. Da müsstest Du mit Laborequipment am Controller vorbei direkt auf die Flashchips zugreifen, um zu schauen ob dort Klartext oder chiffrierter Text steht.
Ich bevorzuge ebenfalls LUKS.
EDITH sagt: nachdem, was ich auf die Schnelle gefunden habe, gehe ich vorsichtshalber nicht davon aus, dass das HDD-Passwort bei einem OPAL SED Drive automatisch die Verschlüsselung aktiviert. Dafür scheinen separate, OS-spezifische Tools nötig zu sein. LUKS ist einfacher und funktioniert zuverlässig.
Ich habe natürlich eine SSD genutzt, die das Feature unterstützt, auf einem Rechner der das Feature unterstützt - ich bin nur überrascht dass man gar keine Rückmeldung bekommt, dass es funktioniert/läuft
Mir ist aber gerade eine Möglichkeit bewusst geworden: Ich baue die SSD einfach die Tage in einen M.2 auf USB-C Adapter ein und schaue, ob ich sie als externes Laufwerk lesen kann. Erwartung wäre, dass das halt nicht geht... muss mal auf der Arbeit gucken ob jemand ein M.2 Caddy hat.
LUKS kenne ich natürlich schon, aber ich denke mir halt wozu kompliziert und mit Performance-Impact (wenn auch nicht spürbar), wenn's doch auch einfacher/nativ und vollständig in Hardware geht? Datenverlust ist überhaupt kein Thema (und es ist eh das zweite X390 und gefühlt das zehnte Thinkpad im Haus, mit dem man die Entschlüsselung vornehmen könnte), daher wollte ich eben auf diesem Rechner mal die eingebaute Variante ausprobieren.
Mir ist aber gerade eine Möglichkeit bewusst geworden: Ich baue die SSD einfach die Tage in einen M.2 auf USB-C Adapter ein und schaue, ob ich sie als externes Laufwerk lesen kann. Erwartung wäre, dass das halt nicht geht... muss mal auf der Arbeit gucken ob jemand ein M.2 Caddy hat.
Das wird vermutlich tatsächlich nicht funktionieren. Sagt aber auch nicht aus, ob die Daten verschlüsselt sind oder nicht. Das hängt, wie hier schon korrekt gesagt wurde, von der Implementierung in der Firmware der SSD ab. Kann sein, muss aber nicht. Manche machen es, manche (viele?) nicht.
Ich baue die SSD einfach die Tage in einen M.2 auf USB-C Adapter ein und schaue, ob ich sie als externes Laufwerk lesen kann. Erwartung wäre, dass das halt nicht geht.
Es dürfte nicht gehen, auch, wenn nur ein Passwort vergeben und die SSD nicht verschlüsselt ist. Externe Laufwerke mit HDD-Passwort werden (fast?) immer als unbekannter oder ähnliche Datenträger angezeigt. Nach meinem Kenntnisstand werden Laufwerke mit HDD-Passwort nur richtig erkannt, wenn sie eingebaut sind.
Ich dachte Systeme, die das HDD-Password nicht unterstützen würden einfach nichts abfragen und einfach alles anzeigen. Dann ist die HDD-Password Funktion (ohne Verschlüsselung wie seit eh und je) ja gar nicht so nutzlos wie ich dachte - Normalos, die nicht mal eben das Controller-IC samt FW tauschen können, kommen ja dann auch ohne Verschlüsselung nicht an die Daten - vorausgesetzt das PW ist in der FW sinnvoll implementiert.
HDD-Passwort und HDD-Verschlüsselung sind zwei verschiedene Dinge.
Das HDD-Passwort wird mit Hilfe eines BIOS-Algorithmus durch einen Hash gebildet und dann abgespeichert.
Aus "Password1234" wird dann im HDD-Controller z.B. "h3y?hn))N5n=JG7-@+Ps}i%-6M0)`me?}:f8PxqQD4)pQ>$8n`D{S%8?=)st1]-!".
Da der BIOS-Algorithmus immer derselbe bleibt, wird bei Eingabe des richtigen Passworts auch immer derselbe Hash gebildet und so die HDD entsperrt.
Innerhalb des gleichen Rechnertyps mit gleicher BIOS-Version (z.B. alle Thinkpads der *61-Generation oder alle ThinkPads der *20er Generation) kann man die Platten tauschen und eine Platte an einem ähnlichen ThinkPad entsperren, da der Hash-Algorithmus derselbe ist. Ist der Hash-Algorithmus von einer anderen Generation oder einem anderen Hersteller oder sitzt die HDD am falschen HDD-Port, z.B. über USB, funktioniert das Entsperren nicht.
Durch die Hash-Bildung, (deswegen wurde sie erfunden), kann man nicht rückwärts auf das Passwort schließen, falls man Hardware-Zugriff auf den HDD-Controller hat.
Soll das Passwort bzw. sein abgespeicherter Hash auf der HDD durch ein spezielles BIOS-Programm entfernt werden, gehen auch sämtliche Daten verloren, die auf der HDD gespeichert waren. Sie werden sicherheitshalber gelöscht, aber man kann die HDD/SSD dann wiederverwenden.
Ist man Admin des ThinkPads mit einer Passwort-HDD, und kennt das BIOS-Passwort als auch das HDD-Passwort, kann durch Änderung des HDD-Passworts die HDD entsperren, in dem man einfach kein neues Passwort mehr eingibt.
Beim HDD-Passwort wird also nur das Passwort verschlüsselt und der Zugang zu den verschlüsselten oder unverschlüsselten Daten geregelt.
Bei der tatsächlichen Daten-Verschlüsselung unterscheidet man hardware-unterstützte und software-unterstützte Verschlüsselung.
Man braucht ein Verschlüsselungsprogramm wie Bitlocker, LUKS oder VeraCrypt.
Erkennt ein Verschlüsselungsprogramm, dass ein Krypto-Chip im HDD-Controller sitzt, benutzt er diesen statt der Softwarelösung und kann quasi in Echtzeit verschlüsselt Lesen und Schreiben.
Bei softwarebasierter Verschlüsselung gehen etwa 5-10% der Lese- und Schreibleistung verloren.
Das Hashing findet natürlich nicht nur beim HDD-Passwort statt, sondern praktisch auch bei jeder anderen Verschlüsselung. Es wird eigentlich nie mit dem Passwort verschlüsselt, sondern immer mit einem Hash davon. ggf. noch plus Salt. Und ggf. wird nicht nur einmal gehasht, sondern (vereinfacht gesagt) mit einer Passwortableitungsfunktion viele tausend Mal, um die Rechenleistung (und Arbeitsspeicherauslastung) bei Brute-Force-Angriffen weiter zu erhöhen und die Möglichkeit, mit spezieller Hardware das ganze zu beschleunigen, zu erschweren.
Wenn das Verschlüsselungsprogramm einen Krypto-Chip in der HDD/SSD erkennt, nutzt er nicht automatisch diesen. Das hat think_pad hier sehr viel einfacher dargestellt als es ist. LUKS oder VeraCrypt nutzen ihn nie. BitLocker automatisch auch gar nicht mehr. Man kann BitLocker aber dazu überreden, Stichwort eDrive. Bei OPAL-Lösungen wird auch der Chip genutzt, aber das findet man praktisch nur im Unternehmensumfeld. Daher ist die Verwendung der internen Hardware-Kryptografie eher die Ausnahme als die Regel.
Bei softwarebasierter Verschlüsselung gehen durchaus sehr viel mehr als 5-10% der Leistung verloren. Kommt drauf an, was man als Kriterium verwendet. Siehe dazu die Beiträge hier: https://thinkpad-forum.de/threads/edrive-auf-neueren-laptops-hier-p14s-gen3-gilt-aber-auch-für-andere.234111/page-2#post-2360231 Da spechen wir eher von -45 bis -70%, wobei die größten Einbußen bei 64 gleichzeitigen Threads passieren, wohingegen im Alltag meist nur 1-2 Threads gleichzeitig zugreifen, daher ist die gefühlte Performanceeinbuße geringer, wenn auch trotzdem vorhanden.
Die SSDs (und der Rest vom Gerät) unterstützen OPAL, ja. Aber damit man das nutzt, muss man es explizit aktivieren. Dafür braucht man recht spezielle Software, die man praktisch nur im Unternehmensumfeld findet. Ohne diese Software wird OPAL aber nicht genutzt, dann hilft einem die mögliche Fähigkeit auch nichts.
Vielleicht noch am Rande: Bios-HDD-Passwort ist abwärts-, jedoch nicht aufwärtskompatibel. Eine auf einem X230 BIOS gesetzte Sperre wird nicht auf einem T500 erkannt, umgekehrt jedoch schon.
Gibt es dazu irgendwo offizielle Dokumentation die halbwegs an Endanwender (oder zumindest Admins) gerichtet ist? Ich finde überall nur entweder Marketingfloskeln, User-Meinungen oder Spezifikation (und die interessiert mich ja nicht - ich will Infos zur Implementierung, besonders Lenovo-seitig).
Laut der "landläufigen Meinung des Internetvolks" ist OPAL einfach ein Standard für SED, und genau diesen nutzt dann angeblich auch Lenovo mittels HDD-Password, wenn die SSD das unterstützt. Die Software wird nur benötigt, wenn man kein kompatibles BIOS/UEFI im Gerät hat und trotzdem OPAL nutzen will, und dabei geht's um Dinge wie sedutil oder die Samsung Software. Ich befürchte entweder hast Du vollkommen recht oder die Wahrheit liegt irgendwo dazwischen.
Du hast nicht zufällig noch nen Tipp für ne verlässliche Quelle oder? Aus der Spec selbst werde ich nicht so richtig schlau - ist ja nur ne Spec und keine Beschreibung der Lenovo-seitigen Implementierung...
-edit- Ich habe dazu noch folgende Aussage gefunden (natürlich wieder aus irgendeinem User-Forum), die mir recht plausibel erscheint:
OPAL (also known as TCG) is a standard for activating the SED's native encryption that is typically found on enterprise-focused products. The mechanism that activates hardware encryption by using the age-old HDD password entered in the BIOS Setup is called Class 0 encryption...
Das deckt sich ja zu 100% mit Deiner Aussage... und die Hinweise weiter unten zu Samsung Magician auch.
-edit- Samsung scheint diese Strategie (BIOS-HDD-Password setzt "Class 0" Encryption, was auch wieder ein Samsung-spezifischer Begriff zu sein scheint, und OPAL wird mit separater Software aktiviert) aktiv zu verfolgen:
Mit dieser Aussage bin ich noch nicht 100% grün, zumindest nicht ohne Zusätze. Das Setzen des HDD-Password führt nämlich oft/meist dazu, dass die Verschlüsselung "aktiviert" wird (im Hintergrund sieht's natürlich anders aus, aber für den Endbenutzer sieht das so aus). Siehe z.B. Samsung:
Du hast also aus meiner Sicht grundsätzlich schon recht, aber die SSD nimmt das Setzen des Passworts als Anlass, weitere Dinge zu tun...
-edit-Das Archwiki ist natürlich auch wieder aufschlussreich um ein Gefühl für die Gesamtsituation bezogen auf Linux zu bekommen - hier wird aber auch mehr oder minder SED = OPAL gleichgesetzt... https://wiki.archlinux.org/title/Self-encrypting_drives
Auch gibt es da noch kein Update zum Thema BIOS HDD-Password in Zeiten von OPAL:
Encryption Standard, ClassO SED) verwendet hardwarebasierte Controller und Verschlüsselungstechnologie, um Daten zu verschlüsseln und externen Zugriff zu verhindern, während gleichzeitig die Leistungsminderung minimiert wird.
- Wenn Sie im BIOS (Basic Input Output System, das grundlegende Eingabe-/Ausgabesystem mit den grundlegendsten Verarbeitungsfunktionen für den Computerbetrieb) ein HDD-Passwort verwenden, wird SED im Class O-Modus aktiviert und es ist keine Installation zusätzlicher Software erforderlich. Einige Systeme oder BIOS unterstützen diese Funktion möglicherweise nicht.
[So richten Sie die AES-Verschlüsselung ein]
- Im BIOS: Sicherheit > Startkennwort > HDD-Passwort (* Dies kann je nach BIOS leicht variieren.)
- Wenn Sie das Passwort vergessen haben, können Sie PSID Revert durchführen, um den Verschlüsselungsschlüssel zurückzusetzen. Dies führt jedoch zur Löschung
aller vorhandenen Daten.
Da steht, dass sich im Controller der SSD ein AES256-Chip befindet, dass für die Aktvierung des Chips ein HDD-Passwort benötigt wird und der Hash dieses Passworts vermutlich als Zufallsvariable für die Verschlüsselung verwendet wird.
Weiterhin steht da, dass ein Verschlüsselungsprogramm im Class 0-Modus darauf zugreifen kann, wenn es anstatt softwarebasierter eine hardwarebasierte Verschlüsselung benutzen soll. Das ist das gleiche, als ob ein Videodecoder oder Videoencoder auf einen H.264- oder H.265-Chip der Grafikkarte zugreift, um eine Hardwarecodierung anstatt einer Softwarecodierung von Videos vorzunehmen.
Das Verschlüsselungsprogramm muss also bereit sein, die Hardwarelösung anstatt der Softwarelösung zu verwenden. Im Übrigen verwendet 7-ZIP auch AES256 für die Verschlüsselung. Wer ernsthaft etwas zu verschlüsseln hat, kann auf einer Bitlocker-Partition auch noch verschiedene Ordner mit AES256 verschlüsseln, falls das für den Schutz der Privatsphäre erforderlich ist. Hardwareverschlüsselung auf privater Ebene ist nicht erwünscht.
Hardwareverschlüsselung auf dienstlicher Ebene ist..., ich sage mal ..., nachträglich "lizensiert" worden. Es geht darum, die Daten notfalls wiederherstellen zu können, egal wie und von wem sie verschlüsselt worden sind. In irgendeinem Tresor müssen also Unterlagen vorhanden sein, in denen steht, wie Vorgesetzte notfalls wieder an die verschlüsselten Daten kommen. Das gilt nicht nur für Festplatten, sondern z.B. auch für Server, Router oder Webcams, die Traffic-Statistiken oder den Inhalt verschlüsselt nach Hause senden können.
Da steht, dass sich im Controller der SSD ein AES256-Chip befindet, dass für die Aktvierung des Chips ein HDD-Passwort benötigt wird und der Hash dieses Passworts vermutlich als Zufallsvariable für die Verschlüsselung verwendet wird.
Weiterhin steht da, dass ein Verschlüsselungsprogramm im Class 0-Modus darauf zugreifen kann, wenn es anstatt softwarebasierter eine hardwarebasierte Verschlüsselung benutzen soll. Das ist das gleiche, als ob ein Videodecoder oder Videoencoder auf einen H.264- oder H.265-Chip der Grafikkarte zugreift, um eine Hardwarecodierung anstatt einer Softwarecodierung von Videos vorzunehmen.
@think_pad Ich befürchte Du wirfst da Einiges durcheinander. Es geht nicht um "irgendeine Software" die "im Class0 Modus auf die AES Verschlüsselung zugreift", sondern darum dass der Controller der SSD selbst sich um die Entschlüsselung kümmert - in diesem Fall im Zusammenhang mit dem vergebenen HDD-Password im BIOS.
Deine Interpretation der maschinellen Übersetzung ist teilweise auch einfach nicht korrekt, z.B. wird nicht "der AES256-Chip" durch setzen des Passworts aktiviert, sondern die SSD-eigene Hardwareverschlüsselung, die AES256 unter der Haube zur Verschlüsselung nutzt - ob über einen separaten Chip (sehr unwahrscheinlich) oder durch eine im Controller eingebaute HW Crypto-Einheit (wahrscheinlicher) oder eine weitere Lösung steht da überhaupt nicht.
Ich würde Dich in dem Zusammenhang darum bitten, Mutmaßungen besser als Solche zu kennzeichnen und nicht als Fakt darzustellen.
Das Verschlüsselungsprogramm muss also bereit sein, die Hardwarelösung anstatt der Softwarelösung zu verwenden. Im Übrigen verwendet 7-ZIP auch AES256 für die Verschlüsselung. Wer ernsthaft etwas zu verschlüsseln hat, kann auf einer Bitlocker-Partition auch noch verschiedene Ordner mit AES256 verschlüsseln, falls das für den Schutz der Privatsphäre erforderlich ist. Hardwareverschlüsselung auf privater Ebene ist nicht erwünscht.
Es geht auch nicht darum, was AES256 ist, oder dass andere Programme auch AES256 nutzen... das ist für die Fragestellung vollkommen irrelevant und ohnehin allen Teilnehmenden bekannt.
Hardwareverschlüsselung auf dienstlicher Ebene ist..., ich sage mal ..., nachträglich "lizensiert" worden. Es geht darum, die Daten notfalls wiederherstellen zu können, egal wie und von wem sie verschlüsselt worden sind. In irgendeinem Tresor müssen also Unterlagen vorhanden sein, in denen steht, wie Vorgesetzte notfalls wieder an die verschlüsselten Daten kommen. Das gilt nicht nur für Festplatten, sondern z.B. auch für Server, Router oder Webcams, die Traffic-Statistiken oder den Inhalt verschlüsselt nach Hause senden können.
Das ist ein berechtigter Einwand, in diesem Fall aber ziemlich irrelevant. Es gibt bei uns keine lokalen Datenspeicher mehr - der mögliche Datenverlust hält sich sehr in Grenzen. Für meine anderen privat genutzten Thinkpads auch irrelevant, da dank SyncThing nur extrem kurzzeitig unsynchronisierte Änderungen im Bereich User-Daten vorhanden sind.
Du siehst nur den technischen Aspekt und hast den größeren Zusammenhang nicht ganz verstanden: Hardwareverschlüsselung ist nachträglich ein so heißes Eisen geworden, dass Privatpersonen gar keinen Zugang mehr haben sollen. Hardwareverschlüsselung für sensible Daten im dienstlichen Bereich muss lizensiert werden. Man muss eine für Hardwareverschlüsselung lizensierte Firma beauftragen, diese einzurichten und zu überwachen. Deswegen werden die Versuche einer Controller-Hardwareverschlüsselung in früher frei erhältlichen Laufwerken absichtlich so schwammig behandelt, dass man sie als Privatperson nicht einsetzen können soll.
Diese Seite verwendet Cookies, um Inhalte zu personalisieren und dich nach der Registrierung angemeldet zu halten. Durch die Nutzung unserer Webseite erklärst du dich damit einverstanden.
