Most active commenters
  • adastra22(6)

←back to thread

Apple: SSH and FileVault

(keith.github.io)
507 points ingve | 16 comments | | HN request time: 0.001s | source | bottom
Show context
mmaunder ◴[] No.45294710[source]
There’s an attack vector in there somewhere.
replies(3): >>45294968 #>>45295595 #>>45300986 #
xoa ◴[] No.45294968[source]
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.
replies(3): >>45295011 #>>45296172 #>>45301008 #
1. adastra22 ◴[] No.45295011[source]
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?
replies(3): >>45295348 #>>45295489 #>>45295543 #
2. Citizen8396 ◴[] No.45295348[source]
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

replies(1): >>45297351 #
3. pseudalopex ◴[] No.45295489[source]
> 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-...

replies(1): >>45297329 #
4. xoa ◴[] No.45295543[source]
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/

replies(2): >>45295879 #>>45297339 #
5. qmr ◴[] No.45295879[source]
Call me crazy, (“you’re crazy!”) but I still zero all storage before destruction, sale or repurposing.

Belt and suspenders.

replies(2): >>45296391 #>>45297890 #
6. johncolanduoni ◴[] No.45296391{3}[source]
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.
replies(1): >>45296827 #
7. jshier ◴[] No.45296827{4}[source]
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).
replies(1): >>45298200 #
8. adastra22 ◴[] No.45297329[source]
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.

replies(1): >>45297661 #
9. adastra22 ◴[] No.45297339[source]
> 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.

10. adastra22 ◴[] No.45297351[source]
> 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.

11. pseudalopex ◴[] No.45297661{3}[source]
Was iCloud Keychain enabled before you upgraded? Or was it forced on?
replies(1): >>45297711 #
12. adastra22 ◴[] No.45297711{4}[source]
I use iCloud keychain as my password manager, just for other things.
13. wpm ◴[] No.45297890{3}[source]
I mean, if you regularly deal with data worth the effort necessary to recover, that isn’t crazy at all
replies(1): >>45328661 #
14. burnerthrow008 ◴[] No.45298200{5}[source]
I thought all SSDs did that for wear-leveling purposes.
replies(1): >>45310433 #
15. johncolanduoni ◴[] No.45310433{6}[source]
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.
16. adastra22 ◴[] No.45328661{4}[source]
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.