FileVault trigger

[Technoprenerd]

This is an idea for a FileVault trigger.

After the cable is detached, the trigger should be possible to remove the user that has access to Filevault (like: https://brendanthompson.com/til/2021/07/remove-user-from-filevault).

The command to remove a user from FileVault is: sudo fdesetup remove -user <Username>

This way, another (non admin) user can be first setup with access/login to filevault (for good opsec with an unkown password, but that would make it unusable after reboot), so that when the shutdown is triggered, the specific filevault user is removed.

The best option is to delete the whole FileVault key, but AFAIK that's not possible on a running Mac since it's also the boot/system partition, which has to be running when the trigger activates.
Links from my research:
https://discussions.apple.com/thread/7169436
https://apple.stackexchange.com/questions/261537/i-was-able-to-erase-filevault-encrypted-drive

Any thoughts or ideas are greatly appreciated.

[maltfield]

Hey @Technoprenerd thanks for the ticket :)

Sorry, I'm not especially familiar with the internals and usage of FileVault. Are you saying that if:

1. The FileVault volume was initially setup by a non-admin "User A" and
2. Only "User A" and another "User B" are granted access to that FileVault volume and
3. We set "User A" password to a long, random passphrase that we intentionally don't save

And then, if we remove "User B" from having access to the FileVault volume, then the FileVault volume effectively can no longer be decrypted (even by the root user)?

Does apple have any decent documentation describing how all this works? In LUKS there's 8-32 keyslots, and the way LUKS works is very clearly documented in the whitepapers:

1. LUKS1 https://gitlab.com/cryptsetup/cryptsetup/-/wikis/LUKS-standard/on-disk-format.pdf
2. LUKS2 https://gitlab.com/cryptsetup/LUKS2-docs/blob/master/luks2_doc_wip.pdf

Is there an equivalent whitepaper describing FileVault so I can wrap my head around its headers/footers/keyslots/encodings/recovery/etc?

I think the deliverable here would be to not only write a self-destruct trigger for FileVault, but to thoroughly document that it works (with forensic evidence), as was done for our LUKS Self-Destruct Trigger:

• https://www.buskill.in/luks-self-destruct/

[Technoprenerd]

@maltfield me neither, but from my limited understanding the above should be correct.

There are multiple FileVault Analysis or Filevault reverse engineering papers, but I haven't found official documentation from Apple.
Found the following links.

Filevault Wikipedia and Apple site:
https://en.wikipedia.org/wiki/FileVault#FileVault_2
https://support.apple.com/guide/security/volume-encryption-with-filevault-sec4c6dc1b6e/web

Filevault analysis from Scheiner:
https://www.schneier.com/blog/archives/2012/08/an_analysis_of.html

And on:
https://forums.macrumors.com/threads/how-exactly-does-filevault-work.2191792/

Some schematics in slide 11 in this pdf:
https://www.cl.cam.ac.uk/~osc22/docs/cl_fv2_presentation_2012.pdf

Maybe there are other sources I haven't looked at yet (like forensics or re papers).

Since there is no official documentation, I don't think we can get to a forensic evidence stage.

[maltfield]

Great links, thanks!

I haven't found official documentation from Apple.

That's really shocking but also not surprising.

Honestly I'm not sure if I'll be investing effort in implementing a self-destruct feature on a disk encryption scheme that doesn't have official documentation. All we'd get is a time-sink of effort into something that we can't prove actually works or not :(

It's unfortunate because I do think a lot of our users are using MacBooks.

I generally recommend veracrypt instead of bitlocker on Windows, but a quick check suggests that veracrypt "System Encryption" is supported in Windows, but not MacOS

• https://www.veracrypt.fr/en/Supported%20Systems%20for%20System%20Encryption.html

Are there any open-source FDE tools that are fully supported and actively used for MacOS?

[Technoprenerd]

@maltfield :

It's unfortunate but it seems that there was one FOSS FDE tool for MacOS, but not anymore FOSS and usable.

PGP Whole Disk Encryption for MacOS - https://tidbits.com/2010/05/14/pgp-whole-disk-encryption-and-pgp-desktop-professional-10-0/
(There are enterprise offerings that use FileVault and add some (key)management layer on top of it)

Not much is known for FDE in MacOS (besides non-foss FileVault and out of date applications).
Best option is to create encrypted volumes/containers (with Veracrypt, use DiskUtility in Apple, etc).

[maltfield]

Agreed. I think the best thing is to tell Mac users to, yes, use FileVault -- but only store really sensitive stuff in veracrypt volumes.

@Technoprenerd I know MacOS is designed to sleep rather than shutdown, but can you tell me: if a MacOS machine is shutdown by BusKill (via the soft-shutdown trigger), does that already dismount veracrypt volumes (ie after booting the computer again, will it or will it not require a password again to decrypt/mount a veracrypt volume that was mounted at the time the shutdown trigger executed)?

[maltfield]

See also #60

[Technoprenerd]

@maltfield: Yes.

I've executed the script : https://github.com/BusKill/buskill-app/blob/master/src/packages/buskill/root_child_mac.py

The output of the logging is:

19:45:06,622 root_child INFO Waiting for command
19:45:31,554 root_child INFO Command received
19:45:31,555 root_child DEBUG Command is 'soft-shutdown'
19:45:31,555 root_child DEBUG Attempting to call trigger_softshutdown_mac()
19:45:31,556 root_child DEBUG BusKill soft-shutdown trigger executing now
19:45:31,556 root_child INFO Attempting to execute `shutdown -h now`
19:45:32,42 root_child DEBUG subprocess returncode|0|
19:45:32,43 root_child DEBUG subprocess stdout|Shutdown NOW!

System shutdown time has arrived

19:45:32,43 root_child DEBUG subprocess stderr||
19:45:32,43 root_child INFO Attempting to execute `poweroff
19:45:32,317 root_child DEBUG subprocess returncode|1|
19:45:32,318 root_child DEBUG subprocess stdout||
19:45:32,318 root_child DEBUG subprocess stderr||
19:45:32,318 root_child ERROR Failed to execute `halt`!
19:45:32,318 root_child INFO Finished executing 'soft-shutdown'

19:45:32,318 root_child INFO Waiting for command

What is interesting is that the screen froze for 2 or 3 seconds, I couldn't do anything (no mouse/keyboard i/o).
When starting it, it will need to require a password for Veracrypt to mount a volume.
Not sure if or when the veracrypt dismounted it's volumes, but there is a settings in Veracrypt Preferences that's called "Dismount All Volumes when: Veracrypt quits". It's on by default (in the auto-dismount setting).