FileVault Alternative?

[misanthrophy]

hi,

I am using a cMP 4.1 -> 5.1 running 10.13.6.

As Apple doea not offer to properly run FileVault on my configuration with a TITAN X installed, I am searching for a good alternative!

I am planning on enabling a Firmware Password for HW encryption.
A Yubikey for an additional login security layer.
„FileVault“ for software encryption.

Does here anyone use another software similar to FV? What would you suggest?

Thx in advance!

 

[bookemdano]

Someone correct me if I'm wrong here, but it was my understanding that the cMP doesn't have the ability to set a firmware password. At least that's the impression I was left with after reading this article (which states only the 2013 MP has that ability).

Not sure you're going to find a seamless replacement for FV, sadly. Best I can think of would be to consciously store all personal info on a second drive (USB or internal) and encrypt that.

 

[misanthrophy]

Someone correct me if I'm wrong here, but it was my understanding that the cMP doesn't have the ability to set a firmware password. At least that's the impression I was left with after reading this article (which states only the 2013 MP has that ability).

Not sure you're going to find a seamless replacement for FV, sadly. Best I can think of would be to consciously store all personal info on a second drive (USB or internal) and encrypt that.

Hmmm, this article https://support.apple.com/en-us/HT204455
Does not exclude any Mac for FW passwords?! You only need to have a recovery partition. I haven‘t tried it yet, but will do it tomorrow.

 

[tsialex]

Hmmm, this article https://support.apple.com/en-us/HT204455
Does not exclude any Mac for FW passwords?! You only need to have a recovery partition. I haven‘t tried it yet, but will do it tomorrow.

Firmware password is practically useless with any Macs without Intel Management Engine. You just need to change the hardware config, replace the main disk/change RAM and you disable it.

 

[w1z]

Does here anyone use another software similar to FV? What would you suggest?

You can still use filevault/APFS encryption but only for your home folder - Do you need to protect your main OS too? It entails using a secondary account to manually mount your home folder (on every boot) which resides on an encrypted partition/volume then switching to your account.

Let me know if you are interested so I can share the steps or you could sell your Titan and buy a Mac EFI GPU then follow my steps here

 

[Lycestra]

Firmware password is practically useless with any Macs without Intel Management Engine. You just need to change the hardware config, replace the main disk/change RAM and you disable it.

This is why Mac Pro's have locks...? That nub in the opening handle can turn to reveal a loop, which you can then lock to prevent any internal modifications.

Came here to see if you happen to know any caveats of using a Firmware Password with Mojave and non-EFI cards in a Mac Pro. e.g. every other early boot screen (FileVault, Option Boot Disk selection) can't be displayed, so is the Firmware Password somehow different? I see there is an OS level enable/disable of the firmware password, so it's an extra layer of protection. But if I needed to run Rescue mode or boot from USB or in Target Disk mode without being able to boot normally to disable the password, is it even possible without an EFI-capable display?

Also, any explanation of this "-allow-oroms" option with the "firmwarepassword" command?

Thanks for the input!

 

[tsialex]

This is why Mac Pro's have locks...? That nub in the opening handle can turn to reveal a loop, which you can then lock to prevent any internal modifications.

Came here to see if you happen to know any caveats of using a Firmware Password with Mojave and non-EFI cards in a Mac Pro. e.g. every other early boot screen (FileVault, Option Boot Disk selection) can't be displayed, so is the Firmware Password somehow different? I see there is an OS level enable/disable of the firmware password, so it's an extra layer of protection. But if I needed to run Rescue mode or boot from USB or in Target Disk mode without being able to boot normally to disable the password, is it even possible without an EFI-capable display?

Also, any explanation of this "-allow-oroms" option with the "firmwarepassword" command?

Thanks for the input!

The lock blocks unauthorised hardware mods, and disabling firmware password.

It's not possible without EFI, sorry.
[doublepost=1538743023][/doublepost]-allow-oroms = Option ROMs, like some PCIe Disk Controllers have.

 

[Lycestra]

The lock blocks unauthorised hardware mods, and disabling firmware password.

It's not possible without EFI, sorry.
[doublepost=1538743023][/doublepost]-allow-oroms = Option ROMs, like some PCIe Disk Controllers have.

So, summary:
- Setting a firmware password prevents changing boot partitions and modes (e.g. rescue, target disk mode). to do so requires entering a password or disabling the password
- password can only be entered with EFI display if during boot
- password can be disabled/enabled in booted OS
- resetting/disabling password also occurs after altering hardware configuration (pull a memory card or something, anything)
- any such alteration requires opening the computer case


So to consider a use case with Mojave:
- enable firmware password, always boot from the preferred OS partition
- lock the case with something better than a luggage lock
- to change boot mode or go to rescue, entering the password isn't an option, only disabling it
- if there's some foresight, can disable it in the OS, and continue like normal
- if this is a rescue or something is preventing OS booting, you must open the case and disable it by changing hardware
- after doing whatever it is you needed, boot the normal OS and re-enable the firmware lock.

so really it's a lock that can be unlocked and removed via authorized software (admin password and firmware password) or physical interaction that involves a physical lock. Not how it was originally intended, I gather, but at least not as wide open.

Since filevault is not available, this is probably better than nothing, in terms of protecting the physical container of my data from unauthorized access, by direct access or side-booting hackery.

 

[tsialex]

So, summary:
- Setting a firmware password prevents changing boot partitions and modes (e.g. rescue, target disk mode). to do so requires entering a password or disabling the password
- password can only be entered with EFI display if during boot
- password can be disabled/enabled in booted OS
- resetting/disabling password also occurs after altering hardware configuration (pull a memory card or something, anything)
- any such alteration requires opening the computer case


So to consider a use case with Mojave:
- enable firmware password, always boot from the preferred OS partition
- lock the case with something better than a luggage lock
- to change boot mode or go to rescue, entering the password isn't an option, only disabling it
- if there's some foresight, can disable it in the OS, and continue like normal
- if this is a rescue or something is preventing OS booting, you must open the case and disable it by changing hardware
- after doing whatever it is you needed, boot the normal OS and re-enable the firmware lock.

so really it's a lock that can be unlocked and removed via authorized software (admin password and firmware password) or physical interaction that involves a physical lock. Not how it was originally intended, I gather, but at least not as wide open.

Since filevault is not available, this is probably better than nothing, in terms of protecting the physical container of my data from unauthorized access, by direct access or side-booting hackery.

Seems correct, but this need to be tested. We are making presumptions based on previous BootROMs/HighSierra, I don't know if Apple changed this workflow with the new BootROMs/Mojave.

 

[h9826790]

Formatted the drive to apfs encrytped may be the alternative option. No boot screen required. And you have to type password blindly to boot the OS.

It’s been tested in HS can do that way with non Mac EFI GPU. Should be the same in Mojave.

 

[0488568]

If you are looking for an encryption solution there is veracrypt. I works with a partition or a file. It can also chain different types of algorithms. A lot slower but I think its tougher to crack than FileVault

 

[jaysee_au]

I've been thinking about possible solutions to this problem.

Have done some testing - and I think the most reliable (and secure) solution will be the "second APFS encrypted volume used for home". A great benefit to APFS is that every volume can access the same space - so I'm thinking a 'boot' user to log in with (with saved password for APFS volume if you want) + then the primary user on a separate partition will be the best option.

I did some testing and it seems that if you don't leave the first user logged in, the system tries to unmount drives the user mounted when they log out. So you need to log in, mount the drive, fast user switch to your second user (with home set to the encrypted volume "/Volumes/<username>").

Could be a good enough solution for me - I'm primarily worried about data being stolen / compromised in the event my house is robbed more than I am about someone coming in and installing spyware while I'm away so I think I can live without full disk encryption for System & Apps etc. but can't without it for home. Will do a bit more testing and report back.

 

[Lycestra]

I've been looking at the second encrypted apfs partition sharing the same space. I'm not sure the best way to "move" my home from the boot partition to the secondary. Options I could think of are rsync -avE, mv, or restore from TimeMachine. I haven't found a way to restore my home from TimeMachine in a different location, and rsync -avE seems to take forever. trying mv now, which I did in stages (a bash for-loop of all files, including "." files) so that i could actually move them from primary to secondary directly, and let APFS manage the free space. My main worry is about the mail "DataVault" being inaccessible no matter the method. Hopefully not needed...? Looking forward to the report.

 

[jaysee_au]

Since posting above, I've had another thought inspired by the fact that people are using dosdude1's patcher to get past the install check (I have EFI graphics).

I'm wondering if we could just create a new APFS container, add two volumes - 1 encrypted, 1 not, and install to the unencrypted one... then use Carbon Copy Cloner to move it to the other encrypted one and then boot off it. I'm doing some testing now... will report back.

 

[jaysee_au]

Ok - a bit of an update.

I have a GTX680 flashed to run Mac Edition ROM, so I get EFI support.

I was able to:

1. Install macOS 10.14.0 to a clean SSD (fresh partition map)
2. Add another APFS (Encrypted) volume to that container with a password
3. Boot to my original drive (10.13.6), unlock the encrypted volume and then use Carbon Copy Cloner to clone. I got a warning about the APFS helper partitions but I ignored it as I figured it's the same hardware.
4. Set startup disk to the encrypted drive and rebooted. Got a FileVault like unlock screen with 'Disk Password' rather than username. Entered password and booted.
5. Enrolled into the Developer Previews and ran the 10.14.1 update. Installed fine - had to unlock drive on each boot of the machine as per item 4. (wanted to check if updates would break this - I think it'll be ok).

Only weirdness was I couldn't "enable users" for FileVault, but I'm not that worried about that - happy to just unlock using password at EFI.

After this was all successful, I decided to see if I could startup the machine with an RX580 instead of my GTX580 Mac Edition. After a few minutes of trying (entering passwords blind) I gave up. I get the feeling from an email from Craig Federighi I got, that the problem is loading the UI to unlock the drive just won't work on the newer cards. I have read some reports of people being able to blindly unlock drives, but it didn't work for me.

It seems that the MacPro 5,1 with an EFI GPU that also supports Metal should be 100% supported for Mojave, but Apple have missed that these cards exist because they were never shipped as OEM parts in the MacPros. But there looks to be no real reason why FileVault can't be allowed on a GTX680 machine, but probably not worth the effort for Apple when they can't exactly recommend people go and buy an old GPU and flash the firmware to make it work.

My guess is that doing an upgrade of my main partition to Mojave would work the same way. I will add disable FileVault on my current boot volume first, then run the upgrade of Mojave over it, then boot to a temporary install of macOS with CCC and then clone my upgraded current partition to a new, APFS encrypted partition and boot from that. Thankfully I have over half of my SSD free, so it should be easy enough.

I think I'll give that a shot at some point in the next few days.

(Edit: Obviously this won't help the people with non EFI graphics sadly. But it feels like there's been some changes to the bootloader since 10.13 which could be why the 'blind' option doesn't work now.)

 

[bookemdano]

Thanks for sharing your experience. I also was unable to enter a FV disk password blind with my RX 580. Ended up formatting the drive back to plain APFS and reinstalled Mojave.

Another poster who tried this same method last week with dosdude1's patcher mentioned the different-looking password entry screen asking for the disk password instead of the login password. My guess is that the act of enabling FV via System Preferences is what performs the additional "special sauce" needed to allow the user accounts to unlock the drive. Since that routine is disabled in Mojave, I'm not sure if there is any other way to get it.

I just wish Apple would come up with a way for owners of EFI Metal cards to re-enable it. I understand why they disabled it by default, but they should add back in a backdoor way to use it for folks who know what they're doing. Maybe owners of EFI Metal cards should submit bug reports to that effect? Couldn't hurt.

 

[Lycestra]

Moving my home directory to an encrypted second APFS "partition" that shares its space with the non-encrypted boot drive seems to work. It's by no means automatic. Same procedure as if you were to move your home directory off of the boot drive. To mount it, I have to log in as another user (in my case, I use my admin user, since my normal user is a separate non-admin). I'm not going to automate it tho, since that defeats some of the purpose.

I haven't found any problems, just a few typical instances of re-logging in in some apps. I spent most of the time yesterday just making quadruple sure i kept my data. The solution of using "mv" seemed to be just fine.

 

[w1z]

It's by no means automatic.

I wouldn't fully automate it as the password, if saved under the boot user, to unlock the encrypted partition would reside in the user/system keychain which is stored on the non-encrypted drive.

If you are into devising or using nifty hacks or solutions, like me, you could securely automate the process by using a password protected/encrypted usb flash drive and system run script that would execute on boot, scan mounted USBs for the filevault master keychain, unlock then mount filevault drives/partitions automatically. You can also add a fingerprint reader or use a yubikey for another layer of security. Many ways to go about it.