←back to thread

Apple: SSH and FileVault

(keith.github.io)
507 points ingve | 2 comments | | HN request time: 0.02s | source
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 #
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 #
xoa ◴[] No.45295543{3}[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 #
qmr ◴[] No.45295879{4}[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 #
johncolanduoni ◴[] No.45296391{5}[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 #
jshier ◴[] No.45296827{6}[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 #
1. burnerthrow008 ◴[] No.45298200{7}[source]
I thought all SSDs did that for wear-leveling purposes.
replies(1): >>45310433 #
2. johncolanduoni ◴[] No.45310433[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.