[continued from part I]
Local vs domain logon
In keeping with the Windows example from 2013, this post will also look at local smart-card logon, as opposed to directory based. That is, the credentials on the card correspond to a user account that is defined on the local machine, as opposed to a centralized identity management service such as Active Directory. A directory-based approach would allow similar authentication to any domain-joined machine using a smart-card, while the local case only works for a user account recognized by one machine. For example, it would not be possible to use these credentials to access a remote file-share afterwards, while that would be supported for the AD scenario because the logon in that case results in Kerberos credentials recognized by all other domain participants.
Interestingly that local logon case is natively supported by the remnants of smart-card infrastructure in OS X. By contrast Windows only ships with domain logon, using PKINIT extension to Kerberos. Third-party solutions such as eIDAuthenticate are required to get local scenario working on Windows. (In the same way that Apple can’t seem to grok enterprise requirements, MSFT errs in the other direction of enabling certain functionality only for enterprise. One can imagine a confused program manager in Redmond asking “why would an average user ever want to login with a smart-card?”)
At a high-level there are two pieces to smart-card logon, which is to say authenticating with a digital certificate where the private key happens to reside on a “smart card.” (Increasingly the card is not an actual card but could be a USB token or even virtual-card emulated by the TPM on the local machine.)
- Target machine decides which user account that certificate represents
- The card proves possession of the private-key corresponding to the public-key found in the certificate
The second part is a relatively straightforward cryptographic problem that has many precedents in the literature, including SSH public-key authentication and TLS client authentication. Typically both sides jointly generate a challenge, the card performs a private-key operation using that challenge and machine verifies the result using the public-key. Exact details vary based on key-type and allowed key-usage attributes in the certificate. For example if the certificate had an RSA key, the machine could encrypt some data and ask the card to respond with proof that it can recover the original plaintext. If the certificate instead had an ECDSA key which is only usable for signatures but not encryption (or it has an RSA key but the key-usage constraints on the certificate rule out encryption) the protocol may involve signing a jointly generated challenge.
Tangent: PKINIT in reality
Reality of PKINIT specification is a lot messier— not to mention the quirks of how Windows has implemented it historically. Authentication of user is achieved indirectly in two steps. First client sends the Kerberos domain-controller (KDC) a request signed with its own key-pair, then receives a Kerberos ticket-granting-ticket (TGT) from KDC encoded in one of two different ways:
- Encrypted in the same RSA key used by the client when signing— this was the only option supported in early implementations of PKINIT in Windows
- Using a Diffie-Hellman key exchange, with DH parameter and client input authenticated by the signature sent in the original request
Mapping from any CA
The good news is local logon does not involve a KDC, there is no reason for implementations to worry about idiosyncrasies of RFC4556 or interop with Kerberos. Instead they have a different problem in mapping a certificate to user accounts. This is relatively straightforward in the enterprise: user certificates are issued by an internal certificate authority that is either part of Active Directory domain controller using the certificate services role (in the common case of an all-Windows shop) or some stand-alone internal CA that has been configured for this purpose and marked as trusted by AD. The certificates are based on a fixed template with username encoded in specific X509 fields such as email address or UPN, universal principal name. That takes the guesswork out of deciding which user is involved. The UPN “email@example.com” or that same value in email field unambiguously indicates this is user Alice logging into Acme enterprise domain.
By contrast local smart-card logon is typically designed to work with any existing certificates the user may have, including self-signed ones; this approach might be called “bring-your-own-certificate” or BYOC. No assumptions can be made about the template that certificate follows, other than conforming to X509. It may not have any fields that would allow obvious linking with the local account. For example there may be no UPN and email address might point to Alice’s corporate account, while the machine in question is a stand-alone home PC with personal account nicknamed “sunshine.” Main design challenge then is devising a flexible and secure way to choose which certificates are permitted to login to which account.