In this blog post, I will be talking about how smart card logon works, and why I think it is better in terms of security. Smart cards are not a new thing. They appeared long time ago, as a second factor authentication to enhance the overall security. People use smart cards to encrypt information or to for digital signatures. What is interesting though is the ability to log on to a Windows machine using smart cards. After all, smart cards contain digital certificates that are issued by a certificate authority. That certificate authority is supposed to be a trusted service inside the network. Meanwhile, Active Directory is the trusted identity store that manages computer and user accounts, and enable the use of Kerberos to enable secure access to resources.

So the tricky question is how a digital certificate inside a smart card, can authenticate a user during the logon experience, to Active Directory? In other words, how smart card logon works?

In order to understand the terms used in this blog post, let us agree on couple of terms. KDC stands for Key Distribution Service, and it is running on each domain controller. Domain Controllers are the server role that represents Active Directory service. “Active Directory”, “KDC”, and “domain controller”, all mean the same thing.

Kerberos is the authentication protocol when a user log on interactively to a domain joined machine. Each domain joined machine has a secret that is only known to itself and to the KDC. This secret key is used to create a secure channel between the machine and the KDC. This channel is important, because logon requests for users are passed through this channel to the domain controller.

How Normal Password type logon happens ?

I want to give you a brief introduction on how normal logon works using passwords, before jumping to smart card logon.When a user attempts to logon to a workstation, the workstation sends a request to the KDC. KDC generates a TGT (Ticket Granting Ticket) and encrypts it with a key (Ku). This Key (Ku) is derived from the hash of the user password, and only the user and the KDC know about this key. The workstation asks the user for a password, derive the hash of the password to get (Ku) and then decrypt the TGT.

Why Password Logon is not good ?

In this protocol, (Ku) is exposed to two parties, the user and the workstation. A key memorized by the user can be vulnerable because he can tell it to another user or (Shoulder Surf) it when he type it. Further more, her keystrokes may be snooped remotely without her knowledge.

A key in a workstation can be vulnerable if the workstation is not securely protected or cannot be trusted .If someone can scan the entire memory, he can obtain the key. If someone has admin access to the workstation, he can install logon program to store user password.

To solve those issues , it is preferable to decrypt the TGT outside the workstation.Therefore an external encryption device is required. Furthermore , user passwords are weak by nature, and are subjective to dictionary attacks, and can be shared between multiple users.

To overcome those limitations, you can use a smart card logon instead of password logon to better enhance the overall security of your logon experience. In the next section, I will explain how smart card logon works in details.

How Smart Card logon happens ?

In order for smart card logon to work, the domain controller should have a digital certificate by itself. Each domain controller participating in smart card logon, should have a digital certificate on its certificate store. Here is how smart card logon works:

  • If a reader is attached to the user’s machine, the user is prompted to put in a card.
  • Then the user is prompted to enter a pin.
  • The logon request is passed to the Local Security Authority (LSA).
  • LSA communicates with the Kerberos authentication package on the client.
  • Kerberos sends a request to the Kerberos Distribution Center (KDC) on the domain controller for authentication. The request includes a copy of the x.509 certificate (from the smart card) in the pre-authentication data field of the request and is signed by the private key.
  • The KDC builds a certification path from the certificate to a root CA in the system root store.
  • There must be an enterprise Certification Authority (CA, published in Active Directory). This prevents a rogue CA certified in another CA hierarchy from issuing a certificate in the domain.
  • The KDC uses the public key from the certificate to verify the signature.
  • KDC verifies the timestamp is within skew time, the time period during which a request can be processed. This helps to detect a replay attack.
  • KDC looks in the AD for account information.
  • If all tests are passed, the KDC returns a Ticket Granting Ticket (TGT). The KDC provides a copy of its certificate as well and signs the returned information with its private key.
  • The client verifies the KDC by building a certificate path from the certificate to the trusted root CA and uses the KDC public key to verify the reply signature.
  • If all is OK, the normal Kerberos path is followed from here (the TGT is used to get a service ticket and hence to the user’s desktop).