There’s an attack vector in there somewhere.

xoa 4 days ago | parent | next [-]

Kinda struggling to think of what, beyond the well understood risks of using password-based SSH at all. But that's easily ameliorated by sticking it behind Wireguard or something similar. I think this is a pretty welcome change vs turning off FV entirely which I've had to do with Mac servers in the past.

▲

g-mork 4 days ago | parent | next [-]

1) steal computer,

2) copy unencrypted SSH host key from it to a new computer (which necessarily must not be stored in the data volume), configured with the network identity of original computer

3) leave new computer in place of original to capture remote SSH-to-unlock attempt

4) use knowledge of password to unlock original's filevault at your leisure somewhere offsite

	▲	johncolanduoni 4 days ago \| parent [-]
		I’m not sure if they do this, but nothing would stop Apple from putting the SSH host key in the Secure Enclave. This would prevent the extract the SSH host (private) key step.

▲

adastra22 4 days ago | parent | prev | next [-]

Tahoe now escrows your FileVailt key to the iCloud keychain, even if that is something you explicitly opted out of before. Can this recovery key be used to unlock over SSH?

▲

pseudalopex 4 days ago | parent | next [-]

> Tahoe now escrows your FileVailt key to the iCloud keychain, even if that is something you explicitly opted out of before.

Yes and no according to Glenn Fleishman. Storing FileVault recovery keys in iCloud Keychain wasn't a choice before. The old iCloud recovery method wasn't end to end encrypted. But iCloud Keychain is. So calling it escrow is debatable. And old recovery keys aren't added to iCloud Keychain. But new recovery keys are stored in iCloud Keychain if enabled.[1]

[1] https://sixcolors.com/post/2025/09/filevault-on-macos-tahoe-...

▲

adastra22 4 days ago | parent [-]

I can confirm that old recovery keys are added to the iCloud Keychain, even if you explicitly opted out of iCloud recovery before. This is exactly what happened to me when I upgraded my systems to macOS 26 yesterday.

iCloud Keychain is NOT the same security as a hardcopy written down recovery key, which is what I used before. This is absolutely a forced change in security policy that was not communicated or opted into by the user.

▲

pseudalopex 4 days ago | parent [-]

Was iCloud Keychain enabled before you upgraded? Or was it forced on?

	▲	adastra22 4 days ago \| parent [-]
		I use iCloud keychain as my password manager, just for other things.

▲

xoa 4 days ago | parent | prev | next [-]

I don't know but I'm still not seeing the relevance? The threat/target scenarios in general for FDE are physical theft of a device, hardware servicing by 3rd parties, and dealing with end of life (either due to replacement or hardware failure). FDE means that "erasing all data securely" can involve simple key purging instead of extremely time consuming zeroing/overwriting or physical destruction. But it's no barrier nor meant to be any barrier against hot online attacks, if someone is able to get admin remote access to a running system without authorization that is the problem and it'd be equally the problem whether the machine was cold booted or already booted. And if they illegitimately possess the recovery key then it's a problem whether remote or physically present.

FWIW and having not looked yet (since I never upgrade major macOS versions anymore without a good 3-5 months going by and the first 2-3 minor fixes first) my default assumption is it's still possible to not escrow recovery keys, if only because plenty of people don't use iCloud keychain at all (including myself), and also because I know for sure that you can use configuration profiles to control FV recovery key escrow already. That'd be a requirement for lots of business usage so even if it needs a profile to use should still be there? But again this all seems orthogonal to the issue at hand. Stuff does crash or need updates that require a reboot and previously you either needed to turn off FV entirely or use a hardware workaround for GUI access (ie, setup a basic SBC with HDMI/USB in and use it as a bridge or use a premade solution along the lines of PiKVM [0]). It's definitely a small but nice (and feels rare nowadays from Apple) remote admin gesture to let it be done in software like it should have been long ago.

----

0: https://pikvm.org/

▲

adastra22 4 days ago | parent | next [-]

> my default assumption is it's still possible to not escrow recovery keys

At least if you have an iCloud account attached to your profile (I have no idea what happens if you don't), the upgrade process will automatically and without notification or asking consent add your recovery key to the iCloud Keychain. It does tell you afterwards what it so helpfully did.

▲

qmr 4 days ago | parent | prev [-]

Call me crazy, (“you’re crazy!”) but I still zero all storage before destruction, sale or repurposing.

Belt and suspenders.

▲

johncolanduoni 4 days ago | parent | next [-]

For SSDs that doesn’t actually guarantee deletion - there could still be some over-provisioned erase blocks that have the old data due to wear leveling.

▲

jshier 4 days ago | parent [-]

Apple's SSDs are all encrypted at the controller nowadays. No need to rewrite, just reformat and it cycles the key, leaving any recoverable data irrevocably encrypted (until we break modern encryption).

▲

burnerthrow008 4 days ago | parent [-]

I thought all SSDs did that for wear-leveling purposes.

	▲	johncolanduoni 3 days ago \| parent [-]
		They do, but consumer ones usually don't implement the additional API (TCG Opal) that lets you lock/unlock the hardware encryption key. Without that capability you can't use it to implement full-disk encryption. They do usually implement the NVMe secure erase feature though, which will rotate it.

▲

wpm 4 days ago | parent | prev [-]

I mean, if you regularly deal with data worth the effort necessary to recover, that isn’t crazy at all

	▲	adastra22 a day ago \| parent [-]
		On a modern SSD it is cargo culting though. Every write is assigned to a new sector. Makes sense when wiping the whole drive though.

▲

Citizen8396 4 days ago | parent | prev [-]

1. Keychain is local if you don't enable iCloud

2. If someone has compromised your iCloud account and/or device, you have bigger things to worry about

3. No

	▲	adastra22 4 days ago \| parent [-]
		> If someone has compromised your iCloud account and/or device, you have bigger things to worry about That doesn't mean all my security should be a house of cards with a single point of failure in the form of my iCloud account and/or device(s). Someone shouldn't be able to get the keys to the castle just by compromising any single one of those.

▲

shawnz 4 days ago | parent | prev [-]

Would Wireguard function in this pre-unlock environment?

▲

lxgr 4 days ago | parent | prev | next [-]

Unless this somehow force-enables username/password authentication for SSH configs that otherwise enforce public-key auth, I can't really think of anything. Can you?

▲

bigyabai 4 days ago | parent | prev [-]

Yup. My post-Blastdoor reaction to these writeups is always one of tentative suspicion.