Die Smart­card hat in den ver­gan­genen 20 Jahren die Welt erobert: Von Bankkarten, über Kun­denkarten, Mit­glied­karten, Zutrittskarten und in der IT für die Spe­icherung von Zer­ti­fikat­en. Beson­ders kri­tis­che Geräte wer­den seit vie­len Jahren mit Smart­cards für die Ver­schlüs­selung und Benutzeri­den­ti­fizierung geschützt. Win­dows Nutzer kön­nen eine Vielzahl an von Microsoft unter­stützten Smart­cards für die Win­dows Anmel­dung nutzen, jedoch ist die Nutzer von Ver­schlüs­selung oder Benutzeri­den­ti­fizierung mit Zer­ti­fikat­en und Smart­cards unter Lin­ux nur wenig ver­bre­it­et.

Zwei-Fak­toren Authen­tifizierung (auch 2FA, Mul­ti-Fak­tor Authen­tisierung, oder starke Benutzeri­den­ti­fizierung genan­nt) hil­ft bei der Com­pli­anceer­fül­lung und ist zer­ti­fizierten Umge­bun­gen oft von den Reg­u­la­to­rien oder Audi­toren gefordert.

Dieser Artikel beschreibt in ein­fachen Schrit­ten die Instal­la­tion und Nutzung von Smart­cards als Zwei-Fak­toren Authen­tifizierung (auch 2FA oder Mul­ti-Fak­tor Authen­tisierung genan­nt) mit dem aktuellen (Stand August 2019) Ubun­tu Desk­top 19.04 für die wichtig­sten Login-Anwen­dungs­fälle.

  • LUKS Disk Encryp­tion

  • Con­sole Login

  • GUI Login

  • Remote SSH Login

Imple­men­tierung: mit­tel 60%
Funk­tion­sum­fang 75%
Sicher­heit 100%

Die Instal­la­tion der Smart­card Treiber und des 2FA PAM Moduls

Die Instal­la­tion des benötigten Authen­tisierungsmoduls unter Lin­ux ist ein­fach, da es direkt über die Ubun­tu Dis­tri­b­u­tion­squelle instal­liert wer­den kann. Vor der Instal­la­tion von open­sc und lib­pam-pkc­s11 emp­fiehlt es sich das Sys­tem mit “sudo apt upgrade” zu aktu­al­isieren.

Bei der Instal­la­tion von open­sc und lib­pam-pkc­s11 wer­den einige Pack­ages zusät­zlich instal­liert, da die Instal­la­tion vol­lau­toma­tisch und prob­lem­los erfol­gt verzichte ich hier auf die Analyse der Soft­warekom­po­nen­ten.

$ sudo apt install open­sc

$ sudo apt install lib­pam-pkc­s11

Die Smart­card Read­er Treiber und die Smart­card Mid­dle­ware sowie das PAM Authen­tisierungsmod­ul für Lin­ux sind nun instal­liert. Jedoch muss die Zwei-Fak­toren Meth­ode am Sys­tem aktiviert wer­den, indem die Lin­ux PAM Kon­fig­u­ra­tion für die Nutzung der Smart­card 2FA angepasst wird.

Aktivierung des der Smart­card 2FA Kon­fig­u­ra­tion

Die fol­gen­den Kon­fig­u­ra­tio­nen habe ich in ein­er nicht pro­duk­tiv­en, virtuellen Tes­tumge­bung mit ein­er Testkarte von cert­gate erstellt. Daher verzichte ich auf die Unken­ntlich­machung von Userken­nun­gen oder Smart­card Details.

Im ersten Schritt müssen wir prüfen, ob der Smart­card-Read­er über die Lin­ux PC/SC Schnittstelle erkan­nt wird. Dazu benutzen wir das open­sc-tool mit der Option “-l” (klein L).

$ open­sc-tool ‑l
# Detect­ed read­ers (pcsc)
Nr. Card Fea­tures Name
0 Yes OMNIKEY Card­Man 5321 00 00

In mein­er Tes­tumge­bung habe ich einen OMNIKEY Card­Man 5321 (einen großen Brud­er vom sehr weit ver­bre­it­eten OMNIKEY Card­Man 3121) über USB ver­bun­den.

Mit dem näch­sten Befehl lis­ten wir die Smart­card Treiber, die in der instal­lierten Ver­sion von Open­SC ver­füg­bar sind:

$ open­sc-tool ‑D
Con­fig­ured card dri­vers:
car­dos Siemens Car­dOS
flex Schlum­berg­er Multiflex/Cryptoflex
cyber­flex Schlum­berg­er Cyber­flex
gpk Gem­plus GPK
gemsafeV1 Gemal­to Gem­Safe V1 applet
asep­cos Athena ASEPCOS
star­cos STARCOS
tcos TCOS 3.0
oberthur Oberthur AuthentIC.v2/CosmopolIC.v4
authen­tic Oberthur Authen­tIC v3.1
iasecc IAS-ECC
belpic Belpic cards
incrypto34 Incard Incripto34
acos5 ACS ACOS5 card
akis TUBITAK UEKAE AKIS
enter­safe enter­safe
epass2003 epass2003
ruto­ken Ruto­ken dri­ver
rutoken_ecp Ruto­ken ECP dri­ver
myeid MyEID cards with PKCS#15 applet
dnie DNIe: Span­ish eID card
Mask­Tech Mask­Tech Smart Card
atrust-acos A‑Trust ACOS cards
west­cos WESTCOS com­pat­i­ble cards
mus­cle Mus­cle­Ap­plet
sc-hsm Smart­Card-HSM
mcrd MICARDO 2.1 / EstEID 1.0 — 3.5
set­cos Setec cards
PIV-II Per­son­al Iden­ti­ty Ver­i­fi­ca­tion Card
cac Com­mon Access Card (CAC)
itac­ns Ital­ian CNS
isoAp­plet Javac­ard with IsoAp­plet
gids GIDS Smart Card
openpgp OpenPGP card
jpki JPKI(Japanese Indi­vid­ual Num­ber Cards)
coolkey COOLKEY
npa Ger­man ID card (neuer Per­son­alausweis, nPA)
default Default dri­ver for unknown cards

In Folge werde ich den fett markierten GIDS Smart Card Treiber nutzen, da ich ein GIDS 1.2 Smart­card als Testkarte habe.

Im näch­sten Schritt greifen wir über das pkc­s11-tool auf die Smart­card zu. Zuerst prüfen wir ob die Smart­card Treiber funk­tion­ieren:

$ pkc­s11-tool ‑L
Avail­able slots:
Slot 0 (0x0): OMNIKEY Card­Man 5321 00 00
token label : User­PIN (GIDS card)
token man­u­fac­tur­er : www.mysmartlogon.com
token mod­el : PKCS#15 emu­lat­ed
token flags : login required, token ini­tial­ized, PIN ini­tial­ized
hard­ware ver­sion : 0.0
firmware ver­sion : 0.0
ser­i­al num : 96f9503d220b0bd8
pin min/max : 4/15

Per­fekt! Über den OMNIKEY Card­Man 5321 wird eine GIDS Smart­card angezeigt, die aber mit ein­er User­PIN geschützt ist. Die anderen Infor­ma­tio­nen sind Sta­tus­in­for­ma­tio­nen der Smart­card, wie z.B. die erlaubte PIN (ver­gle­ich­bar mit einem Pass­wort) Länge von min­destens 4 Zeichen und max­i­mal 15 Zeichen.

Jet­zt wo wir wis­sen, dass die Smart­card ansprech­bar ist nutzen wir das pkc­s11-tool mit “-O” (das Zeichen O nicht Null) zusam­men mit “-l” (klein L) um die Objek­te aufzulis­ten und zuvor einen login über die User­PIN durchzuführen.

aschuster@ubuntudesktop1904:~$ pkc­s11-tool ‑O ‑l
Using slot 0 with a present token (0x0)
Log­ging in to “User­PIN (GIDS card)”.
Please enter User PIN:
Pri­vate Key Object; RSA
label: cert­gate demo-55a5094d-4207–43d2–43687
ID: 00
Usage: decrypt, sign
Pub­lic Key Object; RSA 2048 bits
label: cert­gate demo-55a5094d-4207–43d2–43687
ID: 00
Usage: encrypt, ver­i­fy
Cer­tifi­cate Object; type = X.509 cert
label: cert­gate 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 befind­en sich drei Objek­te auf der Smart­card:

  1. ein RSA 2048-Bit pri­vater Schlüs­sel (Pri­vate Key)
  2. der zu passende RSA 2048-Bit öffentliche Schlüs­sel (Pub­lic Key)
  3. das X.509 Zer­ti­fikat mit dem Label “cert­gate demo-55a5094d-4207–43d2–43687”

Für unsere weit­ere Kon­fig­u­ra­tion ist der CN im “Sub­ject” des Zer­ti­fikates wichtig. In diesem X.509 Zer­ti­fikat lautet der CN “cert­gate demo”.

Die Kon­fig­u­ra­tion des PKCS#11 PAM Moduls erfol­gt in der Kon­fig­u­ra­tions­datei pam_pkcs11.conf im Verze­ich­nis /etc/pam_pkcs11.

Hier die Kon­fig­u­ra­tion als Text und als Screen­shot:

$ 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 = open­sc;
pkcs11_module open­sc {
mod­ule = /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;
mod­ule = inter­nal ;
default_match = false;
default_user = nobody ;
}
map­per cn {
debug = false;
mod­ule = inter­nal;
ignore­case = true;
map­file = file:///etc/pam_pkcs11/cn_map;
}
}

Beson­ders erwäh­nenswert sind die Ein­träge “use_pkcs11_module = open­sc;” dieser ver­weist auf den Abschnitt darunter wo das Soft­ware-Mod­ul “mod­ule = /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so;” definiert wird.

In diesem Beispiel schal­ten wir mit “cert_policy = none;” die CRL und CA Zer­ti­fikats­ket­ten-Prü­fung ab. Dies wird man in pro­duk­tiv­en Umge­bun­gen natür­lich nicht so kon­fig­uri­eren, son­dern eine zumin­d­est zweistu­fige CA mit CRL-Prü­fung nutzen.

Der wichtige Ein­trag “use_mappers = cn, null;” ver­weist direkt auf den unten kon­fig­uri­erten Map­per “map­per cn”. Dort definieren wir in ein­fach­ster Weise eine Map­ping-Datei, die einzelne Zer­ti­fikate den Benutzer-Accounts zuweist. Auch hier wird es in größeren Pro­duk­tivumge­bun­gen einen Automa­tismus geben, der eine automa­tis­che Zuweisung von aus­gestell­ten CA Zer­ti­fikat­en auf zen­tral definierte Benutzer­ac­counts ermöglicht.

Nun müssen wir noch das Zer­ti­fikat dem Benutzer zuweisen, dies erfol­gt in der Datei “cn_map” im Verze­ich­nis “/etc/pam_pkcs11”.

$ cat cn_map
cert­gate demo -> aschus­ter

Er Ein­trag “cert­gate demo” bezieht sich auf den CN Ein­trag im X.509 Zer­ti­fikat, der Ein­trag “aschus­ter” auf die Benutzer-ID in der Datei /etc/passwd .

Das Lin­ux Kon­fig­u­ra­tion ist nun für 2FA mit ein­er Open­SC unter­stützen Smart­card vor­bere­it­et. Nun muss der Lin­ux Login Prozess um die Zwei-Fak­toren-Authen­tisierung erweit­ert wer­den.

Lin­ux PAM Kon­fig­u­ra­tion

Die PAM Kon­fig­u­ra­tion erfol­gt in den Dateien im Verze­ich­nis /etc/pam.d

Hier gibt es ver­schiedene Kon­fig­u­ra­tions­dateien für den Con­solen Login (Datei: login) und für die grafis­che Lin­ux GUI (Datei: gdm-pass­word).

Zwei-Fak­toren Benutzeri­den­ti­fizierung für Lin­ux Con­solen Login

Um die Smart­card 2FA für das Lin­ux Con­solen Login (Text-Screen direkt auf dem Client oder dem Serv­er) zu aktivieren, ändern Sie die Datei /etc/pam.d/login als root Benutzer entsprechend dem fol­gen­den Beispiel:

#The PAM con­fig­u­ra­tion file for the Shad­ow ‘login’ ser­vice
auth option­al pam_faildelay.so delay=3000000
auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so
auth req­ui­site pam_nologin.so
ses­sion [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
ses­sion required pam_loginuid.so
ses­sion [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
#pars­ing /etc/environment needs “readenv=1”
ses­sion required pam_env.so readenv=1
ses­sion required pam_env.so readenv=1 envfile=/etc/default/locale
#Stan­dard Un*x authen­ti­ca­tion.
@include com­mon-auth
ses­sion option­al pam_motd.so noup­date
#MODIFICATION: required for Smart­card 2FA
auth required pam_pkcs11.so

#This allows cer­tain extra groups to be grant­ed to a user
auth option­al pam_group.so
#Sets up user lim­its accord­ing to /etc/security/limits.conf
ses­sion required pam_limits.so
#Prints the last login info upon suc­cess­ful login
ses­sion option­al pam_lastlog.so
#Prints the mes­sage of the day upon suc­cess­ful login.
ses­sion option­al pam_motd.so motd=/run/motd.dynamic
ses­sion option­al pam_motd.so noup­date
#
ses­sion option­al pam_mail.so stan­dard
#Cre­ate a new ses­sion keyring.
ses­sion option­al pam_keyinit.so force revoke
#Stan­dard Un*x account and ses­sion
@include com­mon-account
@include com­mon-ses­sion
@include com­mon-pass­word

Zwei-Fak­toren Benutzeri­den­ti­fizierung für Lin­ux GUI (GDM Ober­fläche)

Um die Smart­card 2FA für den Ubun­tu Win­dow-Man­ag­er GDM zu aktivieren, ändern Sie die Datei /etc/pam.d/gdm-password als root Benutzer entsprechend dem fol­gen­den Beispiel:

#%PAM‑1.0
auth req­ui­site pam_nologin.so
auth required pam_succeed_if.so user != root quiet_success
@include com­mon-auth
#Required for Smart­card 2FA
auth required pam_pkcs11.so

auth option­al pam_gnome_keyring.so
@include com­mon-account
ses­sion [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close
ses­sion required pam_loginuid.so
ses­sion [success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open
ses­sion option­al pam_keyinit.so force revoke
ses­sion required pam_limits.so
ses­sion required pam_env.so readenv=1
ses­sion required pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale
@include com­mon-ses­sion
ses­sion option­al pam_gnome_keyring.so auto_start
@include com­mon-pass­word

Zwei-Fak­toren Benutzeri­den­ti­fizierung für Remote Zugriff per SSH

Der Remote Zugriff per SSH auf ein ent­fer­ntes Sys­tem funk­tion­iert nicht über das Lin­ux PAM Moduls des Ziel­sys­tems, da der Benutzer, der sich per SSH an einem Ziel­sys­tem anmeldet, seinen Smart­card Read­er ja nicht am Ziel­sys­tem ver­bun­den hat, son­dern an seinem lokalen Client.

SSHD unter­stützt jedoch die Anmel­dung mit Zer­ti­fikat­en, egal ob das zugreifende lokale Sys­tem ein Lin­ux oder Win­dows-Client ist. Ein funk­tion­ieren­des Beispiel für SSH find­en Sie unter dem Link https://help.ubuntu.com/community/SSH/OpenSSH/Keys . Natür­lich ent­fällt das Erstellen von privaten/public Key bei ein­er CA / Smart­card Infra­struk­tur, da die Benutzer ihr Schlüs­sel­ma­te­r­i­al ja von der CA Stelle erhal­ten.

Der Lin­ux GUI 2FA Login

Der Lin­ux Con­solen 2FA Login

Google Authen­ti­ca­tor Sicher­heit­süber­legun­gen

Auf­grund der FIPS und EAL 4 / EAL 5 zer­ti­fizierten Smart­cards und Token die bei ein­er Smart­card Zwei-Fak­toren-Benutzeri­den­ti­fizierung einge­set­zt wer­den sind die pri­vat­en Schlüs­sel der Mul­ti-Fak­tor Authen­tifizierung opti­mal geschützt. Wichtig ist natür­lich ein sicher­er Betrieb der Zer­ti­fikat­saus­gabesteller der CA, damit sichergestellt wird, dass nur berechtigte Benutzer ein passendes X.509 Zer­ti­fikat und ein Schlüs­sel-Mate­r­i­al bekom­men.

Der Vorteil ein­er Smart­card Authen­tisierung ist, dass diese 2FA Meth­ode sowohl im Offline-Modus als auch im Online-Modus eines Clients funk­tion­ieren. Im Offline-Modus muss man zuvor syn­chro­nisierte CRL Lis­ten für die Zer­ti­fikat­sprü­fung nutzen, um Online-Modus kann man auch die mod­erne OCSP Zer­ti­fikat­sprü­fung über ein Net­zw­erkpro­tokoll ver­wen­den.

Fol­gende Angriff­s­meth­o­d­en sind bei Smart­cards unter­bun­den:

Unau­torisierte Nutzung der PKI Schüs­sel

Die Smart­card ist mit ein­er User­PIN geschützt, diese User­PIN ist nur dem autorisierten Benutzer bekan­nt und kann nur von dem autorisierten Benutzer geän­dert wer­den. Das zer­ti­fizierte Smart­card Betrieb­ssys­tem schützt diesen ver­traulichen User­PIN.

Erstel­lung ein­er Kopie (oder Export) des pri­vat­en Schlüs­sels

Der pri­vate Schlüs­sel kann von ein­er Smart­card nicht kopiert wer­den, der Schlüs­sel wird i.d.R. auch direkt auf der Smart­card erstellt, daher existiert keine Kopie des ver­traulichen Schlüs­sels.

Brute-Force Angriff

Das Smart­card-Betrieb­ssys­tem sper­rt die Smart­card nach ein­er definier­baren Anzahl an Fehlver­suchen der User­PIN. Typ­is­cher­weise ist diese Anzahl an Zugriffsver­suchen auf einen Wert zwis­chen 5 und 10 eingestellt.