Die Smart­card hat in den ver­gan­ge­nen 20 Jah­ren die Welt erobert: Von Bank­kar­ten, über Kun­den­kar­ten, Mit­glied­kar­ten, Zutritts­kar­ten und in der IT für die Spei­che­rung von Zer­ti­fi­ka­ten. Beson­ders kri­ti­sche Gerä­te wer­den seit vie­len Jah­ren mit Smart­cards für die Ver­schlüs­se­lung und Benut­ze­r­iden­ti­fi­zie­rung geschützt. Win­dows Nut­zer kön­nen eine Viel­zahl an von Micro­soft unter­stütz­ten Smart­cards für die Win­dows Anmel­dung nut­zen, jedoch ist die Nut­zer von Ver­schlüs­se­lung oder Benut­ze­r­iden­ti­fi­zie­rung mit Zer­ti­fi­ka­ten und Smart­cards unter Linux nur wenig verbreitet.

Zwei-Fak­to­ren Authen­ti­fi­zie­rung (auch 2FA, Mul­ti-Fak­tor Authen­ti­sie­rung, oder star­ke Benut­ze­r­iden­ti­fi­zie­rung genannt) hilft bei der Com­pli­an­ceer­fül­lung und ist zer­ti­fi­zier­ten Umge­bun­gen oft von den Regu­la­to­ri­en oder Audi­to­ren gefordert.

Die­ser Arti­kel beschreibt in ein­fa­chen Schrit­ten die Instal­la­ti­on und Nut­zung von Smart­cards als Zwei-Fak­to­ren Authen­ti­fi­zie­rung (auch 2FA oder Mul­ti-Fak­tor Authen­ti­sie­rung genannt) mit dem aktu­el­len (Stand August 2019) Ubun­tu Desk­top 19.04 für die wich­tigs­ten Login-Anwendungsfälle.

  • LUKS Disk Encryption

  • Con­so­le Login

  • GUI Log­in

  • Remo­te SSH Login

Imple­men­tie­rung: mit­tel 60%
Funk­ti­ons­um­fang 75%
Sicher­heit 100%

Die Instal­la­ti­on der Smart­card Trei­ber und des 2FA PAM Moduls

Die Instal­la­ti­on des benö­tig­ten Authen­ti­sie­rungs­mo­duls unter Linux ist ein­fach, da es direkt über die Ubun­tu Dis­tri­bu­ti­ons­quel­le instal­liert wer­den kann. Vor der Instal­la­ti­on von opensc und lib­pam-pkcs11 emp­fiehlt es sich das Sys­tem mit “sudo apt upgrade” zu aktualisieren.

Bei der Instal­la­ti­on von opensc und lib­pam-pkcs11 wer­den eini­ge Packa­ges zusätz­lich instal­liert, da die Instal­la­ti­on voll­au­to­ma­tisch und pro­blem­los erfolgt ver­zich­te ich hier auf die Ana­ly­se der Softwarekomponenten.

$ sudo apt install opensc

$ sudo apt install libpam-pkcs11

Die Smart­card Rea­der Trei­ber und die Smart­card Midd­le­wa­re sowie das PAM Authen­ti­sie­rungs­mo­dul für Linux sind nun instal­liert. Jedoch muss die Zwei-Fak­to­ren Metho­de am Sys­tem akti­viert wer­den, indem die Linux PAM Kon­fi­gu­ra­ti­on für die Nut­zung der Smart­card 2FA ange­passt wird.

Akti­vie­rung des der Smart­card 2FA Konfiguration

Die fol­gen­den Kon­fi­gu­ra­tio­nen habe ich in einer nicht pro­duk­ti­ven, vir­tu­el­len Test­um­ge­bung mit einer Test­kar­te von cert­ga­te erstellt. Daher ver­zich­te ich auf die Unkennt­lich­ma­chung von User­ken­nun­gen oder Smart­card Details.

Im ers­ten Schritt müs­sen wir prü­fen, ob der Smart­card-Rea­der über die Linux PC/SC Schnitt­stel­le erkannt wird. Dazu benut­zen wir das opensc-tool mit der Opti­on “-l” (klein L).

$ opensc-tool ‑l
# Detec­ted rea­ders (pcsc)
Nr. Card Fea­tures Name
0 Yes OMNIKEY Card­Man 5321 00 00

In mei­ner Test­um­ge­bung habe ich einen OMNIKEY Card­Man 5321 (einen gro­ßen Bru­der vom sehr weit ver­brei­te­ten OMNIKEY Card­Man 3121) über USB verbunden.

Mit dem nächs­ten Befehl lis­ten wir die Smart­card Trei­ber, die in der instal­lier­ten Ver­si­on von OpenSC ver­füg­bar sind:

$ opensc-tool ‑D
Con­fi­gu­red card drivers:
car­dos Sie­mens CardOS
flex Schlum­ber­ger Multiflex/Cryptoflex
cyber­flex Schlum­ber­ger Cyberflex
gpk Gemp­lus GPK
gemsafeV1 Gemal­to Gem­Safe V1 applet
asep­cos Athena ASEPCOS
star­cos STARCOS
tcos TCOS 3.0
ober­thur Ober­thur AuthentIC.v2/CosmopolIC.v4
authen­tic Ober­thur Authen­tIC v3.1
iasecc IAS-ECC
bel­pic Bel­pic cards
incrypto34 Incard Incripto34
acos5 ACS ACOS5 card
akis TUBITAK UEKAE AKIS
ent­er­safe entersafe
epass2003 epass2003
rut­oken Rut­oken driver
rutoken_ecp Rut­oken ECP driver
myeid MyEID cards with PKCS#15 applet
dnie DNIe: Spa­nish eID card
Mask­Tech Mask­Tech Smart Card
atrust-acos A‑Trust ACOS cards
west­cos WESTCOS com­pa­ti­ble cards
mus­cle MuscleApplet
sc-hsm SmartCard-HSM
mcrd MICARDO 2.1 / EstEID 1.0 — 3.5
set­cos Set­ec cards
PIV-II Per­so­nal Iden­ti­ty Veri­fi­ca­ti­on Card
cac Com­mon Access Card (CAC)
itacns Ita­li­an CNS
iso­App­let Java­card with IsoApplet
gids GIDS Smart Card
openpgp OpenPGP card
jpki JPKI(Japanese Indi­vi­du­al Num­ber Cards)
cool­key COOLKEY
npa Ger­man ID card (neu­er Per­so­nal­aus­weis, nPA)
default Default dri­ver for unknown cards

In Fol­ge wer­de ich den fett mar­kier­ten GIDS Smart Card Trei­ber nut­zen, da ich ein GIDS 1.2 Smart­card als Test­kar­te habe.

Im nächs­ten Schritt grei­fen wir über das pkcs11-tool auf die Smart­card zu. Zuerst prü­fen wir ob die Smart­card Trei­ber funktionieren:

$ pkcs11-tool ‑L
Avail­ab­le slots:
Slot 0 (0x0): OMNIKEY Card­Man 5321 00 00
token label : User­PIN (GIDS card)
token manu­fac­tu­rer : www.mysmartlogon.com
token model : PKCS#15 emulated
token flags : log­in requi­red, token initia­li­zed, PIN initialized
hard­ware ver­si­on : 0.0
firm­ware ver­si­on : 0.0
seri­al num : 96f9503d220b0bd8
pin min/max : 4/15

Per­fekt! Über den OMNIKEY Card­Man 5321 wird eine GIDS Smart­card ange­zeigt, die aber mit einer User­PIN geschützt ist. Die ande­ren Infor­ma­tio­nen sind Sta­tus­in­for­ma­tio­nen der Smart­card, wie z.B. die erlaub­te PIN (ver­gleich­bar mit einem Pass­wort) Län­ge von min­des­tens 4 Zei­chen und maxi­mal 15 Zeichen.

Jetzt wo wir wis­sen, dass die Smart­card ansprech­bar ist nut­zen wir das pkcs11-tool mit “-O” (das Zei­chen O nicht Null) zusam­men mit “-l” (klein L) um die Objek­te auf­zu­lis­ten und zuvor einen login über die User­PIN durchzuführen.

aschuster@ubuntudesktop1904:~$ pkcs11-tool ‑O ‑l
Using slot 0 with a pre­sent token (0x0)
Log­ging in to “User­PIN (GIDS card)”.
Plea­se enter User PIN:
Pri­va­te Key Object; RSA
label: cert­ga­te demo-55a5094d-4207–43d2–43687
ID: 00
Usa­ge: decrypt, sign
Public Key Object; RSA 2048 bits
label: cert­ga­te demo-55a5094d-4207–43d2–43687
ID: 00
Usa­ge: encrypt, verify
Cer­ti­fi­ca­te Object; type = X.509 cert
label: cert­ga­te demo-55a5094d-4207–43d2–43687
sub­ject: DN: DC=local, DC=certgate, OU=certgate-user, OU=Entwicklung, CN=certgate demo/emailAddress=certgate-DEMO@certgate.com
ID: 00

Es befin­den sich drei Objek­te auf der Smartcard:

  1. ein RSA 2048-Bit pri­va­ter Schlüs­sel (Pri­va­te Key)
  2. der zu pas­sen­de RSA 2048-Bit öffent­li­che Schlüs­sel (Public Key)
  3. das X.509 Zer­ti­fi­kat mit dem Label “cert­ga­te demo-55a5094d-4207–43d2–43687”

Für unse­re wei­te­re Kon­fi­gu­ra­ti­on ist der CN im “Sub­ject” des Zer­ti­fi­ka­tes wich­tig. In die­sem X.509 Zer­ti­fi­kat lau­tet der CN “cert­ga­te demo”.

Die Kon­fi­gu­ra­ti­on des PKCS#11 PAM Moduls erfolgt in der Kon­fi­gu­ra­ti­ons­da­tei pam_pkcs11.conf im Ver­zeich­nis /etc/pam_pkcs11.

Hier die Kon­fi­gu­ra­ti­on als Text und als Screenshot:

$ cat /etc/pam_pkcs11/pam_pkcs11.conf
pam_pkcs11 {
nul­lok = true;
debug = false;
use_first_pass = false;
try_first_pass = false;
use_authtok = false;
use_pkcs11_module = opensc;
pkcs11_module opensc {
modu­le = /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;
map­per null {
debug = false;
modu­le = internal ;
default_match = false;
default_user = nobody ;
}
map­per cn {
debug = false;
modu­le = internal;
igno­re­ca­se = true;
map­fi­le = file:///etc/pam_pkcs11/cn_map;
}
}

Beson­ders erwäh­nens­wert sind die Ein­trä­ge “use_pkcs11_module = opensc;” die­ser ver­weist auf den Abschnitt dar­un­ter wo das Soft­ware-Modul “modu­le = /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so;” defi­niert wird.

In die­sem Bei­spiel schal­ten wir mit “cert_policy = none;” die CRL und CA Zer­ti­fi­kats­ket­ten-Prü­fung ab. Dies wird man in pro­duk­ti­ven Umge­bun­gen natür­lich nicht so kon­fi­gu­rie­ren, son­dern eine zumin­dest zwei­stu­fi­ge CA mit CRL-Prü­fung nutzen.

Der wich­ti­ge Ein­trag “use_mappers = cn, null;” ver­weist direkt auf den unten kon­fi­gu­rier­ten Map­per “map­per cn”. Dort defi­nie­ren wir in ein­fachs­ter Wei­se eine Map­ping-Datei, die ein­zel­ne Zer­ti­fi­ka­te den Benut­zer-Accounts zuweist. Auch hier wird es in grö­ße­ren Pro­duk­tiv­um­ge­bun­gen einen Auto­ma­tis­mus geben, der eine auto­ma­ti­sche Zuwei­sung von aus­ge­stell­ten CA Zer­ti­fi­ka­ten auf zen­tral defi­nier­te Benut­zer­ac­counts ermöglicht.

Nun müs­sen wir noch das Zer­ti­fi­kat dem Benut­zer zuwei­sen, dies erfolgt in der Datei “cn_map” im Ver­zeich­nis “/etc/pam_pkcs11”.

$ cat cn_map
cert­ga­te demo -> aschuster

Er Ein­trag “cert­ga­te demo” bezieht sich auf den CN Ein­trag im X.509 Zer­ti­fi­kat, der Ein­trag “aschus­ter” auf die Benut­zer-ID in der Datei /etc/passwd .

Das Linux Kon­fi­gu­ra­ti­on ist nun für 2FA mit einer OpenSC unter­stüt­zen Smart­card vor­be­rei­tet. Nun muss der Linux Log­in Pro­zess um die Zwei-Fak­to­ren-Authen­ti­sie­rung erwei­tert werden.

Linux PAM Konfiguration

Die PAM Kon­fi­gu­ra­ti­on erfolgt in den Datei­en im Ver­zeich­nis /etc/pam.d

Hier gibt es ver­schie­de­ne Kon­fi­gu­ra­ti­ons­da­tei­en für den Con­so­len Log­in (Datei: log­in) und für die gra­fi­sche Linux GUI (Datei: gdm-password).

Zwei-Fak­to­ren Benut­ze­r­iden­ti­fi­zie­rung für Linux Con­so­len Login

Um die Smart­card 2FA für das Linux Con­so­len Log­in (Text-Screen direkt auf dem Cli­ent oder dem Ser­ver) zu akti­vie­ren, ändern Sie die Datei /etc/pam.d/login als root Benut­zer ent­spre­chend dem fol­gen­den Beispiel:

#The PAM con­fi­gu­ra­ti­on file for the Shadow ‘log­in’ service
auth optio­nal pam_faildelay.so delay=3000000
auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so
auth requi­si­te pam_nologin.so
ses­si­on [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
ses­si­on requi­red pam_loginuid.so
ses­si­on [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
#par­sing /etc/environment needs “readenv=1”
ses­si­on requi­red pam_env.so readenv=1
ses­si­on requi­red pam_env.so readenv=1 envfile=/etc/default/locale
#Stan­dard Un*x authentication.
@include common-auth
ses­si­on optio­nal pam_motd.so noupdate
#MODIFICATION: requi­red for Smart­card 2FA
auth requi­red pam_pkcs11.so

#This allows cer­tain extra groups to be gran­ted to a user
auth optio­nal pam_group.so
#Sets up user limits accord­ing to /etc/security/limits.conf
ses­si­on requi­red pam_limits.so
#Prints the last log­in info upon suc­cess­ful login
ses­si­on optio­nal pam_lastlog.so
#Prints the mes­sa­ge of the day upon suc­cess­ful login.
ses­si­on optio­nal pam_motd.so motd=/run/motd.dynamic
ses­si­on optio­nal pam_motd.so noupdate
#
ses­si­on optio­nal pam_mail.so standard
#Crea­te a new ses­si­on keyring.
ses­si­on optio­nal pam_keyinit.so for­ce revoke
#Stan­dard Un*x account and session
@include common-account
@include common-session
@include common-password

Zwei-Fak­to­ren Benut­ze­r­iden­ti­fi­zie­rung für Linux GUI (GDM Oberfläche)

Um die Smart­card 2FA für den Ubun­tu Win­dow-Mana­ger GDM zu akti­vie­ren, ändern Sie die Datei /etc/pam.d/gdm-password als root Benut­zer ent­spre­chend dem fol­gen­den Beispiel:

#%PAM‑1.0
auth requi­si­te pam_nologin.so
auth requi­red pam_succeed_if.so user != root quiet_success
@include common-auth
#Requi­red for Smart­card 2FA
auth requi­red pam_pkcs11.so

auth optio­nal pam_gnome_keyring.so
@include common-account
ses­si­on [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
ses­si­on requi­red pam_loginuid.so
ses­si­on [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
ses­si­on optio­nal pam_keyinit.so for­ce revoke
ses­si­on requi­red pam_limits.so
ses­si­on requi­red pam_env.so readenv=1
ses­si­on requi­red pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale
@include common-session
ses­si­on optio­nal pam_gnome_keyring.so auto_start
@include common-password

Zwei-Fak­to­ren Benut­ze­r­iden­ti­fi­zie­rung für Remo­te Zugriff per SSH

Der Remo­te Zugriff per SSH auf ein ent­fern­tes Sys­tem funk­tio­niert nicht über das Linux PAM Moduls des Ziel­sys­tems, da der Benut­zer, der sich per SSH an einem Ziel­sys­tem anmel­det, sei­nen Smart­card Rea­der ja nicht am Ziel­sys­tem ver­bun­den hat, son­dern an sei­nem loka­len Client.

SSHD unter­stützt jedoch die Anmel­dung mit Zer­ti­fi­ka­ten, egal ob das zugrei­fen­de loka­le Sys­tem ein Linux oder Win­dows-Cli­ent ist. Ein funk­tio­nie­ren­des Bei­spiel für SSH fin­den Sie unter dem Link https://help.ubuntu.com/community/SSH/OpenSSH/Keys . Natür­lich ent­fällt das Erstel­len von privaten/public Key bei einer CA / Smart­card Infra­struk­tur, da die Benut­zer ihr Schlüs­sel­ma­te­ri­al ja von der CA Stel­le erhalten.

Der Linux GUI 2FA Login

Der Linux Con­so­len 2FA Login

Goog­le Authen­ti­ca­tor Sicherheitsüberlegungen

Auf­grund der FIPS und EAL 4 / EAL 5 zer­ti­fi­zier­ten Smart­cards und Token die bei einer Smart­card Zwei-Fak­to­ren-Benut­ze­r­iden­ti­fi­zie­rung ein­ge­setzt wer­den sind die pri­va­ten Schlüs­sel der Mul­ti-Fak­tor Authen­ti­fi­zie­rung opti­mal geschützt. Wich­tig ist natür­lich ein siche­rer Betrieb der Zer­ti­fi­kats­aus­ga­be­stel­ler der CA, damit sicher­ge­stellt wird, dass nur berech­tig­te Benut­zer ein pas­sen­des X.509 Zer­ti­fi­kat und ein Schlüs­sel-Mate­ri­al bekommen.

Der Vor­teil einer Smart­card Authen­ti­sie­rung ist, dass die­se 2FA Metho­de sowohl im Off­line-Modus als auch im Online-Modus eines Cli­ents funk­tio­nie­ren. Im Off­line-Modus muss man zuvor syn­chro­ni­sier­te CRL Lis­ten für die Zer­ti­fi­kats­prü­fung nut­zen, um Online-Modus kann man auch die moder­ne OCSP Zer­ti­fi­kats­prü­fung über ein Netz­werk­pro­to­koll verwenden.

Fol­gen­de Angriffs­me­tho­den sind bei Smart­cards unterbunden:

Unau­to­ri­sier­te Nut­zung der PKI Schüssel

Die Smart­card ist mit einer User­PIN geschützt, die­se User­PIN ist nur dem auto­ri­sier­ten Benut­zer bekannt und kann nur von dem auto­ri­sier­ten Benut­zer geän­dert wer­den. Das zer­ti­fi­zier­te Smart­card Betriebs­sys­tem schützt die­sen ver­trau­li­chen UserPIN.

Erstel­lung einer Kopie (oder Export) des pri­va­ten Schlüssels

Der pri­va­te Schlüs­sel kann von einer Smart­card nicht kopiert wer­den, der Schlüs­sel wird i.d.R. auch direkt auf der Smart­card erstellt, daher exis­tiert kei­ne Kopie des ver­trau­li­chen Schlüssels.

Bru­te-For­ce Angriff

Das Smart­card-Betriebs­sys­tem sperrt die Smart­card nach einer defi­nier­ba­ren Anzahl an Fehl­ver­su­chen der User­PIN. Typi­scher­wei­se ist die­se Anzahl an Zugriffs­ver­su­chen auf einen Wert zwi­schen 5 und 10 eingestellt.