Foren

Big Sur wird nicht auf verschlüsselten Laufwerken installiert, warum?

ZombiePhysiker

Originalplakat
22. Mai 2014
  • 31.01.2021
Seit vielen Jahren formatiere ich meine System-/Boot-Festplatte als verschlüsseltes Laufwerk. Zuerst als HFS+ Encrypted und in den letzten Jahren als APFS Encrypted. Alles hat gut durch Catalina geklappt.

Wenn Sie jedoch jetzt zuerst ein Laufwerk als APFS-verschlüsselt formatieren und versuchen, Big Sur (neueste 11.1 und frühere 11.01) auf diesem Laufwerk zu verwenden, erhalten Sie die folgende Fehlermeldung:

'Sie können nicht auf diesem Volume installieren, da es ein Festplattenkennwort hat.'

Wenn Sie jedoch auf einem nicht verschlüsselten Laufwerk installieren, können Sie später FileVault auswählen und der gesamte Container wird gemäß diesem Thread verschlüsselt: https://discussions.apple.com/thread/252036326

Dies bedeutet jedoch, dass jeder einfach den FileVault-Schalter umlegen und die Verschlüsselung auf dem Laufwerk rückgängig machen kann. Dies ist schlecht, wenn Sie nicht möchten, dass das Laufwerk zu irgendeinem Zeitpunkt unverschlüsselt ist.

Die Frage ist WARUM!? Warum dieses Verhalten. Die aktuelle Problemumgehung besteht darin, Catalina auf einem APFS-verschlüsselten Laufwerk zu installieren und dann ein Upgrade auf diesem Laufwerk durchzuführen. Big Sur wird und funktioniert gut, aber warum erfordert die verrückte Arbeit herum?

Würde mich über Gedanken / Spekulationen freuen, ob dies ein Fehler oder ein Feature ist und wenn es ein Feature ist, WARUM!?

Robotik

10. Juli 2007


Edinburgh
  • 31.01.2021
Möglicherweise hat sich das Verschlüsselungsprotokoll geändert? Möglicherweise möchten Sie die aktualisierte Verschlüsselung verwenden.

svanstrom

zu
8. Februar 2002
🇸🇪
  • 31.01.2021
Ok, eine kurze Suche scheint mir zu sagen, dass Änderungen an CoreStorage vorgenommen wurden…

www.bitdefender.com

Auswirkungen von macOS Big Sur (11.0) auf die Volumenverschlüsselung in Endpoint Security für Mac

Unterstützung www.bitdefender.com www.bitdefender.com

Bekannte Probleme mit macOS Big Sur | Carbon Copy Cloner | Bombich-Software

bombich.com

ZombiePhysiker

Originalplakat
22. Mai 2014
  • 31.01.2021
robotica sagte: Vielleicht hat sich das Verschlüsselungsprotokoll geändert? Möglicherweise möchten Sie die aktualisierte Verschlüsselung verwenden.

Ich habe sowohl die ältere APFS-Formatierung verwendet als auch frisch formatierte Laufwerke mit 11.1 ausprobiert. Also verwende ich eine eigene Verschlüsselung.

Ihre Vermutung ist jedoch gut, da sich zwischen der Verschlüsselung des Laufwerks auf 11.01 und 11.1 in Bezug auf die Art und Weise, wie Big Sur Time Machine-Backups durchführt, etwas tiefgreifendes geändert hat. Siehe diesen Thread: https://forums.macrumors.com/threads/best-way-to-format-time-machine-drive.2280154/

Es war ein Leistungsunterschied bei Tag und Nacht, nachdem wir in 11.1 auf APFS neu formatiert und die Zeitmaschine erneut ausgeführt haben.

Wie auch immer, hier, selbst wenn ich mit 11.1 neu formatiere, kann ich das Betriebssystem immer noch nicht installieren.
Reaktionen:Robotik

ZombiePhysiker

Originalplakat
22. Mai 2014
  • 31.01.2021
svanstrom sagte: Okay, eine kurze Suche scheint mir zu sagen, dass Änderungen an CoreStorage vorgenommen wurden…

www.bitdefender.com

Auswirkungen von macOS Big Sur (11.0) auf die Volumenverschlüsselung in Endpoint Security für Mac

Unterstützung www.bitdefender.com www.bitdefender.com

Bekannte Probleme mit macOS Big Sur | Carbon Copy Cloner | Bombich-Software

bombich.com

Ja, ich habe keinen Zweifel, dass sich viele Dinge geändert haben, aber es funktioniert immer noch, wenn Sie ein vollständiges APFS-verschlüsseltes Laufwerksformat verwenden, Catalina installieren und dann das Big Sur-Upgrade durchführen. Obwohl es einen Unterschied ohne Unterschied sein kann, frage ich mich, ob es keine 'Konvertierung' gegeben hat.

Das heißt, ich sehe, dass mein FileVault eingeschaltet ist und mein Laufwerkscontainer auf dem Laufwerk im Festplatten-Dienstprogramm.app als APFS-verschlüsselt angezeigt wird jetzt? Das Sicherheitsfenster zeigt jedoch einen Wiederherstellungsschlüssel an ... Ich weiß nicht, ob nur Ihr Vanilla-FileVault-Schalter einen Wiederherstellungsschlüssel einstellt? Zuletzt bearbeitet: 31.01.2021 C

Chilip

19.02.2021
  • 19.02.2021
Dieses Problem ist wirklich ärgerlich.

Für mich scheint es durch die neue Apple-Richtlinie verursacht zu werden: 'Verschlüsseln Sie den Systemcontainer nicht, da er schreibgeschützt gemountet ist und die gleichen Daten für alle Macs da draußen enthält'. Vielleicht glaubt Apple, dass es auch eine Verbesserung der Energie- und Gesamtleistung sein könnte, da keine Verschlüsselung zu einem geringeren Stromverbrauch und 'Leistungsverbrauch' führt.

Ich weiß es nicht, aber lassen Sie es mich wissen, wenn Sie eine Lösung für die Installation von Big Sur auf einem frischen und bereits verschlüsselten APFS-Volume finden.
Reaktionen:ZombiePhysiker

ZombiePhysiker

Originalplakat
22. Mai 2014
  • 20. Februar 2021
Es ist seltsamer, weil ich mir ziemlich sicher bin, dass Big Sur IMMER ALLE CONTAINER VERSCHLÜSSELT, nur wird es einen öffentlichen Schlüssel für Container haben, für die keine 'Verschlüsselung' aktiviert ist.

Warum vermute ich das. Weil ich Big Sur gerade frisch auf einem unverschlüsselten APFS-Laufwerk installiert habe. Speichern Sie über 10 TB Daten in einem Konto. DANN wurde der Dateitresor aktiviert und das Ganze war in weniger als einer Minute 'verschlüsselt', und jetzt wird der Container als APFS-verschlüsselter Container angezeigt. KEINE MÖGLICHKEIT, dass es so schnell so viele Daten verarbeitet hat, so dass diese Dinge immer von Anfang an verschlüsselt sind. Wenn dem so ist, warum lassen Sie mich nicht trotzdem das gesamte Laufwerk sperren, denn das Argument über Leistung / Verbrauch der Verschlüsselung entfällt, wenn im Wesentlichen sowieso immer alles verschlüsselt ist.

Für mich bedeutet dies wirklich, dass das gesamte Laufwerk IMMER verschlüsselt war und ich jetzt einen Schlüssel dafür setze. Aber das macht mir große Sorgen. Bedeutet das, dass Filevault mit 2 Schlüsseln arbeitet? Und mit dem OS leicht in der Lage, den Zugang per Passwort zu ändern. Wie wurde das bisher verschlüsselt? Ich könnte die Dinge missverstehen, aber dies lässt das Gespenst eines universellen Entsperr-/Hintertürschlüssels aufkommen.
Reaktionen:Chilip D

Daverich4

13.01.2020
  • 20. Februar 2021
ZombiePhysicist sagte: Dies bedeutet jedoch, dass jeder einfach den FileVault-Schalter umlegen und die Verschlüsselung auf dem Laufwerk rückgängig machen kann. Dies ist schlecht, wenn Sie nicht möchten, dass das Laufwerk zu irgendeinem Zeitpunkt unverschlüsselt ist.
Sie benötigen den Administratornamen und das Kennwort, um FileVault zu deaktivieren. Wie unterscheidet sich das von jeder anderen Form der Verschlüsselung?

Quacksalber

18.09.2013
Manchester, Großbritannien
  • 20. Februar 2021
Ich habe FileVault nicht aktiviert und im Terminal ausgeführt
diskutil apfs list
und die Ausgabe zeigt jedoch keine Verschlüsselung für alle Volumes
sowohl für Macintosh HD als auch für Macintosh HD - Datenvolumen wird angezeigt als
verschlüsselt - Nein (im Ruhezustand verschlüsselt) C

Chilip

19.02.2021
  • 21.02.2021
Daverich4 sagte: Sie benötigen den Administratornamen und das Passwort, um FileVault zu deaktivieren. Wie unterscheidet sich das von jeder anderen Form der Verschlüsselung?
Der Unterschied besteht darin, dass sich in meinem Fall mein Festplattenverschlüsselungskennwort immer von meinem Benutzerkontokennwort unterscheidet und ich es aus Sicherheitsgründen nicht mit dem Schlüsselbund speichere/verknüpfe.

ZombiePhysicist sagte: Ich könnte die Dinge missverstehen, aber das bringt das Gespenst eines universellen Entsperr-/Hintertürschlüssels irgendeiner Art auf.

Ich stimme Ihnen voll und ganz zu - ich mag auch nicht die Tatsache, dass wir nur eine Art 'Wiederherstellungsschlüssel' erhalten, der vielleicht nicht der tatsächlich verwendete Verschlüsselungsschlüssel ist - daher habe ich keine Ahnung, welcher Schlüssel (oder Schlüsselabweichung-zufällig) ist -algorithm) wird zur Verschlüsselung verwendet. J

jcscol

26.09.2018
  • 21.02.2021
ZombiePhysicist sagte: Ich habe Big Sur gerade frisch auf einem unverschlüsselten APFS-Laufwerk installiert. Speichern Sie über 10 TB Daten in einem Konto. DANN wurde der Dateitresor aktiviert und das Ganze war in weniger als einer Minute 'verschlüsselt', und jetzt wird der Container als APFS-verschlüsselter Container angezeigt. KEINE MÖGLICHKEIT, dass es so viele Daten so schnell verarbeitet hat
Dies war nicht meine Erfahrung beim Einschalten von Filevault in Big Sur bei meiner ursprünglichen Installation oder bei bootfähigen CCC-Klonen. Sie durchlaufen den Verschlüsselungsprozess, wobei ein 300-GB-Laufwerk auf meinem MacBook über eine Stunde dauert.

Für mich bedeutet dies wirklich, dass das gesamte Laufwerk IMMER verschlüsselt war und ich jetzt einen Schlüssel dafür setze.
Ich habe keine Anzeichen dafür gesehen, dass dies hier der Fall ist

aber dies bringt das Gespenst eines universellen Entsperr-/Hintertürschlüssels irgendeiner Art auf.
Nur wenn deine Annahme richtig ist, was ich nicht glaube. D

Daverich4

13.01.2020
  • 21.02.2021
Chilipp sagte: Der Unterschied besteht darin, dass sich in meinem Fall mein Festplattenverschlüsselungskennwort immer von meinem Benutzerkontokennwort unterscheidet und ich es aus Sicherheitsgründen nicht mit dem Schlüsselbund speichere/verknüpfe.
Ich glaube, ich verstehe hier etwas nicht. In der Diskussion ging es um das Deaktivieren von FileVault, was den Zugriff auf einen entsperrten Computer erfordert. An diesem Punkt ist der Zugriff auf das verschlüsselte Laufwerk transparent, es ist kein Passwort erforderlich. Redest du von etwas anderem? C

Chilip

19.02.2021
  • 21.02.2021
Daverich4 sagte: Ich glaube, ich verstehe hier etwas nicht. In der Diskussion ging es um das Deaktivieren von FileVault, was den Zugriff auf einen entsperrten Computer erfordert. An diesem Punkt ist der Zugriff auf das verschlüsselte Laufwerk transparent, es ist kein Passwort erforderlich. Redest du von etwas anderem?

Meines Erachtens geht es um die Unfähigkeit, Big Sur auf einem zuvor / im Voraus verschlüsselten Volume zu installieren.

Und auch wenn jemand den Dateitresor nur für einen bereits entsperrten Computer deaktivieren darf, macht es sicherlich einen Unterschied, ob es überhaupt möglich ist, ihn zu deaktivieren oder nicht.

Wenn jemand zum Beispiel das Passwort meines Accounts klaut, könnte man die Verschlüsselung komplett deaktivieren. Infolgedessen werden meine (potenziell) sensiblen Daten unverschlüsselt auf das Volume kopiert und es wäre für jemanden einfacher, seinen Inhalt zu „wiederherstellen“, selbst wenn die Verschlüsselung wieder aktiviert wird (wenn sie nicht überschrieben wird).

Aus Sicherheitssicht ist dies also ein No-Go für sensible Daten, auch auf HDD und SSD. J

jcscol

26.09.2018
  • 21.02.2021
Chilipp sagte: Was mich betrifft, geht es in der Diskussion um die Unfähigkeit, Big Sur auf einem zuvor / im Voraus verschlüsselten Volume zu installieren.
OK ...

Wenn jemand zum Beispiel das Passwort meines Accounts klaut, könnte man die Verschlüsselung komplett deaktivieren. Infolgedessen werden meine (potenziell) sensiblen Daten unverschlüsselt auf das Volume kopiert und es wäre für jemanden einfacher, seinen Inhalt zu „wiederherstellen“, selbst wenn die Verschlüsselung wieder aktiviert wird (wenn sie nicht überschrieben wird).

Nur bis der Neuverschlüsselungsprozess abgeschlossen war, aber immer noch ...

Nehmen Sie Ihr Szenario von jemandem:

a) Wer hat Zugriff auf Ihre Maschine
b) Kennt Ihr Admin-Konto-Passwort

Die separat verschlüsselte Bootdiskette bietet Ihnen in diesem Szenario keinen weiteren Schutz, *es sei denn,* der Computer wird heruntergefahren (da das separat verschlüsselte Laufwerk bereits für das Booten des Systems entsperrt wurde).

Aus Sicherheitssicht ist dies also ein No-Go für sensible Daten, auch auf HDD und SSD.

Sie sollten sich sowieso nicht auf Filevault verlassen, um hochsensible Daten zu schützen. Solche sensiblen Daten sollten in einer separat verschlüsselten Sparse-Image-Datei (mit einem anderen Passwort) auf Ihrem Filevault-Laufwerk gespeichert werden.

ZombiePhysiker

Originalplakat
22. Mai 2014
  • 21.02.2021
jcscol sagte: Dies war nicht meine Erfahrung beim Einschalten von Filevault in Big Sur bei meiner ursprünglichen Installation oder bei bootfähigen CCC-Klonen. Sie durchlaufen den Verschlüsselungsprozess, wobei ein 300-GB-Laufwerk auf meinem MacBook über eine Stunde dauert.


Ich habe keine Anzeichen dafür gesehen, dass dies hier der Fall ist


Nur wenn deine Annahme richtig ist, was ich nicht glaube.

Versuchen Sie es mit einer Neuinstallation. Ich sage dir. Dies geschieht innerhalb von ein oder zwei Minuten. Die NO WAY-Verschlüsselung wird tatsächlich so schnell abgeschlossen. Es tut es, während es voranschreitet. Ich habe keine andere Erklärung für die fast sofortige Verschlüsselung eines gesamten Datenvolumens (mehrere Terabyte davon).

Ich habe dies gerade mit einer Neuinstallation von 11.2.1 auf einem Nicht-T2-Laufwerk getan, und das Einschalten von FileVault war in ein oder zwei Minuten erledigt. Dies war auf einem ziemlich leistungsstarken 28-Core-Mac Pro, aber ich sah nicht genug iStat-Festplattennutzung, um rechtfertigen das Gefühl, dass alle Daten durchgegangen sind. Nicht nah genug. Vielleicht ist es anders, wenn man einen Klon irgendwie abarbeitet?

Es kann durchaus eine andere Art von Multi-Key-Verschlüsselung geben, die ich nicht verstehe. Ich bin also kein Verschlüsselungsexperte, es ist überhaupt nicht in meinem Steuerhaus.

Das heißt, ich weiß genug, dass mehrere Terabyte nicht innerhalb von 2 Minuten verschlüsselt werden. Ein Gedanke wäre, wenn dies auf einem T2-Laufwerk passiert. Gut, das ist immer verschlüsselt. Aber das ist auf meinem PCI Micron 9300 Pro U.2-Laufwerk. Das Betriebssystem sieht es als externes Laufwerk an, es bekommt nicht die T2-Behandlung.

Eine Erklärung ist, dass es selbst auf 'nicht verschlüsselten' Laufwerken eine konstante Verschlüsselung im laufenden Betrieb durchführt, und es gibt eine Schlüsselverwaltung, die ich nicht verstehe. Aber ich wünschte, der Prozess wäre nicht so undurchsichtig. Zuletzt bearbeitet: 21.02.2021