FileVault 2's FDE = Goodbye to remote boot & login?

Question

FileVault 2's FDE = Goodbye to remote boot & login?

Does enabling Lion's Full Disk Encryption (FDE) in FileVault 2 effectively rule out being able to remotely restart & then log in to the Mac?

So far, for me, yes it does 😟 I walked straight into this hassle and could kick myself for not seeing it coming.

I can understand the fundamental problem here... booting from an FDE-enabled Mac drive first involves the Mac booting from the EFI firmware to perform the machine login. Then, and only then, does it go on to boot from the startup disk and configure everything as normal.

Meaning of course, during that initial (firmware) login, with no OS loaded at that point, the Mac's networking is unconfigured and hence inactive, meaning in turn I can't remote to it to enter the login creds. Catch 22! Someone has to be there physically with the machine to do the login, ho ho.

Now, not being able to remotely restart a Mac and THEN log in to carry on working on it is a MAJOR hassle for me - I need to do that loads. And I suspect can be just as awkward for many other business/educational Mac admins out there, especially where remote admin is more needed. Fortunately, some such admins can simply not bother using FDE on the boot drive for that very showstopping reason, lucky them!

But... what about those of us who now have to use FDE on their Macs, like me? I support 20+ Macs and an XServe within a massive corporate enterprise. The company's global policy makers are now insisting that ALL machines (whether PCs, Macs or whatever) that are used to handle or store company data must have full disk encryption running, and all data files placed on fixed & removeable media are encrypted. I believe this strategy is an increasing trend across larger organizations especially, given ever more focus (and some paranoia!) on data security lately.

Sooooo.... on hearing about this unwelcome and sudden need for FDE, I reluctantly decided maybe it's time to consider upgrading all our Macs from SL to Lion, if only to get the FDE feature from Lion. We must have FDE for the Macs, whether it's Apple's or a third party solution for that. Naturally, I'd much prefer to go with the built-in Apple FDE - if I had that choice.

AFAIK there's no way round this roadblock (well, ok, short of elaborate measures like a remote-controlled robot to tap in the login creds!). Maybe there's at least one third party FDE tool wouldn't have the same problem? I don't know yet - I only got as far as trying out the Apple route. Until I was stopped in my tracks.

Or, am I missing a trick? Please, someone tell me what I can do about this situation? But please don't suggest to try getting our policy makers to change their stance on this security rule - no way will that happen. With 100s of 1000s of PCs yet only a handful of Macs in the company, I wouldn't even be heard!

I do about 95% of my Mac admin work remotely. And most of that is done outside office hours, to avoid disruption to users. I frequently schedule the Macs to power themselves on at nights so I can then do maintenance/repair work on them, often needing to do restarts along the way, hence my predicament now 😟

As I write, the test Mac I was upgrading to Lion last night and enabled the FDE on is now sitting there miles away waiting for someone to log in. I can't get anyone to do that for me until they return on Tues from the Easter break, and it's a long way for me to travel to do it myself.

Perhaps what's needed is some sort of change to the EFI firmware, to allow remotely sending the necessary login creds to the boot rom, via some LOM-type alternative connection into the ethernet i/f? Or, get the EFI firmware to also include the config & enabling of the Ethernet and a skinny ARD client? But what are the chances of Apple providing any such solution anyway? Just thinking out loud here...

When Apple announced the death of XServe I was wondering how business users can carry on using Macs for much longer. This latest issue, with FDE, is another nail in the coffin, if not the final one.

Ideas/comments anyone please?

Posted on Apr 7, 2012 10:08 AM

Reply

Answer 1

Apr 7, 2012 10:33 AM in response to TestBeforeSelling

My recommendation here would be to avoid filevault on the boot volume, and instead put sensitive data into encrypted disk images or on secondary hard drives that are encrypted. Perhaps one could rewrite the EFI firmware to store the filevault password or encryption keys and automatically unlock the volume, but this would defeat the purpose of FileVault.

As it stands, if you need to do remote work that requires rebooting then you should not enable FileVault on the boot volume.

Reply

Answer 2

Apr 7, 2012 11:10 AM in response to Topher Kessler

Thanks for your comments. But, as I say, I have to use FDE on the boot volume whether I like it or not, and I have to admin the Macs remotely.

To me it's ridiculous for FDE to impose such a restriction on remote working (or vice versa). Clearly a massive oversight.

More and more remote admins will get hit by this, as and when their organizations insist on ALL drives having FDE as standard, confidential data on them or not, which is where things are heading fast. Our company is not so unusual in that regard, and there will be more to follow.

Reply

Answer 3

Apr 7, 2012 11:25 AM in response to TestBeforeSelling

One option is to get a KVM switch that has remote access capability, such as the following: http://www.rackmountmart.com/rmLCD/lcdK1039.htm

From here you could reboot the system and provide the initial login credentials to unlock the drive via the switch, followed by directly accessing the system via SSH or VNC (or continuing to use th switch).

Reply

Answer 4

Apr 7, 2012 11:39 AM in response to Topher Kessler

I can see that would work thanks, but afraid again it's not an option for me. We're simply not allowed to connect our own networking devices, e.g. switches etc, to the company network. This is normal policy in larger organizations, and understandably so.

It was hard enough getting the Macs themselves to be allowed on the network, and every so often I have to fight to keep it that way.

Reply

Answer 5

Apr 10, 2012 11:12 AM in response to TestBeforeSelling

Just to update after checking out some alternative FDE solutions, I see most of them have taken on board the importance to (and rights of!) admins of being able to remotely reboot the Macs they support. The vendors (e.g. Sophos) provide admins with the means (typically via CLI) to temporarily bypass the inital preboot authentication. Not rocket science of course.

Some would say this approach potentially weakens the security, somewhat defeating the very purpose of FDE. OK, so maybe there is a greater risk in some situations, yet admins are still free to use the feature entirely at their own discretion (and are usually best placed to be aware of the actual conditions they work in).

The important principle to me here is that the paying customers for such software should remain free to choose what they do with the product (short of breaking any licensing rules).

So come on Apple please, let's have solutions that fit real use in the real world! A PBA bypass feature in FV2 would be such a step.

... rant over (and shameless bump!)

Reply

Answer 6

Nov 27, 2012 12:38 PM in response to TestBeforeSelling

Hi TestBeforeSelling,

In 10.8.2, Apple built in the ability to initiate an authorized pre-boot authentication bypass via CLI:

sudo fdesetup authrestart

This essentially allows you to provide credentials for the pre-boot authentication when you're initiating the restart action.

Reply