Re: [Fed-Talk] Apple Smart Card Setup Guide (was Disabling password login in favor of CAC)
Re: [Fed-Talk] Apple Smart Card Setup Guide (was Disabling password login in favor of CAC)
- Subject: Re: [Fed-Talk] Apple Smart Card Setup Guide (was Disabling password login in favor of CAC)
- From: "Timothy J. Miller" <email@hidden>
- Date: Tue, 29 Aug 2006 10:00:39 -0500
Paul Nelson wrote:
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.
This is fine. A private key challenge *is* performed, and my
back-o'-the-envelope calculations suggest that you'd need to generate on
the order of 2^505 RSA1024 bit keys in order to get a 50% chance of a
collision. This is a classic birthday attack, and assumes that you want
to collide *any two* keys.
If you want to collide a *given single key*, the number of keys you'd
have to generate is much, much higher. Like around 2^1010.
That's keys--what about hashes? SHA-1 is 160 bits long. You need to
generate 2^80 texts in order to have a 50% chance of any *two* text
hashes colliding. Recent attacks on SHA-1 have reduced this to around
2^60. But that's still a collision of any *two* random texts. To
collide a *given* text--like a cert or a key--is again much higher:
around 2^120. (The SHA-1 attack described last week on generating
meaningful SHA-1 collisions are inapplicable to certificates as they
relied on adding *invisible*, *unstructured* data to a text in order to
collide the hashes; you can't do this with structured texts like X.509
certificates.)
Using hashes in this manner is a variant of a trust model called "key
continuity management," and is quite secure when implemented properly
(in this case, ensuring that the account store of public key hashes are
1) entered correctly initially, 2) unmodifiable except by trusted
parties, and 3) only modified when the actual user's key changes; in a
managed environment these are relatively easy to meet).
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.
This is incorrect. After PIN entry, a private key challenge is performed.
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.
Authentication with PKI is a one step process: verify that the user
possesses the private key corresponding to the certificate presented.
Authorization is a different problem. There are lots of ways to
approach authorization, which include mapping the whole cert against the
account store (which is what you're describing), or by mapping data
extracted from the cert (public key hash, account name, etc.) against
the account store.
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.
That's because they're already installed in the system X509Anchors and
X509Certificates keychains. Apple's been including the DoD CAs since
Jaguar.
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.
My last testing on this contradicts yours. I specifically tested
certificate chaining and observed it working correctly; if the
authorities were not installed in X509Anchors & X509Certificates, users
could not authenticate.
I'll retest when I get some free time.
*Revocation* checking...now *there* was a problem. But that's partly a
network architecture thing.
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?
JTF-GNO CTO 06-02 doesn't get that specific. The AF PKI SPO taking the
tack that CAC enabled local login is sufficient if nothing else is
possible or practical in a given environment. This covers OS X (for
now, but we don't have a lot of these) and Linux (which I have working
using CoolKey from RHFC5, pcscd and pam_pkcs11).
-- Tim
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
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