Why is macOS update creating a new file vault recovery key?

sxbsxb wrote:

I turned File Vault off. I never noticed a decryption status bar. I left the machine overnight and turned File Vault on this morning. I opted to avoid iCloud and had it generate a new key. When I clicked Continue it said it was calculating how long it would take. Then, within 30 seconds it said it was done. NOT POSSIBLE. I am using 333 GB out of 494 GB capacity.

My less than fully informed understanding of the subject is that this is normal for silicon Macs like yours, which are always encrypted and have been from the get-go. Turning on FileVault provides additional password protection and generates the Recovery Key we’re discussing.

Some of the details can be found here (and I’m sure lots of other places):

https://eclecticlight.co/2023/03/31/why-you-should-enable-filevault/

What I just found out is that while I got two panels (after two logins with an account without iCloud) warning me that the recovery key had changed, it actually hadn't!

I tried "sudo fdesetup validaterecovery" on both new ones and the original one, and the 'new' ones returrned false while the original one returned true (phew!)

So, definitely a bug?

sxbsxb wrote:

Still puzzled with the bogus keys generated when updating. I am betting it's because Apple developers didn't test without iCloud as most of them would be using it.

The last paragraph of this article and the comments following it (especially those by the article's author) purport to provide context to what′s occurring.

https://eclecticlight.co/2024/03/07/apple-has-released-sonoma-14-4-update-and-security-updates-to-ventura-and-monterey/

It doesn′t, however, address the serious security issue that′s being created for those who unwittingly accept new FileVault Recovery Keys that aren′t in fact valid.

Another unresolved issue, of course, is the status of the Recovery Keys generated for those who opt to have their Recovery Keys escrowed to iCloud and who have no way to validate their keys, even if they wanted to do so, since they never see them.

DEFCON 3 wrote:

The last paragraph of this article and the comments following it (especially those by the article's author) purport to provide context to what′s occurring.

Don't get your information from social media influencers.

Another unresolved issue, of course, is the status of the Recovery Keys generated for those who opt to have their Recovery Keys escrowed to iCloud and who have no way to validate their keys, even if they wanted to do so, since they never see them.

It is important to remember that the FileVault recovery keys are just that - for last-ditch recovery. Your account password will continue to unlock FileVault. I recommend maintaining an additional Administrator account that you don't screw around with as a fallback.

I've been using FileVault for many years and I've never needed to use a recovery key. People should be realistic. Anyone who manages to forget their login password probably isn't going to be able to find their recovery key either. The recovery key is a "warm fuzzy" that Apple really has to provide because people would freak out otherwise. But you'll never need it or use it.

During the 3 month life of my Macbook, I have had 3 File Vault recovery keys.

I did not opt for an association with the Apple ID.

2 recent updates gave me a new recovery key.

The first time I recieved a new one, I overwrote the original, I didnt think to keep the 'old' one.

The second time, I recieved a new one I did keep the previous.

For both of my new keys I ran:

fdesetup validaterecovery

Both were false, they were not valid keys. I don't have the original to check if that was valid.

When I learned they were invalid, I turned off, and back on the file vault to key a new key.

This time fdesetup validaterecovery was true. The latest key is valid.

Be aware! I just updated to 14.5

Again, there was a request to update the Filevault Key.

HOWEVER, unlike last time, the NEW key is now the valid key.

Previously, the new keys returned false when running

sudo fdesetup validaterecovery

sxbsxb wrote:

The last two macOS updates, to 14.4 and 14.4.1, give me a screen that says the File Vault Recovery Key has been changed. That is a rather big deal, IMO. What is going on? Anyone else see this?

Does that mean you were given a new key...?

Verify FileVault status from Terminal.app copy and paste:

fdesetup status

verify if FileVault Recovery Key current, copy and paste;

sudo fdesetup validaterecovery

“Enter the current recovery key:” type or paste in your Recovery Key and press ENTER\Return key to continue

(note: your psswd will not echo on screen type it in anyway, use the enter\return key to proceed.)

You will see:

True if the Recovery Key the current key;

False if no

You can turn off FIlevault from System Settings...

you can read more—

If you encrypted your Mac’s boot disk with FileVault 2 —this prevents you from using your Apple ID to reset your password

(since the password is used in FileVault’s encryption). Read this Apple support document for more information about FileVault. ref: Protect data on your Mac with FileVault - Apple Support

macOS utilizes the macOS admin user account password for unlocking Filevault.

more on File Vault2— see HWTech

enter a password to unlock the disk”macin… - Apple Community

AndyXII wrote:

I assume your agenda would be the promotion of your software product.

Not at all. For one thing, the Apple Support Community Terms of Use forbid me from doing that. For another, EtreCheck's revenue peaked long ago. It is rapidly becoming more trouble than it's worth.

Dr. Oakley's blog provides useful information (admittedly for those with a decent grasp on the subject) in a courteous fashion. I'll leave preaching to you.

A fascinating perspective! There is definitely some useful information there. When I want the full path to the awful Apple "lsregister" tool, I tend to go to that web site to get it instead on even looking in my own source code.

But I do have a decent grasp on the subject, so I can tell the difference between convenient information like the path to a system tool, which can be easily verified, and speculation, misinformation, and misunderstandings that are all woven within in the same post.

It's particularly fascinating how you would interpret that as "courteous". It's really just aligning a message with other social media influencers in the same space. They know what people want to hear and feed that to them. Then, a non-influencer comes along and says something contradictory, based on facts that would require effort to verify. That message of discord is treated as "rudeness". I have contradicted not some social media influencer, but your own deeply-held beliefs. You take offence, and double-down faith in your source of misinformation.

It really is close to "preaching". There is even a term for it - "preaching to the choir". But even in real-life congregations, people are aware of the dangers of having a savvy, manipulative paster who uses their position to craft a conformable message designed more to secure their own position instead of focusing on those parts of the gospel that people need to hear. It's pretty easy to see when people in other churches are being fooled. The trick is to be able to apply that critical analysis to one's own group.

sxbsxb wrote:

Or, did I read the documentation correctly that I can turn off File Vault with just my password? And then turn it on later when the disk has been decrypted and turn it on again?

I do want File Vault on -- but I want it working.

I would turn off FileVault while you are able.

After it completed the decryption and you want to continue using FileVault, you can enable it at that time. The process can take some time, let it run...you can use your mac as normal.

At that time I Suspect you have the option to receive a new FileVault pass key...

Then verify it is valid so you can proceed with confidence.

AndyXII wrote:

I'm sure you had not meant to infer otherwise.

Don't put words into other people's mouths, especially when they just said the exact opposite.

His web site is a veritable encyclopaedic cornucopia of information on all things macOS related.

Social media can be more than just those well-known social media platforms, it can be traditional web sites, ancient message systems, blogs, and even software. It all boils down to believing what someone on the internet tells you. Sometimes they're right. Sometimes they have an agenda. If you can't tell the difference, then you're a follower. It doesn't matter if you follow a politician, a party, a preacher, or some guy on the Internet. You're still being led around on a string the same way.

evoolb wrote:

Why would the FileVault Recovery Key change on my MacBook Pro with M3 after the upgrade to 14.5, but not on the MacBook Pro with M2?

For that matter, why would it change on either machine? There's no obvious explanation, making it appear to happen almost at random.

(Whether it's random or not, the posts here and elsewhere seem to suggest it tends to be persistent, often affecting the same systems across Sonoma upgrades. The 14.5 upgrade marks the third consecutive time for my MacBook Pro M1.)

Interesting that the replacement key you received for your M3 was actually valid, which is a new wrinkle. Thanks for the update.

sxbsxb wrote:

The last two macOS updates, to 14.4 and 14.4.1, give me a screen that says the File Vault Recovery Key has been changed. That is a rather big deal, IMO. What is going on? Anyone else see this?

I haven't updated to 14.4.1 yet, but this occurred to me as well during the recent 14.4 update.

I wasn't frankly paying attention during the initial reboot after the update, and consequently can't recall the actual process; but at the point at which I realized that I was to be given a new FileVault Recovery Key, I opted, perhaps ill-advisedly, to force a system shutdown. The machine then rebooted normally and my existing, locally stored Recovery Key remains valid. So no harm done.

I've seen reports of this same issue on other forums, but unfortunately no advice on how to circumvent or suppress it, much less an explanation of its rationale (if there actually is any).