FileVault 2 (FDE) in Lion: Fragen & Gedanken

[mr.pink]

Für diejenigen unter euch, die sich mit FV2 schon genauer ausseinandergesetzt haben, sei es nun getestet oder eingelesen, hier ein paar meiner Fragen & Gedanken dazu.

1) Es macht rEFIt (derzeit) unnutzbar, obwohl es dafür aus technischer Sicht kein Erfordernis gibt. KA ob das Apples Absicht ist oder nicht, aber es macht es unnötig kompliziert bis unmöglich, andere Systeme via rEFIt zu booten - ka wie das mit Bootcamp aussieht.

2) Was soll es sicherheitstechnisch bringen, dass man es mit jedem Nutzerpasswort unlocken kann? "Mutti" wird wohl kaum ein ausreichend langes/sicheres Password nutzen.

3) Warum wird es überhaupt gegen Nutzerpasswörter gelockt bzw warum kann man kein Passwort nur für die Verschlüsselung anlegen? Derzeit nutz ich einen meiner Yubikeys dafür, aber den auch dauernd für Admin-Tätigkeiten anzustecken ist unpraktisch.

4) Sich zu merken, mit welchem Tastaturlayout das System gelockt wird, ist auch nicht gerade sinnvoll, schränkt es doch die möglichen Werte teils sehr ein, die man durchprobieren muss.

5) Warum kein Support für Keyfiles oder irgendeinen anderen Weg für 2-Factor-Auth?

6) Ich find's doch schon schade, dass man nur ja/nein für Crypto selektieren kann, nicht aber einstellen, wie genau man es gerne hätte. Auf meinem (Linux-)Desktop nutzt ich z.B. "nur" Blowfish für das System, dafür aber Serpent für die Nutzdaten. AES ist ja gut und schön, aber leider unterstützen die mit Abstand meisten in Macs verbauten Prozessoren kein AES-NI.

7) Leider gibt's mal wieder keine Sourcen dazu. Auch wenn Apple AFAIK externe Sicherheitsdienstleister eingeladen hat, den Code zu auditen, sind diese AFAIK per NDA gebunden. Sinnvoll für den Endnutzer ist das nun nicht gerade.

Alles in allem bin ich doch ein wenig enttäuscht, sicherlich ist es auch für Laien einfach nutzbar, wie sicher es dann aber ist, sei mal dahin gestellt - und jetzt bitte nicht wieder mit Sachen ala "hast du Angst vor der CIA" kommen. Auf anderen Systemen, egal ob Win32 oder Linux/Unix hat man dank TrueCrypt, GELI oder dm-crypt/LUKS imho wesentlich mehr Flexibilität und das find ich doch schon schade

 

[ImperatoR]

Also Truecrypt gibt es auch für Mac OS X, es hält dich also nichts davon ab dieses zu nutzen.

1: Das ist sehr ärgerlich, da hast du recht. Aber ich denke die rEFIt-Entwickler werden dort nachlegen?

2: Das ist wohl weniger von sicherheitskritischer Relevanz, sondern eher, dass auch alle Nutzer Zugriff weiterhin auf den Mac haben. Schließlich ist nun die gesamte Festplatte verschlüsselt. Entweder muss Mutti ein sicheres Passwort wählen oder einen eigenen Rechner haben.

3: Siehe 2. Wozu benutzt du diesen Yubikey? Hört sich ganz interessant an, kannst du das bitte für mich noch etwas ausführen?

4: Das ist mir bisher nicht aufgefallen, da ich momentan nur das US-Layout benutze, aber könnte in der Tat ärgerlich werden. Zumal man ja nur im Loginscreen die Tastatur wählen lassen müsste. (Kann aber wohl leicht nachgebessert werden, schreib am besten mal ein Ticket bei Apple)

5: Das wäre echt eine tolle Sache!

6: Das war schon so auch bei FV1, immer nur AES-128. Aber so lange dieser als sicher gilt, braucht man eigentlich auch nichts stärkeres? Wenn ja kann ein Patch (hoffenltich) schnell nachgeliefert werden oder falls AES knackbar werden sollte auf Alternativen umsteigen. Sehe ich aber keinen Grund zu (noch nicht). Und das kann jeden anderen Algorithmus auch passieren, also ist man mit XYZ-4096 auch nicht unbedingt sicherer.

7: Ja, das gehört eigentlich zu einem guten Verschlüsselungssystem, dass es Quell offen ist. Wirklich schade.

Ich finde es alles in allem gut (von mir verfasst) gelöst.

 

[mr.pink]

Also Truecrypt gibt es auch für Mac OS X, es hält dich also nichts davon ab dieses zu nutzen.

Soweit ich nicht was verpasst habe, ist damit aber noch kein FDE möglich und somit sinnfrei, ausser man kombiniert es mit Checksumming-Techniken o.ä.

1: Das ist sehr ärgerlich, da hast du recht. Aber ich denke die rEFIt-Entwickler werden dort nachlegen?

Ich steck da nicht im Team und hab mir den Code nur kurz angeschaut, aber von dem was ich sah und hörte, könnte das aufwending werden, womit sich die Frage des Willens stellt, denn wahrscheinlich wird auch in Zukunft nur ein Bruchteil der User FDE betreiben.

2: Das ist wohl weniger von sicherheitskritischer Relevanz, sondern eher, dass auch alle Nutzer Zugriff weiterhin auf den Mac haben. Schließlich ist nun die gesamte Festplatte verschlüsselt. Entweder muss Mutti ein sicheres Passwort wählen oder einen eigenen Rechner haben.

Mh, kann man so sehen. Wenn man Apple böses unterstellen wollen würde, könnte man natürlich auch einen gut versteckten User mit einem simplen Passwort anlegen. Jedenfalls seh ich das nicht als saubere Lösung an.

3: Siehe 2. Wozu benutzt du diesen Yubikey? Hört sich ganz interessant an, kannst du das bitte für mich noch etwas ausführen?

http://yubico.com/
Darauf hab ich ein langes statisches Passwort, sowie einen Slot mit OTP. Unter Linux hab ich PAM so eingerichtet, dass OTP+Passwort genutzt wird, unter OS X hab ich dafür bis jetzt noch keinen ordentlichen Weg gefunden. Kurzfassung für OSX, mit einem Tastendruck wird ein langes&sicheres PWD abgesetzt, das nutzt ich derzeit für FileVault. Gut, kommt der Stick weg, ist's natürlich genauso Essig mit der Sicherheit, wie wenn ich das Passwort vergesse - daher die Suche nach der ordentlich 2-Factor-Auth. Für den normalen Login gibt's nebenbei erwähnt z.B. Rohos Login Key (kostet bisschen was), das unterstützt dann auch OTP.

5: Das wäre echt eine tolle Sache!

Imho ist das Pflicht

6: Das war schon so auch bei FV1, immer nur AES-128. Aber so lange dieser als sicher gilt, braucht man eigentlich auch nichts stärkeres? Wenn ja kann ein Patch (hoffenltich) schnell nachgeliefert werden oder falls AES knackbar werden sollte auf Alternativen umsteigen. Sehe ich aber keinen Grund zu (noch nicht). Und das kann jeden anderen Algorithmus auch passieren, also ist man mit XYZ-4096 auch nicht unbedingt sicherer.

Natürlich kann das jedem anderen Cipher auch passieren, das Hauptproblem ist halt, dass Rindjael für AES genutzt wird, weil es ein relativ guter Kompromiss zwischen Sicherheit und Geschwindigkeit ist. Serpent ist z.B. bei weitem sicherer, wenn auch wesentlich anspruchsvoller. Wäre halt schön, sich was aussuchen zu können, dann ist nicht gleich potentiell jeder dran, wenn's eine effektive Attacke gibt. Immerhin wird XTS genutzt - gut, es wird behauptet, überprüfen kann man das kaum; ich erinnere in dem Zusammenhang gerne an die angeblich mit AES verschlüsselnden externen Festplatten, die bei genauerem hinsehen einfach nur XOR machen.

Was mich auch interessieren würde, werden nur die Nutzdaten verschlüsselt oder wird vorher das gesammte Dateisystem - ergo auch die unbeschriebenen Parts - gescrambelt? Bekanntlich ist es schwieriger, aus abcXYZcba Daten auszulesen bzw. zu sehen was sinnvoll ist, als aus 000XYZ000. Alles leider Sachen, die man nicht erfährt und wenn's einer erfährt, darf er/sie's nicht sagen

Ich finde es alles in allem gut (von mir verfasst) gelöst.

Netter Artikel bzw. eher howto, beantwortet aber halt keine kritischen Fragen.

 

[smoe]

Die einfache Antwort dürfte wohl in fast allen Fällen lauten: Weil es so benutzerfreundlich für den Durchschnittsuser ist.

 

[mr.pink]

Ja, nur leider: Sicherheit = Nutzerfreundlichkeit ** -1

Im Zweifel ist halt gerade der wieder in den A.... gekniffen, der sich mangels Sachverständnis drauf verlässt. Wäre der Gag bei der Sache nicht, dass sich diese Leute im Nachhinein immer beschweren, weil sie sich vorher selbst nicht drum kümmern wollten, wäre ja alles in Ordnung, aber so ist das halt mal wieder nur Snake-Oil.

 

[ImperatoR]

Also Apple hat es ja jetzt ganz nutzerfreundlich und auch ausreichend sicher hinbekommen. Wer mehr will, kann die richtig heiklen Daten nochmals in einen Container mit schieß-mich-tot-Algos packen.

Und eine Datenbank aller Nutzerdaten deiner Firma wirst du ja wohl kaum auf einem Laptop herumschleppen. Falls ja, sind diese Daten wieder so überschaubar, dass sie in einen speziellen und separierten Container gehören. Oder wieso weshalb warum?

Und wieso ist dir AES zu unsicher? Wenn das Passwort sicher genug ist, sollte man an AES nicht vorbeikommen.

Yubico sieht interessant aus, damit werde ich mich mal näher beschäftigen.

 

[mr.pink]

Und wieso ist dir AES zu unsicher? Wenn das Passwort sicher genug ist, sollte man an AES nicht vorbeikommen.

Ich kann mich nicht erinnern, das so gesagt zu haben, aber:

a) Rindjael ist ja erstmal nur ein Algo, das Problem ist viel mehr, woher soll man/ich wissen, dass der auch sauber implementiert wurde? Das kann ja keiner - ausser Apple - prüfen. Es könnte eine Backdoor drin sein, die Coder können einfach Mist gemacht haben, etc. pp.

b) Passwort alleine hilft nicht so umfassend, da muss auch ordentlich gesalted werden.

c) Nicht überall wo AES drauf steht, ist es auch drin. Again, dass zu überprüfen ist nicht trivial.

d) rein wissenschaftlich/mathematisch ist AES halt ziemlich schnell, dafür aber "nur" relativ sicher - im Vergleich zu anderen Kandidaten.

AES ist ziemlich weit verbreitet, die Frage ist, welche Konsequenzen man für sich persönlich daraus zieht. Schließlich wird das Ding nicht nur am häufigsten eingesetzt, sondern auch versucht zu brechen - mathematisch, nicht unbedingt via BF. Wenn man sich anschaut, was in den letzten Monaten und Jahren durch GPU-Computing in dem Bereich erreicht wurde und das mit bekannten Attacken kombiniert, dürfte es nicht mehr allzu ewig dauern, bis es mit viel aber für manche vertretbarem Aufwand gebrochen werden kann.

Zugegeben, für den Privatmensch ist das erstmal relativ uninteressant, aber wenn man sich anschaut, was alles an AES so dran hängt - z.B. SSL-Certs - gibt's durchaus interessante Möglichkeiten.

Ja, vielleicht bin ich zu paranoid, aber ein bisschen diversity für extra Komplexität hat selten geschadet.

 

[ImperatoR]

Zu a: Das kann man in der Tat (leider) nicht nachprüfen. Ich weiß auch nicht was das Seitens Apple soll, auf dem Code zu sitzen.

 

[wdominik]

Ich denke bei Sicherheitslösungen gibt es keine Ideal-Lösung. FileVault ist da eher nach wie vor eine Lösung die viel mehr einen neugierigen MacBook Dieb / Finder vom Schnüffeln abhalten soll als entsprechende Organisationen / Behörden mit massig Ressourcen denen Deine Daten so wichtig sind, dass sie jede erdenkliche Bemühung in die Wege leiten Zugriff drauf zu erhalten. (Was nicht unterstellen soll, dass jemand der seine Privatsphäre durch eine Verschlüsselung schützt gleich irgendwas illegales betreibt.)

FileVault bietet meiner Meinung nach für den Durchschnitts-User einen ausreichenden Schutz und das mit einer beachtlichen Transparenz. Ein paar Fortgeschrittene Optionen, wie z. B. Nutzung von Keyfiles + Passwort hätte ich allerdings ebenfalls begrüßt.

2) Bei der Situation frage ich mich allerdings, wie Mutti es finden würde vor ihrer Anmeldung noch fix den 64-Zeichen-Schlüssel für die Verschlüsselung einzugeben. Der stünde dann vermutlich schneller auf einem Post-It am Bildschirm als Du denkst. Von daher ist Single-Sign-On für Familien-Rechner nicht so übermäßig verkehrt – wenn Dir Deine Daten so wichtig sind, teilst Du doch ohnehin den Zugang nicht mit anderen.

4) Das ist auch so eine Sache. Da die Verschlüsselung auf EFI Basis läuft braucht der Angreifer ohnehin physischen Zugang zu deinem Mac. Somit sieht er auch welche Tastatur verwendet wird. Jedes mal bei der Anmeldung fix das indische Keyboard aus dem Keller zu holen halte ich etwas für extrem.

Das ein dm-crypt/LUKS um einiges flexibler ist kann ich bestätigen. Ist halt eben das andere Extrem, bei welchen Du von Verschlüsslungsalgorithmen im Kernel bis Authentifizierung im initramfs alles selbst definieren kann. Natürlich auch nur mit den entsprechenden Wissen und Aufwand.

Was mich an FV2 wesentlich mehr stört, ist die Tatsache, dass sich nur die Bootfestplatte mit verschlüsseln lässt. Da diese bei mir nur für Programme genutzt wird (SSD) ist das recht sinnfrei, wenn dann die Daten auf den anderen 3 Platten unverschlüsselt rumlägen. Eine Lösung über Container ist zwar möglich, aber schön wäre es, wenn das ähnlich transparent wie bei der Bootfestplatte abliefe.

 

[ImperatoR]

Wieso, du kannst doch alle Dateisysteme verschlüsseln…

 

[wdominik]

Und wie, wenn ich mal blöd fragen darf?

 

[ImperatoR]

Mit dem Festplattendienstprogramm, jedoch musst du halt die Festplatte vorher löschen und das Backup wiederherstellen. Vielleicht gibt es via Terminal ein eleganteren Weg, habe ich leider noch nichts gefunden.

 

[wdominik]

Tatsächlich, die Option hab ich echt voll übersehen. Vielen Dank, kann ich den Kritikpunkt wieder revidieren.

 

[mr.pink]

2) Bei der Situation frage ich mich allerdings, wie Mutti es finden würde vor ihrer Anmeldung noch fix den 64-Zeichen-Schlüssel für die Verschlüsselung einzugeben.

Deswegen bin ich ja für 2-/Multifactor-Authing. Ob das jetzt ein Ding ala Yubikey, ein RSA-Token oder nur ein USB-Stick mit ner Datei drauf ist, ist imho relativ irrelevant. Gut, mich betrifft das nicht, an meine Rechner kommt keiner dran und meine Frau hat ihren eigenen.

4) Das ist auch so eine Sache. Da die Verschlüsselung auf EFI Basis läuft braucht der Angreifer ohnehin physischen Zugang zu deinem Mac. Somit sieht er auch welche Tastatur verwendet wird. Jedes mal bei der Anmeldung fix das indische Keyboard aus dem Keller zu holen halte ich etwas für extrem.

Die Hardware der Tastatur hat doch nichts mit dem Layout zu tun - ausser man kann sich sein Passwort nicht merken. In der Theorie würde einen ja nichts davon abhalten, z.B. chinesische Zeichen für das PWD zu nutzen - vorrausgesetzt die Umsetzung ist UTF-8/-16 fähig. Wenn man folglich bei jedem Start kurz das Layout wählen könnte/müßte, wäre das nicht schlecht und so viel Aufwand ist es ja nicht. Nebenbei gefragt, verschlüsselt FV denn immerhin, wenn das System in den Standby geht bzw. Bildschirmschoner geht an o.ä.? Wenn nicht, müßte man das Ding ja nur im angeschalteten Zustand klauen, gab ja schon genug Exploits(z.B. via Firewire), da ließe sich schon was machen.

EFI-basiert ist ja auch wieder ein Problem an sich, die Platte ist ja also nicht voll verschlüsselt, d.h. jemand könnte mit dem - ich nenn's mal - Crypto-Loader "spielen" und z.B. das Passwort mitloggen. Deshalb wird ja z.B. u.a. in allen LUKS-Guides empfohlen, von einem externen Medium zu booten - idealerweise natürlich auch noch von einem ROM.

Edit, wieso physischer Zugang? Vorrausgesetzt man fängt sich irgendwie eine Malware ein, die mit root-Rechten läuft, ist es doch ein leichtes, einen Dump der EFI-Partition - bzw der wichtigen darauf befindlichen Daten - übers Netzwerk zu schieben bzw diese Daten via Netzwerk zu modifizieren. Wie man an Jailbreakme.com sieht, braucht's da nichtmal User-Interaction für, bisschen gutes Social Engineering und das war's dann.

 

[wdominik]

Naja aber sagen wir mal jemand bekommt über Malware o. Ä. Zugang, dann läuft dein Computer ja ohnehin schon, d. H. die verschlüsselte Partition ist ohnehin gemounted. Wenn das der Fall ist, ist es allemal zu spät. Das trifft aber auf alle FDE Lösungen zu. Ob Dir der Angreifer dann gleich die Daten klaut oder Dir ein modifiziertes EFI Image unterschiebt dürfte dann jedenfalls von der geringeren Bedeutung sein.

Keyboard-Layout-mäßig hast Du wiederum recht, mit komplettem UTF-16 zu bruteforcen ist mit Sicherheit rechen-aufwändiger als nur die auf dem eigenen Keyboard-Layout vorhandene Tasten. Aber eine Auswahl bei jeder Anmeldung wäre dennoch etwas störend imho. Dann lieber ein zusätzliches Keyfile.

 

[Rastafari]

Die Hardware der Tastatur hat doch nichts mit dem Layout zu tun

Doch, hat sie. Nur europäische ISO-, US- und japanische Keyboards verwenden das grundsätzlich gleiche Keycode-layout.

In der Theorie würde einen ja nichts davon abhalten, z.B. chinesische Zeichen für das PWD zu nutzen - vorrausgesetzt die Umsetzung ist UTF-8/-16 fähig.

EFI kann zwar grundsätzlich Unicode, aber nur die Tafeln bis 0xFFFF.
Es gibt also Grenzen, ein Kennwort aus Mahjongg-Steinen geht nicht.

Wenn man folglich bei jedem Start kurz das Layout wählen könnte/müßte, wäre das nicht schlecht und so viel Aufwand ist es ja nicht.

ROFLMAO
"Nicht viel Aufwand" - zum wegschmeissen naiv...

verschlüsselt FV denn immerhin, wenn das System in den Standby geht bzw. Bildschirmschoner geht an o.ä.?

Ääääh. Was soll es denn da "besonderes" zu verschlüsseln geben?

EFI-basiert ist ja auch wieder ein Problem an sich, die Platte ist ja also nicht voll verschlüsselt, d.h. jemand könnte mit dem - ich nenn's mal - Crypto-Loader "spielen" und z.B. das Passwort mitloggen. Deshalb wird ja z.B. u.a. in allen LUKS-Guides empfohlen, von einem externen Medium zu booten - idealerweise natürlich auch noch von einem ROM.

Nett, aber nutzlos. Sitzt der Keylogger zB in deiner Netzwerkkarte, interessiert es den Schadcode kein Stück mehr, von welchem Medium du bootest (nachdem der Logger längst aktiv ist).

Vorrausgesetzt man fängt sich irgendwie eine Malware ein, die mit root-Rechten läuft, ist es doch ein leichtes, einen Dump der EFI-Partition - bzw der wichtigen darauf befindlichen Daten - übers Netzwerk zu schieben bzw diese Daten via Netzwerk zu modifizieren.

Im Gegensatz zu bisherigen (BIOS/MBR-gestützten) FDE-Modellen lässt sich in EFI durchaus was dagegen zun (wobei ich noch nicht zu sagen weiss, ob das tatsächlich geschieht).

 

[mr.pink]

EFI kann zwar grundsätzlich Unicode, aber nur die Tafeln bis 0xFFFF.

Mh, danke für die Info.

ROFLMAO
"Nicht viel Aufwand" - zum wegschmeissen naiv...

Missverstehen wir uns hier, oder wär's dir wirklich zuviel, beim booten 2 Klicks zu machen?

Ääääh. Was soll es denn da "besonderes" zu verschlüsseln geben?

Gut, verschlüsseln war hier falsch ausgedrückt. Die Spuren des Keys im RAM zu tilgen meinte ich und gleichzeitig halt das Volume zu locken. Gab ja schon einige Exploits, die trotz aktivem Screensaver die Daten abgezogen haben. IIRC scramblet z.B. TrueCrypt in der Situation, wie das bei LUKS und GELI ist, müßte ich mal schauen.

Nett, aber nutzlos. Sitzt der Keylogger zB in deiner Netzwerkkarte, interessiert es den Schadcode kein Stück mehr, von welchem Medium du bootest (nachdem der Logger längst aktiv ist).

Natürlich, dagegen würde nur OpenHardware helfen, aber davon gibt's leider noch nicht so viel.

Im Gegensatz zu bisherigen (BIOS/MBR-gestützten) FDE-Modellen lässt sich in EFI durchaus was dagegen zun (wobei ich noch nicht zu sagen weiss, ob das tatsächlich geschieht).

Mehr Infos bitte.

 

[Rastafari]

wär's dir wirklich zuviel, beim booten 2 Klicks zu machen?

Natürlich nicht.
Es sei denn du erwartest, dass beim "irgendwohin" klicken auch tatsächlich "irgendwas" passiert.
Wofür hältst du EFI? Für ein komplettes Betriebssystem? Hast du eine auch nur ungefähre Vorstellung von dem Softwarebaum den du brauchst, um vollen Unicode-Support inklusive Eingabemethoden etc auf die Beine zu stellen?

Die Spuren des Keys im RAM zu tilgen meinte ich und gleichzeitig halt das Volume zu locken.

Der "Key" wird nur kurz während des mountens benötigt. Danach ist er obsolet, denn die Folgeschlüssel ergeben sich aus dem gemounteten Volume selbst. Und solange ein Volume gemountet bleibt, kannst du es nicht "locken".

Gab ja schon einige Exploits, die trotz aktivem Screensaver die Daten abgezogen haben.

Ich weiss ja nicht, wovon du sprichst...
Dass ein Screensaver lediglich den Bildschirm verdeckt und die Eingabegeräte blockiert, und sonst überhaupt nichts, das ist dir schon klar, oder?

IIRC scramblet z.B. TrueCrypt in der Situation

So "broken by design" ist nicht mal TrollCrypt.

Mehr Infos bitte.

Im Gegensatz zu landläufigen Binsenweisheiten ist es sehr wohl möglich, jedweden EFI Code digital zu signieren. Und dabei nicht nur den Prüfcode, sondern (hopperla!) auch die Signatur in den signierten Code, also rekursiv in sich selbst einzubetten. Fälsch das mal, viel Spass dabei.

 

[mr.pink]

Natürlich nicht.
Es sei denn du erwartest, dass beim "irgendwohin" klicken auch tatsächlich "irgendwas" passiert.
Wofür hältst du EFI? Für ein komplettes Betriebssystem? Hast du eine auch nur ungefähre Vorstellung von dem Softwarebaum den du brauchst, um vollen Unicode-Support inklusive Eingabemethoden etc auf die Beine zu stellen?

Na, dann klär mich doch mal auf, wie dann der aktuelle Chooser umgesetzt ist.

Und solange ein Volume gemountet bleibt, kannst du es nicht "locken".

Darauf will ich doch hinaus, wenn man nur einen S2RAM macht, braucht man ja nur den aktuellen Status, könnte das/die Volume(n) aushängen und erst bei korrekter Authentifizierung wird's wieder eingehängt.

Ich weiss ja nicht, wovon du sprichst...

Und ich glaub du verstehst nicht, worauf ich hinaus will.

Dass ein Screensaver lediglich den Bildschirm verdeckt und die Eingabegeräte blockiert, und sonst überhaupt nichts, das ist dir schon klar, oder?

Ich will ja eben darauf hinaus, dass es für unbedarfte so aussehen mag, dass ein Screensaver ein Schutzzustand ist, was halt nicht den Fakten entspricht - genauso gibt es ja auch Leute aus der Windows-Welt, die ernsthaft der Meinung sind, Anti-Viren-Software hätte irgendeine Funktion abseits einer fehlerträchtigen Diagnose.

Im Gegensatz zu landläufigen Binsenweisheiten ist es sehr wohl möglich, jedweden EFI Code digital zu signieren. Und dabei nicht nur den Prüfcode, sondern (hopperla!) auch die Signatur in den signierten Code, also rekursiv in sich selbst einzubetten. Fälsch das mal, viel Spass dabei.

Entweder reden wir hier anneinander vorbei, oder ich versteh's einfach nicht. Warum sollte sich jemand die Mühe machen, irgendwelche Checksums zu forgen, wenn man doch auch "einfach" das ganze System ersetzen kann? Soweit mir bekannt ist, findet sich in Macs kein Hardware-Modul (TPM o.ä.), was die Konsistenz der EFI-Partition checkt.

 

[Rastafari]

Na, dann klär mich doch mal auf, wie dann der aktuelle Chooser umgesetzt ist.

Wenn du uns wissen lässt, was dieser "Chooser" genau sein soll?

könnte das/die Volume(n) aushängen

Du kannst kein Volumen aushängen ohne alle Dateien darauf zu schliessen.

Soweit mir bekannt ist, findet sich in Macs kein Hardware-Modul (TPM o.ä.), was die Konsistenz der EFI-Partition checkt.

Das ist auch nicht nötig. Der Lader kann sich durchaus selbst auf Integrität prüfen, und seine Ablaufumgebung auch.
Ein Check der ESP wäre auch reichlich sinnfrei, denn davon kann man beliebig viele haben, auf beliebigen Datenträgern, auch auf externen.