[Fed-Talk] Apple Smart Card Setup Guide (was Disabling password login in favor of CAC)
[Fed-Talk] Apple Smart Card Setup Guide (was Disabling password login in favor of CAC)
- Subject: [Fed-Talk] Apple Smart Card Setup Guide (was Disabling password login in favor of CAC)
- From: Paul Nelson <email@hidden>
- Date: Mon, 28 Aug 2006 19:11:02 -0500
- Thread-topic: Apple Smart Card Setup Guide (was Disabling password login in favor of CAC)
I think there are fundamental problems with Apple's CAC login guide. The
following is based on my own testing. The guide I am referring to is titled
"Smart Card Setup Guide" and I think it is dated 7/20/2006. I did my tests
with Mac OS X 10.4.7
Following the guide directions for CAC without understanding them could make
your computer less secure that just using passwords.
Here is my analysis:
1) Apple doesn't actually use PKI to verify identity. It only uses the
public key hash. This approach assumes that no other certificate can be
made that has the same public key hash. If a completely different smart
card can have a certificate placed on it with a matching public key hash,
the Mac will accept it as authoritative since it only looks for a user
account with a matching pubkeyhash attribute.
If you choose the directory attribute method described in Apple's guide,
things actually get worse. Instead of matching a public key hash, a system
is configured to match some info extracted from the certificate on the smart
card. This is much easier to spoof that a public key hash. For example, if
I based my CAC login on the directions in the guide, I would match up my
user account with the NT Principal Name attribute from a certificate. All I
need to do is generate a certificate with the NT Principal Name extension
and install that cert on a CAC like smart card (from Active Identity). Now
I have a spoofed CAC that I know the PIN for. When I insert it, I will get
logged in as the user that matches the NT Principal Name.
Unfortunately, Apple says that Attribute lookup is "required for all U.S.
Federal Government smart cards." (pg 11)
2) A PIN only protects the use of the private keys on the CAC, and those
keys are not used in Apple's smart card login scheme. If PKI were used,
some arbitrary data would be encrypted using the smart card private key, and
then decrypted using a certificate stored with the user's account info. If
this were done, then the system has shown that the private key was in the
users' possession. Throw in some trust and certificate revocation checks,
and you've got something that provides much stronger assurance that the user
has the right smart card, and has not spoofed one.
3) Apple's login software (smartcard-sniffer) does not do a certificate
status check on the smart card certificate to see if the certificate is
trusted by the local system. This means that the certificate does not have
to be trusted by the local Macintosh to be used for login. There is no
mention of installing root and intermediate certs in the Keychain in Apple's
login guide. I've tested to make sure no DoD certs were trusted (or even
installed) on a Mac, and login was still allowed using a CAC. If trust
checks were enforced, it would be much more difficult to spoof a user, since
the spoofed certificate would have to have been generated by a certificate
authority trusted by the Mac.
4) sc_auth does not work on Intel Macs. This is a known problem. You might
want to refer here for a workaround:
http://www.nabble.com/Tokend-on-Mac-OS-X-(Intel)-t2085561.html
To prevent logging in with a password, the administrator should set up an
account to use a smart card, then change the account password to something
that no one knows. This is how Microsoft's Active Directory "Require smart
card for login" works. When you removed the shadowhash attribute, you
basically did the same thing.
sudo is going to be a problem for users in the military. I don't see this
getting solved right away. Our CAC login stuff doesn't do this either. We
should be able to handle this in a graphical environment using the
authorization framework to run privileged code. We are looking into a
replacement for sudo that works in an ssh session as well.
What directory service are you using to manage user identity? I'm not sure
you meet any DoD CAC login requirements by just using a local account. Does
anyone know if this is true?
Paul Nelson
Thursby Software Systems, Inc.
on 8/28/06 4:43 PM, email@hidden at email@hidden wrote:
> Hi all,
>
> I'm working on implementing CAC logins on the Macs in my department. I've
> followed the smart card setup guide and am able to log onto my machine
> with my CAC. If I don't put my CAC into the reader, though, I can still
> log in with my password...this is not acceptable because it completely
> defeats the purpose of requiring CAC logins. I was able to make the
> system not accept my password by deleting the ShadowHash entry under
> authentication_authority for my account name in NetInfo Manager. With
> that item deleted and the CAC out of the reader, I am still able to input
> a username and password but the password is no longer accepted and I can
> only log in with a CAC and PIN. However, I am now unable to perform any
> commands using sudo with either my password or CAC PIN.
>
> So...what I need is a way to ONLY accept CAC logins but still have access
> to the sudo functionality on the commandline. I've exhausted my list of
> Google search terms without finding any way of doing this. Any help would
> be very much appreciated!
>
> TIA,
> Eric
> _______________________________________________
> 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