Re: [Fed-Talk] FileVault 2.0 + CAC card
Re: [Fed-Talk] FileVault 2.0 + CAC card
- Subject: Re: [Fed-Talk] FileVault 2.0 + CAC card
- From: "Miller, Timothy J." <email@hidden>
- Date: Wed, 12 Sep 2012 17:19:49 +0000
- Thread-topic: [Fed-Talk] FileVault 2.0 + CAC card
All FDE solutions are fundamentally the same. A "pre-boot environment" is
just an alternative OS to which the ROM boot loader transfers control, and
which itself loads and transfer to the "real" OS assuming certain
conditions are met. This environment is not constrained by EFI; it is a
complete OS and has the same access to devices as OS X does.
The pre-boot environment is only constrained by the desire to keep it
small and so limit the need for development. Driving smart cards brings
in a plethora of standards that increases the development requirements,
and so need a substantial business case. As a result, dedicated FDE
vendors have a stronger incentive here than OS vendors, simply because
most of the OS vendors users will never use the feature. Even MS doesn't
support smart cards in BitLocker's pre-boot OS.
-- T
On 9/12/12 10:10 AM, "Link, Peter R." <email@hidden> wrote:
>
>
>
>Jim,
>I don't believe it is a limitation of EFI, just a limitation of Apple's
>implementation. If I read the following WinMagic article correctly, DoD
>has CAC access at the pre-boot stage for Windows
> systems (current users correct me if/when I'm wrong). WinMagic is using
>the same EFI for their product as Apple is using in FileVault-2. I use
>WinMagic's SecureDoc for Mac (SDM) with a Seagate SED and there's a
>limited amount of things we can do to alter the
> pre-boot procedure but there's a lot of things WinMagic can do. I
>believe SDM is now using a small Linux boot OS for the pre-boot sequence.
>This is loaded in EFI or at least accessed by the EFI boot sequence. For
>CAC access, it sounds like there's enough of
> an environment to handle CAC access so if Apple, or some other vendor,
>wanted to try and duplicate WinMagic's process, it seems like it could be
>done. Of course, for Apple to do it, they would need a ton of
>justification to even think about it.*
>I respectably disagree with Shawn's alternative to use the legacy version
>of FileVault for two reasons: 1) that version might not be FIPS 140-2
>validated much longer or even supported in newer
> OSes, and 2) it doesn't provide the same amount of protection as
>FileVault-2 does (which is real close to being validated under FIPS
>140-2).
>
>
>http://www.winmagic.com/market-segment/government/dod-cac-card
>
>
>
>
>*I'm not bitter, I'm just fighting a losing battle getting Apple to fix
>Lion/ML Mail to work with encryption certificates loaded on an external
>LDAP server. This worked in 10.6 but was removed from Lion and isn't
>going back in unless enough people complain
> about it. Yes, I have a bug report and, yes, Apple has responded but has
>said I'm the only one asking for this capability. I'm not trying to take
>anything away from the original thread but Apple can do just about
>anything you want as long as they see a reason
> to do it.
>
>On Sep 12, 2012, at 7:48 AM, Jim Thomas <email@hidden> wrote:
>
>
>Though it does not happen often, I am willing to admit that I am a
>fallible human being, and can be wrong from time to time.
>
>I was wrong.
>
>My initial statements were based on half experience, half anecdotal
>information, so I had to set up a test environment with a 10.8 Mac to
>confirm or deny the capability. Though you can add a Mobile Account in
>the FV2 Pref Pane, it is only capable of taking
> a password for the user in order to add it in the first place. Once
>added, as Mr. Geddis alluded, the boot login dialog can also only work
>with password, and doesn't allow for two-factor at all.
>
>The section to which he referred:
>----------------------------------------
>At this very early stage of the boot phase, none of the OS-reliant
>services are able to load because they¹re dependent on the OS running.
>This means that alternative authentication mechanisms other than
>password-based authentication aren¹t supported at this
> time.
>
>Any support for additional two-factor authentication mechanisms, such as
>smart cards or one-time passwords (OTP), requires further development of
>those services in the highly restricted space and execution of EFI. If an
>organization needs to use smart cards
> for authenticating and unlocking access to encrypted storage, use of
>container-based Legacy FileVault should be examined more closely.
>
>More information about Legacy FileVault and its support for smart cards
>can be found by searching
>http://www.apple.com/support.
>----------------------------------------
>
>At this point, it sounds like a limitation of the EFI, but one that Apple
>is fully aware of.
>
>That said, I do know that a Mobile Account with a password can indeed be
>set to unlock the disk, as I have tested that myself on my own machine.
>
>I apologize for any confusion caused by an incomplete test on my part,
>but hope that it is fully understandable now.
>
>---Jim
>
>
>
>On 9/11/12 10:05 AM, Shawn Geddis wrote:
>
>
>"Reading is Fundamental" ...
>
>
>Section: "Two-Factor Authentication" pg 39...
>
>
>
>From: Shawn Geddis <email@hidden>
>
>Subject: [Fed-Talk] [Posted] Best Practices for Deploying FileVault 2
>
>Date: August 29, 2012 1:15:12 PM EDT
>
>To: Fed Talk <email@hidden>
>
>
>
>
>Fed-Talk Community,
>
>
>
>
>Those of you that have been asking for a whitepaper on Deploying and
>Understanding FileVault 2 can now grab a fresh copy of the 1.0 version
>from the Apple Training and Certification website for OS X and OS X
>Server.
>
>
>
>
>Training OS X:http://training.apple.com/osx
>
>
>
>
>Best Practices for Deploying FileVault 2
>
>
>
>
>
>
>
>
>
>
>
>- Shawn
>________________________________________
>Shawn Geddis
>Security Consulting Engineer
>Apple Enterprise Division
>
>
>
> _______________________________________________
>Do not post admin requests to the list. They will be ignored.
>Fed-talk mailing list (email@hidden)
>Help/Unsubscribe/Update your Subscription:
>
>This email sent to email@hidden
>
>
>
>_______________________________________________
>Do not post admin requests to the list. They will be ignored.
>Fed-talk mailing list (email@hidden)
>Help/Unsubscribe/Update your Subscription:
>
>This email sent to email@hidden
>
>
>
>
>Peter Link
>Cyber Security Analyst
>Cyber Security Program
>Lawrence Livermore National Laboratory
>PO Box 808, L-315
>Livermore, CA 94551-0808
>email@hidden
>
>
>
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden