Big Sur will not install on encrypted drives, why?

[ZombiePhysicist]

For many years I have formatted my system/boot hard drive as an encrypted drive. First as HFS+ Encrypted, and the last several years as APFS Encrypted. All worked well up through Catalina.

However, now if you first format a drive as APFS Encrypted and try to use the Big Sur (latest 11.1, and earlier 11.01) onto that drive you get the following error:

"You may not install to this volume because it has a disk password"

Yet, if you install on a non-encrypted drive, you may later then select FileVault and the entire container will get encrypted per this thread: https://discussions.apple.com/thread/252036326

However, this means anyone can simply flip the FileVault switch and undo encryption on the drive. This is bad when you dont want the drive to be unencrypted at any time.

The question is WHY!? Why this behavior. The current work around is to install Catalina on an APFS encrypted drive, and then do an upgrade on that drive. Big Sur will and does work fine, but why require the crazy work around?

Would love any thoughts/speculations on if this is a bug or a feature, and if it's a feature, WHY!?

 

[robotica]

There may have been a change to the encryption protocol? It might want to use it’s updated encryption.

 

[svanstrom]

Ok, so a quick search seem to tell me that there have been changes made to CoreStorage…

Bitdefender B2B Help Center

www.bitdefender.com

macOS Big Sur Known Issues - Bombich Software

bombich.com

 

[ZombiePhysicist]

There may have been a change to the encryption protocol? It might want to use it’s updated encryption.

I have both used the older APFS formatting and tried freshly formatted drives with 11.1. So I'm using it's own encryption.

Your guess is a good one though because something profound changed between encrypting the drive on 11.01 and 11.1 with regard to how Big Sur does time machine backups. See this thread: https://forums.macrumors.com/threads/best-way-to-format-time-machine-drive.2280154/

It's been a night and day performance difference having re-formated to APFS in 11.1 and re-run time machine.

Anyway, here even when I reformat with 11.1, it still wont let me install the OS.

 

[ZombiePhysicist]

Ok, so a quick search seem to tell me that there have been changes made to CoreStorage…

Bitdefender B2B Help Center

www.bitdefender.com

macOS Big Sur Known Issues - Bombich Software

bombich.com

Yea, I have no doubt a lot of things changed, but yet it still works if you do a full APFS encrypted drive format, install Catalina, and then do the Big Sur upgrade. Although it may be difference without a difference in that I wonder if it didn't do a "conversion".

Meaning I see that my FileVault is turned on and my drive container shows as APFS Encrypted on the drive in Disk Utility.app... I wonder if I just turn FileVault off on the machine if it will in essence disable APFS encryption with that switch now? However, the security panel shows a recovery key... I dont know if just your vanilla fileVault switch on/off sets a recovery key?

 

[Chilipp]

This issue is really annoying.

For me, it seems that it is caused by Apple's new policy: "do not encrypt the system container as it is mounted read only and contains the same data for all the macs out there". Maybe "Apple thinks" it might also be an energy and overall performance improvement since no encryption results in lesser power and "performance" consumption.

I don't know but let me know if you find a solution for installing Big Sur onto a fresh & already encrypted APFS volume.

 

[ZombiePhysicist]

It's made more weird because I'm pretty positive Big Sur is ALWAYS ENCRYPTING ALL CONTAINERS, just it will have a public key for containers that do not have "encryption" set on.

Why do I suspect this. Because I just installed Big Sur fresh on a non encrypted APFS drive. Put over 10TB of data in an account. THEN turned on file vault and the entire thing was "encrypted" in less than a minute, and now the container shows as an APFS Encrypted container. NO WAY that it processed that much data that fast, so that means these things are always encrypted from the start. So if that's so, why not let me lock the entire drive anyway, because the argument on performance/consumption of encryption goes away if everything is essentially always encrypted anyway.

To me what this really means is the entire drive was ALWAYS encrypted and now I set a key to it. But this makes me super worry. Does that mean that Filevault works with 2 keys? And with the OS easily able to change access via password. How was this encrypted so far? I could be misunderstanding things, but this brings up the specter of a universal unlock/backdoor key of some sort.

 

[Daverich4]

However, this means anyone can simply flip the FileVault switch and undo encryption on the drive. This is bad when you dont want the drive to be unencrypted at any time.

You need the administrator name and password to turn off FileVault. How is that different from any other form of encryption?

 

[Quackers]

I have not turned on FileVault and I ran in the terminal
diskutil apfs list
and the output shows no encryption for all volumes, however
for both Macintosh HD and Macintosh HD - Data volumes it shows as
encrypted - No (encrypted at rest)

 

[Chilipp]

You need the administrator name and password to turn off FileVault. How is that different from any other form of encryption?

The difference is that in my case my disk-encryption password always differ from my user accounts password and I personally do not store/link it with the keychain due to security concerns.

I could be misunderstanding things, but this brings up the specter of a universal unlock/backdoor key of some sort.

I totally agree with you - I also don't like the fact that we only get some sort of "recovery-key" that maybe is not the actually used encryption key - so I have no idea what key (or key-deviation-random-algorithm) is used for encryption.

 

[jcscol]

II just installed Big Sur fresh on a non encrypted APFS drive. Put over 10TB of data in an account. THEN turned on file vault and the entire thing was "encrypted" in less than a minute, and now the container shows as an APFS Encrypted container. NO WAY that it processed that much data that fast

This has not been my experience when switching on Filevault in Big Sur on my original install or on CCC bootable clones. They go through the encryption process, with a 300GB drive taking over an hour on my macbook.

To me what this really means is the entire drive was ALWAYS encrypted and now I set a key to it.

I've not seen any indication that this is the case here

but this brings up the specter of a universal unlock/backdoor key of some sort.

Only if your assumption is correct, which I don't think it is.

 

[Daverich4]

The difference is that in my case my disk-encryption password always differ from my user accounts password and I personally do not store/link it with the keychain due to security concerns.

I think I’m not understanding something here. The discussion was about turning off FileVault, something that requires access to an unlocked computer. At that point access to the encrypted drive is transparent, no password required. Are you talking about something else?

 

[Chilipp]

I think I’m not understanding something here. The discussion was about turning off FileVault, something that requires access to an unlocked computer. At that point access to the encrypted drive is transparent, no password required. Are you talking about something else?

As far as I am concerned, the discussion is about the inability to install Big Sur on a previously / in advance encrypted volume.

And even though someone may only disable file-vault for an already unlocked computer, it certainly does make a difference whether it is possible to disable it at all or not.

If someone for example snitches my accounts password, it would be possible to disable the encryption totally. As a result my (potential) sensitive data gets copied unencrypted onto the volume and it would be easier for someone to "recovery" its contents even if encryption gets enabled again (if not overridden).

So from a security perspective this is a no-go for sensitive data, on HDD and SSD as well.

 

[jcscol]

As far as I am concerned, the discussion is about the inability to install Big Sur on a previously / in advance encrypted volume.

OK ...

If someone for example snitches my accounts password, it would be possible to disable the encryption totally. As a result my (potential) sensitive data gets copied unencrypted onto the volume and it would be easier for someone to "recovery" its contents even if encryption gets enabled again (if not overridden).

Only until the re-encryption process was completed, but still ...

Taking your scenario of someone:

a) Who has access to your machine
b) Knows your Admin account password

Having the boot disk separately encrypted is not going to offer you any further protection in this scenario *unless* the machine is powered down (since the separately encrypted drive has already been unlocked for the system to boot).

So from a security perspective this is a no-go for sensitive data, on HDD and SSD as well.

You shouldn't be relying on Filevault for protecting super-sensitive data anyway. Such sensitive data should be stored in a separately encrypted sparse image file (with a different password) on your Filevault drive.

 

[ZombiePhysicist]

This has not been my experience when switching on Filevault in Big Sur on my original install or on CCC bootable clones. They go through the encryption process, with a 300GB drive taking over an hour on my macbook.


I've not seen any indication that this is the case here


Only if your assumption is correct, which I don't think it is.

Try it on a fresh install. I'm telling you. It happens within a minute or 2. NO WAY encryption actually gets completed that fast. It's doing it as it goes along. I have no other explanation for the near instant encryption of an entire volume full of data (multiple terabytes of it).

I just did this with 11.2.1 fresh install on a non-T2 drive, and turning on FileVault was done in a minute or 2. This was on a pretty powerful 28core Mac Pro, but I didn't see enough iStat disk usage to warrant feeling it was going through all the data. Not near enough. Perhaps it's different when you're working off a clone somehow?

There may well be some other type of multi-key encryption I'm not understanding. I'm so not an encryption expert, it's not at all in my wheelhouse.

That said, I know enough that multiple terabytes do not get encrypted within 2 minutes. One thought would be if this happened on a T2 drive. Fine, that is always encrypted. But this is on my PCI Micron 9300 Pro U.2 drive. The OS sees it as an external drive, it does not get the T2 treatment.

One explanation is it is doing some on the fly constant encryption even on 'non-encrypted' drives and there is some key management that I'm not understanding. But I wish the process wasn't so opaque.

 

[0286338]

What I dont understand is how you found Catalina was ok but only found this problem when moving to Big Sur! I have had the same problem going from Mojave to Catalina and I can find no workaround. Like you I have a different password for my drive encryption versus user accounts, and this is the most secure approach out there. there is no way FV can improve my security that I know of, by offering alternative ways to unlock a drive. One way is one attack vector, 2+ ways is more, so Apple now forces a lower standard of security for my data than it used to. Disappointing to say the least. Did you ever find a meaningful answer/solution re BigSur? I'd be interested to hear if you did. Thanks

 

[ZombiePhysicist]

Sadly. no. It’s just new behavior. Apple just keeps taking away useless features and not enough people complain. Too many apologists enabling them to do less and less.

 

[0286338]

Too many apologists enabling them to do less and less.

Amen, ain't that the truth.
I remember a time when people's suggestions and complaints about OSX were taken really seriously and instantly considered for fixes/updates. Those times are sadly long gone, now all I find is troves of threads (on Apple forums and elsewhere, much like this one) where threads just sit open ended with nobody interested nor inclined to assist or find workarounds. I guess most people just don't care much, either that or Apple have finally trained their disciples to stop wanting stuff Apple dont want them to have. The last good example of people giving a damn in big enough numbers was this superb github thread (and script) to block the countless background processes Apple decided to build into OSX. https://gist.github.com/pwnsdx/1217727ca57de2dd2a372afdd7a0fc21
Anyway, shame, I was hoping you found a solution there.