Chapter 1. Understanding smart card authentication
Authentication based on smart cards is an alternative to passwords. You can store user credentials on a smart card in the form of a private key and a certificate, and special software and hardware is used to access them. Place the smart card into a reader or a USB port and supply the PIN code for the smart card instead of providing your password.
This section describes what a smart card is and how smart card authentication works. It describes the tools that you can use to read and manipulate smart card content. It also provides sample use cases and describes the setup of both the IdM server and IdM client for smart card authentication.
If you want to start to use smart card authentication, see the hardware requirements: Smart Card support in RHEL9.
1.1. What is a smart card
A smart card is a physical device, usually a plastic card with a microprocessor, that can provide personal authentication using certificates stored on the card. Personal authentication means that you can use smart cards in the same way as user passwords.
You can store user credentials on the smart card in the form of a private key and a certificate, and special software and hardware is used to access them. You place the smart card into a reader or a USB socket and supply the PIN code for the smart card instead of providing your password.
1.2. What is smart card authentication
Public-key based authentication and certificate based authentication are two widely used alternatives to password based authentication. Your identity is confirmed by using public and private keys instead of your password. A certificate is an electronic document used to identify an individual, a server, a company, or other entity and to associate that identity with a public key. Like a driver’s license or passport, a certificate provides generally recognized proof of a person’s identity. Public-key cryptography uses certificates to address the problem of impersonation.
In the case of smart card authentication, your user credentials, that is your public and private keys and certificate, are stored on a smart card and can only be used after the smart card is inserted into the reader and a PIN is provided. As you need to possess a physical device, the smart card, and know its PIN, smart card authentication is considered as a type of two factor authentication.
1.2.1. Examples of smart card authentication in IdM
The following examples describe two simple scenarios on how you can use smart cards in IdM.
184.108.40.206. Logging in to your system with a smart card
You can use a smart card to authenticate to a RHEL system as a local user. If your system is configured to enforce smart card login, you are prompted to insert your smart card and enter its PIN and, if that fails, you cannot log in to your system. Alternatively, you can configure your system to authenticate using either smart card authentication or your user name and password. In this case, if you do not have your smart card inserted, you are prompted for your user name and password.
220.127.116.11. Logging in to GDM with lock on removal
You can activate the lock on removal function if you have configured smart card authentication on your RHEL system. If you are logged in to the GNOME Display Manager (GDM) and you remove your smart card, screen lock is enabled and you must reinsert your smart card and authenticate with the PIN to unlock the screen. You cannot use your user name and password to authenticate.
If you are logged in to GDM and you remove your smart card, screen lock is enabled and you must reinsert your smart card and authenticate with the PIN to unlock the screen.
1.3. Smart card authentication options in RHEL
You can configure how you want smart card authentication to work in a particular Identity Management (IdM) client by using the
authselect enable-feature <smartcardoption>. The following smart card options are available:
with-smartcard: Users can authenticate with the user name and password or with their smart card.
with-smartcard-required: Users can authenticate with their smart cards, and password authentication is disabled. You cannot access the system without your smart card. Once you have authenticated with your smart card, you can stay logged in even if your smart card is removed from its reader.Note
with-smartcard-requiredoption only enforces exclusive smart card authentication for login services, such as
gnome-screensaver. For other services, such as
sudofor switching users, smart card authentication is not enforced and if your smart card is not inserted, you are prompted for a password.
with-smartcard-lock-on-removal: Users can authenticate with their smart card. However, if you remove your smart card from its reader, you are automatically locked out of the system. You cannot use password authentication.Note
with-smartcard-lock-on-removaloption only works on systems with the GNOME desktop environment. If you are using a system that is
ttyor console based and you remove your smart card from its reader, you are not automatically locked out of the system.
For more information, see Configuring smart cards using authselect.
1.4. Tools for managing smart cards and their contents
You can use many different tools to manage the keys and certificates stored on your smart cards. You can use these tools to do the following:
- List available smart card readers connected to a system.
- List available smart cards and view their contents.
- Manipulate the smart card content, that is the keys and certificates.
There are many tools that provide similar functionality but some work at different layers of your system. Smart cards are managed on multiple layers by multiple components. On the lower level, the operating system communicates with the smart card reader using the PC/SC protocol, and this communication is handled by the pcsc-lite daemon. The daemon forwards the commands received to the smart card reader typically over USB, which is handled by low-level CCID driver. The PC/SC low level communication is rarely seen on the application level. The main method in RHEL for applications to access smart cards is via a higher level application programming interface (API), the OASIS PKCS#11 API, which abstracts the card communication to specific commands that operate on cryptographic objects, for example, private keys. Smart card vendors provide a shared module, such as an
.so file, which follows the PKCS#11 API and serves as a driver for the smart card.
You can use the following tools to manage your smart cards and their contents:
OpenSC tools: work with the drivers implemented in
- opensc-tool: perform smart card operations.
- pkcs15-tool: manage the PKCS#15 data structures on smart cards, such as listing and reading PINs, keys, and certificates stored on the token.
- pkcs11-tool: manage the PKCS#11 data objects on smart cards, such as listing and reading PINs, keys, and certificates stored on the token.
GnuTLS utils: an API for applications to enable secure communication over the network transport layer, as well as interfaces to access X.509, PKCS#12, OpenPGP, and other structures.
- p11tool: perform operations on PKCS#11 smart cards and security modules.
- certtool: parse and generate X.509 certificates, requests, and private keys.
Network Security Services (NSS) Tools: a set of libraries designed to support the cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards.
- modutil: manage PKCS#11 module information with the security module database.
- certutil: manage keys and certificates in both NSS databases and other NSS tokens.
For more information about using these tools to troubleshoot issues with authenticating using a smart card, see Troubleshooting authentication with smart cards.
1.5. Certificates and smart card authentication
If you use Identity Management (IdM) or Active Directory (AD) to manage identity stores, authentication, policies, and authorization policies in your domain, the certificates used for authentication are generated by IdM or AD, respectively. You can also use certificates provided by an external certificate authority and in this case you must configure Active Directory or IdM to accept certificates from the external provider. If the user is not part of a domain, you can use a certificate generated by a local certificate authority. For details, refer to the following sections:
For a full list of certificates eligible for smart card authentication, see Certificates eligible for smart cards.
1.6. Required steps for smart card authentication in IdM
You must ensure the following steps have been followed before you can authenticate with a smart card in Identity Management (IdM):
- Configure your IdM server for smart card authentication. See Configuring the IdM server for smart card authentication
- Configure your IdM client for smart card authentication. See Configuring the IdM client for smart card authentication
- Add the certificate to the user entry in IdM. See Adding a certificate to a user entry in the IdM Web UI
- Store your keys and certificates on the smart card. See Storing a certificate on a smart card
1.7. Required steps for smart card authentication with certificates issued by Active Directory
You must ensure the following steps have been followed before you can authenticate with a smart card with certificates issued by Active Directory (AD):
- Copy the CA and user certificates from Active Directory to the IdM server and client.
- Configure the IdM server and clients for smart card authentication using ADCS certificates.
- Convert the PFX (PKCS#12) file to be able to store the certificate and private key on the smart card.
- Configure timeouts in the sssd.conf file.
- Create certificate mapping rules for smart card authentication.