Re: [Fed-Talk] [Smart Cards] Tiger Login - DRAFT
Re: [Fed-Talk] [Smart Cards] Tiger Login - DRAFT
- Subject: Re: [Fed-Talk] [Smart Cards] Tiger Login - DRAFT
- From: Shawn Geddis <email@hidden>
- Date: Tue, 14 Feb 2006 08:58:26 -0500
Michael,
On May 24, 2005, at 10:57 AM, Michael Kluskens wrote:
I'm having some issues with CAC and 10.4
I've done testing on OS X 10.4.1 on a standard journaled file
system and on a case-sensitive, journaled file system, with no
apparent difference between them.
The only configuration setup I attempted is in Keychain Access and
that configuration step refuses to "stick" on my machine. (I also
tried sc_auth accept but I get "Access Restricted" and I don't know
what that means).
You are required to have root privileges to run sc_auth, hence the
"access restricted" message when you tried.
OS X Mail works with encryption, decryption, and signing with no
additional configuration.
Precisely the advantage of the abstraction of Smart Cards on Mac OS X
10.4.x...
Safari responds with "The client certificate has been revoked" when
I visit a local PKI enabled site (it's optional for this site
hopefully that is not the cause of the problem). Mozilla also can
not access that site under 10.4 if the CAC is in.
"The client certificate has been revoked" indicates the server
rejected the certificate presented to the website. One new
characteristic of OS X 10.4.4 and later is that the Smart Card will
always appear at the top of the Keychain list and will be the first
credential sent for this kind of event. Previously, if you had
another identity (i.e. VeriSign Cert/Key), that would have been sent
first and then you would have had to choose the Smart Card based
credential when it failed the first time -- adding an Identity
Preference to your Keychain. Starting with 10.4.4 and for those of
you using Smart Cards on a regular basis, you should never have to
deal with that even.
My CAC card reader is a ActivCard reader that was flashed to work
with 10.3 and I have to assume it is working fine since OS X Mail
is fully operational in CAC functions. sc_hash gives the hashes
for all three keys on the CAC.
The flashing was not an issue for 10.3, but rather a major advantage
for working with 10.4.
CCID Compliant readers is definitely the direction to go rather than
having a slew of reader specific drivers hanging out all over the place.
On May 9, 2005, at 2:45 PM, Shawn Geddis wrote:
Smart Cards in "Tiger" - 10.4.x
=====================
Smart Cards (CAC, GSCIS, PIV, JPKI, BELPIC, ....) are all
abstracted as keychains
Can the Smart Card keychain be seen in the "Keychain Access"
application and where? On my machine, the sections labeled "keys"
and "My certificates" are empty.
Keychain Access:
"Keys" - represents "any" keys found in any of your keychains
(credential storage)
"My Certificates" - represents "identities" found among your
keychains. "Identities" means you have both
the Certificate AND the associated Private Key.
** Address Book
Now also displays the "signing" check symbol just left of email
addresses that the user has corresponding Public Cert in their
keychain. The Cert is NOT stored in the keychain, but represents
a relationship with one in one of the currently active keychains.
This works, but I think there is a wording error here, the Cert is
stored in the keychain, it is NOT stored in the Address Book.
The Smart Card _is_ a keychain and hence the Certificates and Keys
displayed are representative of what is in the card. You would not
be able to pull the private key from a Smart Card (if you could that
would be a security issue). So, the "keychain" that is dynamically
added to the keychain list is actually a representation of what is on
the card. That said, for performance reasons, we do cache the public
certificates (since it is public it is not a security issue) within
the tokend cache directory relating to that smart card. For those
interested, look at:
Main Directory: /private/var/db/TokenCache/
directory: config/ -- contains cached config info .. i.e. lastSSID
directory: tokens/ -- a directory for each unique token (i.e.
Smart Card) used on that system
for example:
tokens/com.apple.tokend.cac:CAC-2050-5033-1024-0011-6936/
on my test system it contains:
drwx------ 5 tokend tokend 170 Feb 6 02:40 Cache
-rw-rw-rw- 1 root wheel 13 Feb 6 02:40 PrintName
-rw-rw-rw- 1 root wheel 2 Feb 6 02:40 SSID
drwx------ 2 tokend tokend 68 Feb 6 02:40 Work
The "PrintName" is where the Keychain Name associated with the Smart
Card is cached. If you want to give your Smart Card (as it is
referenced by the Keychain) a different name you can administratively
alter the entry in this file. Be careful _not_ to use some special
characters like a "." period, but you can use dashes and underscores
and spaces. Some might want change the name now from the "smart card
#?" scenario to whatever you want until Apple further refines that
aspect of the Smart Card system to pull unique info from the card.
Fo those who will be quick to quip "Why didn't you just get the info
from the card ?", remember that we support Smart Card types from
around the globe - not just the US Federal Smart Card and almost
every card type is different in how this is done.
"Common Access Card Viewer" functionality is largely now available
since the Smart Cards appear as dynamic keychains. You can view
the Certificate and Key information as well as change the PIN on
the card by selecting the "Change Password for Keychain ...".
This does not work at all for me, the only keychain I have is my
regular software keychain, I see no evidence of the CAC card in
Keychain Access.
If your card does not appear as "smart card #?" then your reader is
not being recognized by the system...
2) The DoD Intermediate CAs are not available to the Keychain List
by default
-- Federal Customers within DoD will need to add the
"X509Certificates" to the list
a) Launch Keychain Access
b) Select "Edit -> Keychain List"
c) Select "Show: Mac OS X (System)"
d) Check "Shared" checkbox next to
"X509Certificates" (/System/Library/Keychains)
e) X509Certificates will now appear in the Keychains
List and will be available for
Intermediates for the whole trust path
validation.
This is what totally fails on my system. First off the check mark
is not there if I immediately or any time afterwards go back into
this menu. Also, I note that I also have System /Library/Keychains
which is shared and X509Anchors /System/Library/Keychains which is
not shared (and not shareable just like X509Certificates). Under
User I also have System /Library/Keychains which is shared.
"Shared" just means it is shared across multiple accounts running on
that same machine. it does not mean they are automatically unlocked
or anything, but that the keychain you mark is automatically made
available in the keychain list to this user and others logged in on
this machine.
The X509Certificates is where Apple has "pre-populated" the DoD (and
a few others) Intermediate Certificates for quick and easy use by DoD
customers. This is not currently enabled by default, but has been
requested by several federal customers. For now, enabling the
X509Certificates by checking the "Shared" checkbox adds this keychain
to the searchable keychains list for this user and others on this
machine.
The X509Anchors keychain is a special one in that it the ONLY
location where Trusted Root CA Certs are stored and trusted
(according to your policy settings) and the X509Anchors is _always_
referenced, since it must be used for full trust path validation.
So, in reference to the X509Anchors, the UI metaphor of the checked/
unchecked "shared" is a bit misleading.
Any anomaly you all experienced back in earlier revs of 10.4.x should
no longer exist. If you do still experience them, please report them
or send me an email message describing your anomalies.
I created a brand new account and the problems existed there as well.
We have pointed a few things out above which should have resolved
those issues for you.
- Shawn
___________________________________________
Shawn Geddis
Security Consulting Engineer
Apple Enterprise Division (Public & Private Sector)
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