Die Smartcard hat in den vergangenen 20 Jahren die Welt erobert: Von Bankkarten, über Kundenkarten, Mitgliedkarten, Zutrittskarten und in der IT für die Speicherung von Zertifikaten. Besonders kritische Geräte werden seit vielen Jahren mit Smartcards für die Verschlüsselung und Benutzeridentifizierung geschützt. Windows Nutzer können eine Vielzahl an von Microsoft unterstützten Smartcards für die Windows Anmeldung nutzen, jedoch ist die Nutzer von Verschlüsselung oder Benutzeridentifizierung mit Zertifikaten und Smartcards unter Linux nur wenig verbreitet.
Zwei-Faktoren Authentifizierung (auch 2FA, Multi-Faktor Authentisierung, oder starke Benutzeridentifizierung genannt) hilft bei der Complianceerfüllung und ist zertifizierten Umgebungen oft von den Regulatorien oder Auditoren gefordert.
Dieser Artikel beschreibt in einfachen Schritten die Installation und Nutzung von Smartcards als Zwei-Faktoren Authentifizierung (auch 2FA oder Multi-Faktor Authentisierung genannt) mit dem aktuellen (Stand August 2019) Ubuntu Desktop 19.04 für die wichtigsten Login-Anwendungsfälle.
Die Installation der Smartcard Treiber und des 2FA PAM Moduls
Die Installation des benötigten Authentisierungsmoduls unter Linux ist einfach, da es direkt über die Ubuntu Distributionsquelle installiert werden kann. Vor der Installation von opensc und libpam-pkcs11 empfiehlt es sich das System mit “sudo apt upgrade” zu aktualisieren.
Bei der Installation von opensc und libpam-pkcs11 werden einige Packages zusätzlich installiert, da die Installation vollautomatisch und problemlos erfolgt verzichte ich hier auf die Analyse der Softwarekomponenten.
$ sudo apt install opensc
…
$ sudo apt install libpam-pkcs11
…
Die Smartcard Reader Treiber und die Smartcard Middleware sowie das PAM Authentisierungsmodul für Linux sind nun installiert. Jedoch muss die Zwei-Faktoren Methode am System aktiviert werden, indem die Linux PAM Konfiguration für die Nutzung der Smartcard 2FA angepasst wird.
Aktivierung des der Smartcard 2FA Konfiguration
Im ersten Schritt müssen wir prüfen, ob der Smartcard-Reader über die Linux PC/SC Schnittstelle erkannt wird. Dazu benutzen wir das opensc-tool mit der Option “-l” (klein L).
$ opensc-tool ‑l
# Detected readers (pcsc)
Nr. Card Features Name
0 Yes OMNIKEY CardMan 5321 00 00
In meiner Testumgebung habe ich einen OMNIKEY CardMan 5321 (einen großen Bruder vom sehr weit verbreiteten OMNIKEY CardMan 3121) über USB verbunden.
Mit dem nächsten Befehl listen wir die Smartcard Treiber, die in der installierten Version von OpenSC verfügbar sind:
$ opensc-tool ‑D
Configured card drivers:
cardos Siemens CardOS
flex Schlumberger Multiflex/Cryptoflex
cyberflex Schlumberger Cyberflex
gpk Gemplus GPK
gemsafeV1 Gemalto GemSafe V1 applet
asepcos Athena ASEPCOS
starcos STARCOS
tcos TCOS 3.0
oberthur Oberthur AuthentIC.v2/CosmopolIC.v4
authentic Oberthur AuthentIC v3.1
iasecc IAS-ECC
belpic Belpic cards
incrypto34 Incard Incripto34
acos5 ACS ACOS5 card
akis TUBITAK UEKAE AKIS
entersafe entersafe
epass2003 epass2003
rutoken Rutoken driver
rutoken_ecp Rutoken ECP driver
myeid MyEID cards with PKCS#15 applet
dnie DNIe: Spanish eID card
MaskTech MaskTech Smart Card
atrust-acos A‑Trust ACOS cards
westcos WESTCOS compatible cards
muscle MuscleApplet
sc-hsm SmartCard-HSM
mcrd MICARDO 2.1 / EstEID 1.0 — 3.5
setcos Setec cards
PIV-II Personal Identity Verification Card
cac Common Access Card (CAC)
itacns Italian CNS
isoApplet Javacard with IsoApplet
gids GIDS Smart Card
openpgp OpenPGP card
jpki JPKI(Japanese Individual Number Cards)
coolkey COOLKEY
npa German ID card (neuer Personalausweis, nPA)
default Default driver for unknown cards
In Folge werde ich den fett markierten GIDS Smart Card Treiber nutzen, da ich ein GIDS 1.2 Smartcard als Testkarte habe.
Im nächsten Schritt greifen wir über das pkcs11-tool auf die Smartcard zu. Zuerst prüfen wir ob die Smartcard Treiber funktionieren:
$ pkcs11-tool ‑L
Available slots:
Slot 0 (0x0): OMNIKEY CardMan 5321 00 00
token label : UserPIN (GIDS card)
token manufacturer : www.mysmartlogon.com
token model : PKCS#15 emulated
token flags : login required, token initialized, PIN initialized
hardware version : 0.0
firmware version : 0.0
serial num : 96f9503d220b0bd8
pin min/max : 4/15
Perfekt! Über den OMNIKEY CardMan 5321 wird eine GIDS Smartcard angezeigt, die aber mit einer UserPIN geschützt ist. Die anderen Informationen sind Statusinformationen der Smartcard, wie z.B. die erlaubte PIN (vergleichbar mit einem Passwort) Länge von mindestens 4 Zeichen und maximal 15 Zeichen.
Jetzt wo wir wissen, dass die Smartcard ansprechbar ist nutzen wir das pkcs11-tool mit “-O” (das Zeichen O nicht Null) zusammen mit “-l” (klein L) um die Objekte aufzulisten und zuvor einen login über die UserPIN durchzuführen.
aschuster@ubuntudesktop1904:~$ pkcs11-tool ‑O ‑l
Using slot 0 with a present token (0x0)
Logging in to “UserPIN (GIDS card)”.
Please enter User PIN:
Private Key Object; RSA
label: certgate demo-55a5094d-4207–43d2–43687
ID: 00
Usage: decrypt, sign
Public Key Object; RSA 2048 bits
label: certgate demo-55a5094d-4207–43d2–43687
ID: 00
Usage: encrypt, verify
Certificate Object; type = X.509 cert
label: certgate demo-55a5094d-4207–43d2–43687
subject: DN: DC=local, DC=certgate, OU=certgate-user, OU=Entwicklung, CN=certgate demo/emailAddress=certgate-DEMO@certgate.com
ID: 00
Es befinden sich drei Objekte auf der Smartcard:
- ein RSA 2048-Bit privater Schlüssel (Private Key)
- der zu passende RSA 2048-Bit öffentliche Schlüssel (Public Key)
- das X.509 Zertifikat mit dem Label “certgate demo-55a5094d-4207–43d2–43687”
Für unsere weitere Konfiguration ist der CN im “Subject” des Zertifikates wichtig. In diesem X.509 Zertifikat lautet der CN “certgate demo”.
Die Konfiguration des PKCS#11 PAM Moduls erfolgt in der Konfigurationsdatei pam_pkcs11.conf im Verzeichnis /etc/pam_pkcs11.
Hier die Konfiguration als Text und als Screenshot:
$ cat /etc/pam_pkcs11/pam_pkcs11.conf
pam_pkcs11 {
nullok = true;
debug = false;
use_first_pass = false;
try_first_pass = false;
use_authtok = false;
use_pkcs11_module = opensc;
pkcs11_module opensc {
module = /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so;
slot_description = “none”;
ca_dir = /etc/pam_pkcs11/cacerts;
crl_dir = /etc/pam_pkcs11/crls;
support_threads = false;
cert_policy = none;
token_type = “Smart card”;
}
use_mappers = cn, null;
mapper_search_path = /lib/pam_pkcs11;
mapper null {
debug = false;
module = internal ;
default_match = false;
default_user = nobody ;
}
mapper cn {
debug = false;
module = internal;
ignorecase = true;
mapfile = file:///etc/pam_pkcs11/cn_map;
}
}
Besonders erwähnenswert sind die Einträge “use_pkcs11_module = opensc;” dieser verweist auf den Abschnitt darunter wo das Software-Modul “module = /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so;” definiert wird.
In diesem Beispiel schalten wir mit “cert_policy = none;” die CRL und CA Zertifikatsketten-Prüfung ab. Dies wird man in produktiven Umgebungen natürlich nicht so konfigurieren, sondern eine zumindest zweistufige CA mit CRL-Prüfung nutzen.
Der wichtige Eintrag “use_mappers = cn, null;” verweist direkt auf den unten konfigurierten Mapper “mapper cn”. Dort definieren wir in einfachster Weise eine Mapping-Datei, die einzelne Zertifikate den Benutzer-Accounts zuweist. Auch hier wird es in größeren Produktivumgebungen einen Automatismus geben, der eine automatische Zuweisung von ausgestellten CA Zertifikaten auf zentral definierte Benutzeraccounts ermöglicht.
Nun müssen wir noch das Zertifikat dem Benutzer zuweisen, dies erfolgt in der Datei “cn_map” im Verzeichnis “/etc/pam_pkcs11”.
$ cat cn_map
certgate demo -> aschuster
Er Eintrag “certgate demo” bezieht sich auf den CN Eintrag im X.509 Zertifikat, der Eintrag “aschuster” auf die Benutzer-ID in der Datei /etc/passwd .
Das Linux Konfiguration ist nun für 2FA mit einer OpenSC unterstützen Smartcard vorbereitet. Nun muss der Linux Login Prozess um die Zwei-Faktoren-Authentisierung erweitert werden.
Linux PAM Konfiguration
Die PAM Konfiguration erfolgt in den Dateien im Verzeichnis /etc/pam.d
Hier gibt es verschiedene Konfigurationsdateien für den Consolen Login (Datei: login) und für die grafische Linux GUI (Datei: gdm-password).
Zwei-Faktoren Benutzeridentifizierung für Linux Consolen Login
Um die Smartcard 2FA für das Linux Consolen Login (Text-Screen direkt auf dem Client oder dem Server) zu aktivieren, ändern Sie die Datei /etc/pam.d/login als root Benutzer entsprechend dem folgenden Beispiel:
#The PAM configuration file for the Shadow ‘login’ service
auth optional pam_faildelay.so delay=3000000
auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so
auth requisite pam_nologin.so
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
session required pam_loginuid.so
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
#parsing /etc/environment needs “readenv=1”
session required pam_env.so readenv=1
session required pam_env.so readenv=1 envfile=/etc/default/locale
#Standard Un*x authentication.
@include common-auth
session optional pam_motd.so noupdate
#MODIFICATION: required for Smartcard 2FA
auth required pam_pkcs11.so
#This allows certain extra groups to be granted to a user
auth optional pam_group.so
#Sets up user limits according to /etc/security/limits.conf
session required pam_limits.so
#Prints the last login info upon successful login
session optional pam_lastlog.so
#Prints the message of the day upon successful login.
session optional pam_motd.so motd=/run/motd.dynamic
session optional pam_motd.so noupdate
#
session optional pam_mail.so standard
#Create a new session keyring.
session optional pam_keyinit.so force revoke
#Standard Un*x account and session
@include common-account
@include common-session
@include common-password
Zwei-Faktoren Benutzeridentifizierung für Linux GUI (GDM Oberfläche)
Um die Smartcard 2FA für den Ubuntu Window-Manager GDM zu aktivieren, ändern Sie die Datei /etc/pam.d/gdm-password als root Benutzer entsprechend dem folgenden Beispiel:
#%PAM‑1.0
auth requisite pam_nologin.so
auth required pam_succeed_if.so user != root quiet_success
@include common-auth
#Required for Smartcard 2FA
auth required pam_pkcs11.so
auth optional pam_gnome_keyring.so
@include common-account
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
session required pam_loginuid.so
session [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
session optional pam_keyinit.so force revoke
session required pam_limits.so
session required pam_env.so readenv=1
session required pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale
@include common-session
session optional pam_gnome_keyring.so auto_start
@include common-password
Zwei-Faktoren Benutzeridentifizierung für Remote Zugriff per SSH
Der Remote Zugriff per SSH auf ein entferntes System funktioniert nicht über das Linux PAM Moduls des Zielsystems, da der Benutzer, der sich per SSH an einem Zielsystem anmeldet, seinen Smartcard Reader ja nicht am Zielsystem verbunden hat, sondern an seinem lokalen Client.
SSHD unterstützt jedoch die Anmeldung mit Zertifikaten, egal ob das zugreifende lokale System ein Linux oder Windows-Client ist. Ein funktionierendes Beispiel für SSH finden Sie unter dem Link https://help.ubuntu.com/community/SSH/OpenSSH/Keys . Natürlich entfällt das Erstellen von privaten/public Key bei einer CA / Smartcard Infrastruktur, da die Benutzer ihr Schlüsselmaterial ja von der CA Stelle erhalten.
Der Linux GUI 2FA Login
Der Linux Consolen 2FA Login
Google Authenticator Sicherheitsüberlegungen
Aufgrund der FIPS und EAL 4 / EAL 5 zertifizierten Smartcards und Token die bei einer Smartcard Zwei-Faktoren-Benutzeridentifizierung eingesetzt werden sind die privaten Schlüssel der Multi-Faktor Authentifizierung optimal geschützt. Wichtig ist natürlich ein sicherer Betrieb der Zertifikatsausgabesteller der CA, damit sichergestellt wird, dass nur berechtigte Benutzer ein passendes X.509 Zertifikat und ein Schlüssel-Material bekommen.
Der Vorteil einer Smartcard Authentisierung ist, dass diese 2FA Methode sowohl im Offline-Modus als auch im Online-Modus eines Clients funktionieren. Im Offline-Modus muss man zuvor synchronisierte CRL Listen für die Zertifikatsprüfung nutzen, um Online-Modus kann man auch die moderne OCSP Zertifikatsprüfung über ein Netzwerkprotokoll verwenden.
Folgende Angriffsmethoden sind bei Smartcards unterbunden:
Unautorisierte Nutzung der PKI Schüssel
Die Smartcard ist mit einer UserPIN geschützt, diese UserPIN ist nur dem autorisierten Benutzer bekannt und kann nur von dem autorisierten Benutzer geändert werden. Das zertifizierte Smartcard Betriebssystem schützt diesen vertraulichen UserPIN.
Erstellung einer Kopie (oder Export) des privaten Schlüssels
Der private Schlüssel kann von einer Smartcard nicht kopiert werden, der Schlüssel wird i.d.R. auch direkt auf der Smartcard erstellt, daher existiert keine Kopie des vertraulichen Schlüssels.
Brute-Force Angriff
Das Smartcard-Betriebssystem sperrt die Smartcard nach einer definierbaren Anzahl an Fehlversuchen der UserPIN. Typischerweise ist diese Anzahl an Zugriffsversuchen auf einen Wert zwischen 5 und 10 eingestellt.
[…] Zurück […]
also smartcard UND paswort als 2FA finde ich ganz ehrlich doch etwas lol. ist die smartcard dank PIN nicht ohnehin 2FA? (also man braucht die karte, etwas was man hat, und die PIN, etwas was man weiß), könnte man das irgendwie auch machen dass man smartcard ODER Passwort nutzen kann?
bspw n super aufwändiges passwort als notfalltor oder so und die smartcard für normale nutzung oder so?
wäre Cool.
Danke.
Hallo!
Vielen Dank für Ihr Kommentar, im Prinzip haben Sie da schon Recht. Von der Konfiguration ändert sich natürlich nicht viel, man kann das Passwort PAM natürlich auch weglassen, wenn man ein ausreichend starkes Passwort für die PIN der Smartcard definieren kann. Bei der von mir genutzten Smartcard ging das leider nicht, als Nutzer kann ich auch 1234 als PIN wählen und die PIN auch gleich mit einem Permanentmarker auf die Smartcard schreiben.
Ihren Blog habe ich auch gesichtet, schöne Arbeit!
Einen Blog aber ganz ohne Impressum zu betreiben — der auch Produktrezensionen enthält — finde ich in heutiger Zeit sehr mutig.
also laut TMG5 geht es um “geschäftsmäßige, in der Regel gegen Entgelt angebotene Telemedien”, ich mache weder ein geschäft noch fordere ich Geld. Dazu ist impressumspflicht schon irgendwie lol angesichts der erzwungenen Whois privacy mit DSGVO. und wenn gesetzeshüter was wollen, können die die Daten einfach abfragen, oder mich direkt kontaktieren über eine von drölf dutzend Möglichkeiten.
und “produktrezensionen”, braucht das Amazonprofil jetzt auch ein Impressum? 🙂
ich mach das einfach weil ich spaß dran habe, lol.
aber mal noch eine Frage: wo kommt das schlüsselpaar auf der karte her?
Ich habe hier eine frische Idem Card -> gotrustid.com die laut eigenen Angaben PIV kann, und ich krieg es einfach nicht hin ein schlüsselpaar zu erstellen, egal ob ich es in windows probiere “schreibgeschützt” oder in linux (kubuntu 18.04).
bzgl ausreichend stark, muss ich sagen, relativ. eine SIM oder EC Karte hat auch nur eine 4 (bzw bei SIM bis 8) stellige PIN, jedoch reicht das aus da man ja nur wenige versuche hat, bei ner smartcard genauso.
die PIN mit marker aud die karte schreiben sicher, kann man aber dann auch das passwort gleich dazuschreiben, lol.
PW weg lassen ist eine interessante idee für smartcard only aber meine Idee wäre ja smartcard oder PW gewesen.
Hallo!
ich habe für den Artikel eine GIDS Smartcard mit einem HID / Omnikey Reader verwendet. Die Idem Smartcard kenne ich leider nicht.
Das Zertifikat kann man auf einer initialisierten Smartcard mit der Anleitung erstellen:
http://cedric.dufour.name/blah/IT/SmartCardsHowto.html
Wichtig ist aber, dass die /usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so in der openssl.conf richig eingebunden ist. Dann klappt auch ein “openssl req …” Befehl.
Viel Erfolg!