[SmartcardServices-Users] Storing Keychain data

[Paul Nelson]

The main reason is so you can use it to log into web servers that require two factor authentication.  Smart cards are mainly used in the industry to store a X509 cert plus the private key that goes with it.  The combination of these provides you with a "digital identity" that has advantages over using a password.

Two browsers for the Mac can make use of these:  Safari and Chrome.

I think that you would be fine if you simply change your login keychain password to match the PIN on your smart card, then think of your smart card as physical key that you can't make a copy of and give to someone else.
Be aware that you will probably make the password for your login keychain weaker by doing this.  Apple has some hooks to encrypt and decrypt your login keychain, but they are very obscure and I don't think they work with a master key in case your smart card is destroyed.

The infrastructure on a Mac is still not ready to do much more that this.

Paul Nelson
Thursby Software Systems, Inc.

On Feb 29, 2012, at 11:33 AM, SB Tech wrote:

> I assume you're referring to the following line:
> 
> > They can be treated as other keychains on the
> > user’s computer, with the limitation that users can’t add other secure
> > objects.
> 
> I would respond: what's the point of adding the Smart Card to keychain access if it cannot store Keychain Access-recognized objects?  Because it seemed such a ludicrous thing to implement, I assumed that, "can’t add other secure objects," simply referred to Keychain Access.  I presumed that it might be possible to add Keychain Access-compatible objects using another method.
> 
> I'm a lay user, considering Smart Cards for a SOHO, not a government IT professional.  Clearly I'm missing some vital reason why the Smart Card should show up as a Dynamic Keychain.  I'd be grateful if someone could explain this to me.
> 
> S.
> 
> On 29 February 2012 17:17, Miller, Timothy J. <tmiller at mitre.org> wrote:
> You initially asked:
> 
> >>> So, my question is: how does one go about using a Smart Card to store
> >>> Keychain Access-specific data, so that the Smart Card "dynamic
> >>> keychain" can more fully perform the functions required on login?
> 
> Per the document you quote, this is not permitted for smartcard-based keychains.
> 
> So now I'm confused what you're actually asking.  You're observing the documented behavior, so what's the problem?
> 
> -- T
> 
> On Feb 29, 2012, at 11:09 AM, SB Tech wrote:
> 
> > If you don't mind, I'm going to quote from Apple's "Mac OS X Security
> > Configuration For Mac OS X Version 10.6 Snow Leopard" document:
> >
> > "Snow Leopard integrates support for hardware-based smart cards as
> > dynamic keychains where any application using keychains can access
> > that smart card. A smart card can be thought of as a portable
> > protected keychain.
> > Smart cards are seen by the operating system as dynamic keychains and
> > are added to the top of the Keychain Access list. They are the first
> > searched in the list. They can be treated as other keychains on the
> > user’s computer, with the limitation that users can’t add other secure
> > objects.
> > When you attach a supported smart card to your computer, it appears in
> > Keychain Access. If multiple smart cards are attached to your
> > computer, they appear at the top of the keychain list alphabetically
> > as separate keychains." (p.136)
> >
> > This encouraged me to believe that the behaviour I was seeing,
> > regarding my Smart Card displacing my Login keychain, was both normal
> > and expected behaviour.  So, how exactly does your Smart Card interact
> > with Keychain Access?  Does it appear at all in the list of Keychains?
> > If not, perhaps there's a low-level setting I can toggle to prevent
> > it appearing.
> >
> > S.
> >
> > On 29 February 2012 13:24, Miller, Timothy J. <tmiller at mitre.org> wrote:
> >> I'm thinking there must be something peculiar about the tokend or card you're using, because I've been using smart cards through CDSA for years without this particular problem arising.
> >>
> >> Unless you're using a stored-value card, you're not going to be able to update data on a smart card.  That's usually reserved for the token manager, since mucking with card data is inherently a security critical operation.  Stored-value cards aren't the best idea for the same reason.
> >>
> >> -- T
> >>
> >> On Feb 18, 2012, at 1:05 PM, SB Tech wrote:
> >>
> >>> Hi,
> >>>
> >>> I looked into using a Smart Card for authentication purposes in my
> >>> SOHO, but came away disappointed by its interaction with Keychain
> >>> Access.  Specifically, because it took the top position in the
> >>> Keychain list, it assumed the Login keychain's duties; but because I
> >>> was unable to store passwords directly on the Smart Card (eg. wifi
> >>> passwords) I found myself having to authenticate a second time, to the
> >>> Login keychain.  In the meantime, there was no automatic
> >>> authentication of login services such as connecting to wifi or
> >>> mounting of secure disk images.
> >>>
> >>> So, my question is: how does one go about using a Smart Card to store
> >>> Keychain Access-specific data, so that the Smart Card "dynamic
> >>> keychain" can more fully perform the functions required on login?
> >>>
> >>> At the moment, I'm not concerned with any particular Smart Card or
> >>> software solution, I'm more interested in knowing whether it's
> >>> actually possible.
> >>>
> >>> Regards.
> >>> _______________________________________________
> >>> SmartcardServices-Users mailing list
> >>> SmartcardServices-Users at lists.macosforge.org
> >>> http://lists.macosforge.org/mailman/listinfo.cgi/smartcardservices-users
> >>
> 
> 
> _______________________________________________
> SmartcardServices-Users mailing list
> SmartcardServices-Users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/smartcardservices-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/smartcardservices-users/attachments/20120229/78fe325c/attachment.html>