Smart-card logon for OS X (part III)


[continued from part II]

Managing the mapping for smart-card logon

OS X supports two options for mapping a certificate to a local user account:

  • Perform look-up in enterprise directory
  • Decide based on hash of the public-key in the certificate

For local login on stand-alone computers without Active Directory or equivalent, only the second, very basic option is available. As described by several sources [Feitian, PIV focused guides, blog posts], sc_auth command in OS X— which is just a Bash script— is used to manage that mapping via various sub-commands. sc_auth hash purports to display keys on currently present smart-cards, but in fact outputs a kitchen sink of certificates including those coming from the local keychain. It can be scoped to  specific key by passing an identifier. For example to get PIV authentication key out of a PIV card when using OpenSC tokend modules:

$ sc_auth hash -k "PIV"
67081F01CB1AAA07EF2B19648D0FD5A89F5FAFB8 PIV AUTH key

The displayed value is a SHA1 hash derived from the public-key. (Keep in mind that key names such “PIV AUTH key” above are manufactured by the tokend middleware; your mileage may vary when using different one.)

To convince OS X into accepting that certificate for local logon, sc_auth accept must be invoked with root privileges.

$ sudo sc_auth accept -u Alice -k "PIV"

This instructs the system to accept the PIV certificate on presently connected smart-card for authenticating local user Alice.  There is another option to specify the key using its hash:

$ sudo sc_auth accept -u Alice -h 67081F01CB1AAA07EF2B19648D0FD5A89F5FAFB8

More than one certificate can be mapped to a single account by repeating that process. sc_auth list will display all currently trusted public-key hashes for a specified user:

$ sc_auth list -u Alice
67081F01CB1AAA07EF2B19648D0FD5A89F5FAFB8

Finally sc_auth remove deletes all certificates currently mapped to a local user account:

$ sudo sc_auth remove -u Alice

Smart-card user experience on OS X

So what does the user experience look like once the mapping is configured?

Initial login

First the bad news: don’t throw away your password just yet. The boot/reboot process remains unchanged. FileVault II full-disk encryption still requires typing in the password to unlock the disk.** Interestingly, its predecessor the original FileVault did support smart-cards because it was decrypting a container in the file-system after enough of the OS had been loaded to support tokend. New variant operates at a much lower level. Because OS X does not ask for the password a second time after the FileVault prompt, there is no opportunity to use smart-card in this scenario.

Good news is that subsequent authentication and screen unlocking can be done using a smart-card. The system recognizes the presence of a card and modifies its UI to switch authentication mode on the fly. For example, here is what the Yosemite login screen usually looks like after signing out:**

Standard login screen

Standard login screen

After a card is connected to the system, the UI updates automatically:

OS X login UI after detecting card presence

OS X login UI after detecting card presence

Local account mapped to the certificate from the card is chosen, and any other  avatars that may have been present disappear from the UI. More subtly the password prompt changes into a PIN prompt. After entering the correct PIN, the system will communicate with the card to verify its possession of the private-key and continue with login as before.

Caveat emptor

  • On failed PIN entry, the system does not display the number of remaining tries left before the card is locked. It is common for card standards to return this information as part of the error; PIV specification specifically mandates that. Windows will display the count after incorrect attempts as a gentle nudge to be careful with next try; a locked card typically requires costly intervention by enterprise IT.
  • After logging in, it is not uncommon to see another prompt coming from the keychain, lest the user is lulled to a false sense of freedom from passwords:
    Screen Shot 2015-02-08 at 20.17.11 Keychain entries previously protected by the password still need to be unlocked using the same credential. If authentication took place using a smart-card, that password is not available after login. So the first application trying to retrieve something out of the key-chain will trigger on-demand collection. (As the dialog from Messages Agent demonstrates, that does not take very long.)

Screen unlock

Unlocking the screen works in a similar fashion, reacting to the presence of a card. Here is example UI when coming out of screen-saver that requires password:

Screen-saver prompting for password

Screen-saver prompting for password

After detecting card presence:

Screen-saver prompting for card PIN

Screen-saver prompting for card PIN

This is arguably the main usability improvement to using smart-cards. Instead of typing a complex passphrase to bring the system out of sleep or unlock after  walking away (responsible individuals lock their screen before leaving their computer unattended, one would hope) one need only type in a short numeric PIN.

[continued]

CP

* In other words OS X places the burden of security on users to choose a random pass-phrase, instead of offloading that problem to specialized hardware. Similarly Apple has never managed to leverage TPMs for disk encryption, despite a half-hearted attempt circa 2006, keeping with the company tradition of failing to grok enterprise technologies.
** MacWorld has a helpful guide for capturing these screenshots, which involve SSH from another machine.

24 thoughts on “Smart-card logon for OS X (part III)

  1. Thanks a lot for this tutorial! Now I’m able to use my work’s smartcard to log into my mac mini.
    One thing though, I have noticed that once you run the “security authorizationdb smartcard enable” command, the lock screen changes to the ugly login/password one and not the slick one with your photo (as the main login UI in the other photos). I have used the disable version of the command and the lock screen still remains at its ugly version. I guess this is a bug. Have you find a way to put the lock screen back to the nice version? I guess there is a preference file to remove somewhere 😉

    • Hello Rafael. I have not run into the situation you describe.
      Could you elaborate? Are you able to login with your smartcard at all? Is this limited to screen unlock only or does it apply on initial login too? (What happens if you log out?)
      There are some restrictions on the certificate that OSX will accept- it has to be pass validation and AFAICT self-signed certificates do not work.

      • Hello Cem. Actually all is working perfectly, I get to login with my smartcard pin from both the initial login and the lock screen.

        My question was more of a cosmetic thing: before activating the smartcard login with the “security” command, the lock screen was similar to the initial one, i.e. my photo and a text box to put the password over the blurred wallpaper. After the command the lock screen became a simple black screen with a window with two text boxes (login/password or login/pin), just like the one in KDE. The initial login screen did not change its look.

        I have searched everywhere for a way to have the lock screen with the nicer wallpaper/photo/password look, but I think this might be just a bug.

    • shirkrin says:

      Hi Rafael, did you manage to restore your lock screen? I’ve been trying (without luck) to get smartcard auth working with a YubiKey NEO and now I’m stuck with an ugly / brocken lock screen even after reverting everything.

      • Hi Shirkrin, nope, I still have the ugly lock screen. I naively thought that it was going to be fixed in El Capitan, but no luck. Maybe it is indeed a feature and not a bug :\.

  2. First of all, thanks for the tutorial.
    I am not able to login, since my system does not detect a smart card insertion. I am able to map local user with the card certificate. Card (with certs) is visible in the Keychain. I can use my certs for document and e-mail signing and encryption. But, when I go to login screen, card is not detected and I always have “Password” dialog. No PIN dialog at all.

    • Hi Again,

      I’ve just noticed that we work for the same company… I guess you are trying to use our blue cards to login, right? I had some problems with the validity of the certificates and that was solved by forcing the trust setting for boot the root and the root CA certificates (in the keychain). If you want, look for me in Lync and I can show you how.

      • Hi,
        the command
        sudo security authorizationdb smartcard enable
        helped me and after that my Mac started to ask for the PIN number whenever the card is inserted.

    • Hello Marko.
      Is the certificate on your card trusted by the system?
      One point that is not mentioned in this tutorial is that OSX must be able to verify the certificate to a trusted root. (In my limited experiments, self-signed certificates did not work even when their trust settings were manually modified to “Always trust” via Keychain app)

    • Hello Vadim.
      I don’t believe it is possible to eliminate that dialog.
      The reason is that your existing keychain with existing secrets (such as saved passwords) is protected by your password. These steps allow logging into OSX without providing your password but then your keychain remains locked.
      (In theory it should be possible to save passwords, keys etc. under the PIV-II keychain present when the card is inserted but I’ve had no luck with this.)
      CP

    • Thank you for pointing that out.
      But in this case it would not allow getting rid of the password right? It would just give you a chance to login with smart-card as a separate step (after entering the password for FV2)

      • That’s correct. Apple would have to significantly re-engineer FV2 and it’s EFI component to allow such a thing. I think the smart card reader and middleware driver vendors would probably also “have kittens” at the thought.

      • richardpurves says:

        Another point to consider, Apple’s new APFS file system. All the CoreStorage work is gonna go out of the window for this. This affects all this because FV2 will probably be replaced with something else. We can hope they allow card auth at EFI boot time!

  3. FYI: OS X 10.11 (El Capitan) and later requires one additional step in order to enable smartcard based login:

    # sudo security authorizationdb smartcard enable

    Without this, the smartcard will not affect the login screen.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s