Anlässlich des gestrigen Releases von KDE Plasma 5.24, das die Möglichkeit Fingerabdrücke zur Authentifizierung einzusetzen, offiziell integriert möchte ich hier noch mal explizit davor warnen. Erstens weil biometrische Daten nicht zur Authentifizierung geeignet sind und zweitens weil Linux nicht die sichere Infrastruktur dafür bietet.
Ich hatte vor etwas mehr als einem Jahr, als die Bestrebungen Fahrt aufnahmen, bereits vor dieser Methode gewarnt und möchte das hier noch mal aufgreifen. Biometrische Daten sind nicht nur ungeeignet zur Authentifizierung, sondern Linux bietet nicht die notwendige Infrastruktur, um solche Daten sicher abzulegen. Die Implementierung in Linux ist ein einziges Sicherheitsrisiko und Datenverlust eine plausible Möglichkeit. Nur weil etwas freie Software ist, darf man dem nicht blind vertrauen.
Biometrische Daten zur Authentifizierung
Der erste Punkt ist natürlich, dass man besser keine biometrischen Daten zur Authentifizierung nutzt. Sie vermitteln ein falsches Sicherheitsgefühl und beim Verlust lassen sie sich nicht ersetzen. Kursiert der eigene Fingerabdruck irgendwo, kann man sich schlecht einen neuen generieren lassen. Andererseits nutzten vor dem Aufkommen solcher Verfahren viel zu wenige Anwender sichere PINs oder Passwörter für ihre mobilen Geräte. Entweder schützte man diese gar nicht oder mit simplen Wischmustern. Fingerabdruck oder Gesichtserkennung bieten hier durchaus einen Mehrwert. Mehrwert aber nur, wenn dieser Fingerabdruck sicher gespeichert wird.
Auf keinen Fall mit Linux!
Die größte Gefahr besteht darin, dass der Fingerabdruck verloren geht bzw. gestohlen wird. Google, Apple, Microsoft – sie alle sind sich dessen bei biometrischen Daten bewusst. Alle drei Anbieter haben in ihren Geräten sogenannte Sicherheitschips verbaut (Apple: Secure Enclave; Google: Titan M; Microsoft: TPM) mit denen sie solche Daten schützen. Die Daten der Fingerabdrücke können nicht vom Gerät exportiert werden.
Irgendwer kommt jetzt bestimmt wieder mit proprietärem Code und proprietärer Hardware, der man nicht vertrauen kann. Das ist Mist, mit dem man den desolaten Zustand unter Linux schönredet! Jeder Programmierer macht Fehler, kein Code ist perfekt, manchmal muss man durch die Architektur neue Sicherheitsmethoden einbauen.
Google, Apple & Co haben diese Verfahren sehr effizient eingesetzt, bisher sind trotz milliardenfacher Nutzung keine Daten abhandengekommen. Zudem speichern diese Firmen die Fingerabdrücke nicht als Bild, sondern als Hashwert. Die Apps bekommen durch das ausgefeilte Berechtigungssystem keinen direkten Zugriff auf den Fingerabdruck selbst, sondern führt nur einen Abgleich mit dem Hash durch – grob vereinfacht erklärt. Das sind die technischen Standards zur Verarbeitung biometrischer Daten und sie sind gerade so ausreichend (eigentlich sollten wir gar keine biometrischen Daten verarbeiten!)
Linux kann gar nichts davon! Hinter solchen Frontends wie bei Plasma kommt fprint zum Einsatz, die Authentifizierung erfolgt über PAM. Linux kann momentan noch nicht ausgreift und flächendeckend mit Sicherheitschips umgehen. Die Daten werden somit einfach im System gespeichert (wo auch sonst bei den aktuellen Möglichkeiten?) und können von dort auch mit entsprechenden Rechten exportiert werden.
Und da kommt mir bitte keiner mit dem tollen Berechtigungssystem von UNIX bzw. Linux. Das ist uralt und garantiert nicht für so hoch sensible Daten entworfen worden. Ein kritischer Fehler und sudo, PolKit oder wo auch immer und und wir sitzen richtig im Dreck! Berechtigungskonzepte für Apps haben wir jenseits von Flatpak gar nicht und noch immer kommen genug Helden auf die Idee, grafische Programme mit Administratorrechten zu starten. KDE hat das gerade erst wieder offiziell für Dolphin möglich gemacht.
Ich finde es in Ordnung, wenn Linux-Anwender sagen, die misstrauen Sicherheitschips wie TPM, aber dann lassen sich halt manche Funktionen wie ein biometrisches Authentifizierungsverfahren nicht umsetzen. Man kann nicht alles haben!
Schlussbemerkung
Dieser Text ist sehr hart und sehr plakativ geschrieben und man könnte zu vielen Punkten mehr schreiben und manches differenzieren. Aber anlässlich der Veröffentlichung von KDE Plasma 5.24 gestern, sehe ich mich in der Pflicht hier eindrücklich zu warnen. Es ist schön, wenn Entwickler sich mit so etwas befassen und hier grundlegende Methoden entwickeln. Wenn ein System aber nicht die geeignete Hardware-Infrastuktur hat, dann kann man an einem gewissen Punkt nicht weiter arbeiten.
Wenn Microsoft, Apple oder Google biometrische Authentifizierungsmaßnahmen so stümperhaft umgesetzt hätten, wäre jeder IT-Experte in jeder denkbaren Weise über sie hergefallen. Bei Linux ist das wieder okay, weil es ja freie Software ist und so. Nein, einsehbarer Code schützt nicht vor allem! Wenn hier Daten verloren gehen, kommen Heartbleed, Boothole und Debians OpenSSL-Fiasko zusammen. Will sagen: Dann ist der Ruf von Linux endgültig im Eimer!
Nachtrag 09. Februar 2022:
Anscheinend bin ich mit meiner Meinung hier wenigstens nicht ganz alleine. Durch einen Kommentar auf Linuxnews bin ich auf diesen Bugreport bei Debian aufmerksam geworden, der auf eine entsprechende Diskussion im GitLab von fprint verweist. Bitte folgenden Kommentare zur Kenntnis nehmen:
There are no short-term plans to fixing this. Any attempts at encrypting the fingerprints would just be security through obscurity as the decryption would need to be made available to fprintd and would therefore be available to other processes.
The only way to currently safeguard the fingerprints is to run with SELinux, AppArmor or another LSM enabled, and made sure that only the fprintd binary has access to those saved fingerprints.
Mal abgesehen davon, dass ich selbst die dort angedachten Schutzmaßnahmen für unzureichend halte, nutzt nur Fedora / RHEL SELinux in einer ausreichenden Konfiguration.
Folgende Aussage des Entwicklers bitte sich ebenfalls Gemüte führen:
I think we might entertain such ideas if anyone can actually point to proper research that shows it is feasible. Before then, I will continue to assume that anything like that is impossible.
Bei diesem Problembewusstsein frage ich mich, ob Debakel wirklich noch die ausreichende Beschreibung ist?
Ist Apple: Secure Enclave; Google: Titan M; Microsoft: TPM soweit gut beschrieben das geneigter Mensch das nutzen kann , sprich Fingerprint linux und TPM z.b oder muss ich bitte bitte machen bei Apple , Google und Co? Was hindert fprint diese Möglichkeit zu nutzen
Mal Entwickler Meinung außen vor.
Secure Enclave und Titan sind Hardware, die sich natürlich nur in entsprechenden Geräten findet. Das kann Linux natürlich nicht nutzen.
Die Bindung an TPM dürfte vermutlich zumindest theoretisch möglich sein. Microsoft macht das mit Windows Hello. TPM lässt sich unter Linux nutzen und ist dokumentiert. Aber ob es dafür Entwickler-Expertise gibt, kann ich natürlich nicht sagen. Frag in 10 Jahren nochmal 😉 Mal ernsthaft: Fprint ist ein kleines „Frickelprojekt“ und als solches vollkommen okay, aber das darf nicht an breite Anwenderschichten ausgerollt werden. Wir reden hier von biometrischen Daten, da kann man nicht mal ein bisschen experimentieren und hoffen, dass es keine Sicherheitslücken gibt.
Vorweg:
Ich lehne die Nutzung biometrischer Daten auch ab.
Ich stelle nicht in Frage, dass diese Fprint Lösung nicht durchdacht ist.
Allerdings gibt es im Linux Kontext schon Wege das besser zu machen, wenn man denn möchte:
https://docs.kernel.org/x86/sgx.html
https://puri.sm/posts/purism-integrates-heads-security-firmware-with-tpm-giving-full-control-and-digital-privacy-to-laptop-users/
Ja, Apple macht das mit dem T2-Chip so gut, auch das ganze Software-Setup unveränderbar vorzugeben, dem Nutzer die Netzwerkkonzrolle zu entziehen und kein anderes System installieren zu können, dass die tolle Hardware zu gunsten einer halb-so-teuren, technisch ebenbürtigen Alternative nur noch ungeutzt herum liegt.
Du möchtest also behaupten, dass du einen vierstelligen Betrag für Hardware ausgeben kannst, aber zu blöd bist, um eine Suchmaschine zu bedienen? Ich helfe dir mal: https://support.apple.com/en-us/HT208198
Genau das ist das schöne an solchen Funktionen: Die meisten Käufer von MacBooks wollen macOS nutzen und bekommen hier erweiterte Sicherheitsfunktionen an die Hand. Wer Linux nutzen möchte, kann dies weiter tun. Minimale Recherchefähigkeiten auf einer offiziellen Apple-Seite vorausgesetzt. Bei manchen scheint es dafür nicht zu reichen. Vielleicht sollten die dann besser auch kein Linux installieren.
———
Redaktioneller Hinweis: Leider finden sich solche Troll-Kommentare wie der Kommentar von „Anonymous“ oft in verschiedenen Blogs und die unbedarfte Leser glauben das dann. Genau deshalb habe ich diesen Kommentar hier freigeschaltet und kommentiert.
da kannst du rumpolemisieten wie du willst, das Ding ist zu recht aussortiert!
Ich stimme dir voll und ganz zu. Ohnehin finde ich biometrische Daten zu Authentifizierung absolut unzureichend und unsicher. Das sollte man dem normalen Benutzer einhämmern, aber leider siegt immer die Bequemlichkeit über Sicherheit.
fprint ist unsicher. Das wusste ich schon vorher und ich frage mich ernsthaft warum man bei dieser faktischen Unsicherheit das auch noch einbindet in eine DE wie KDE oder Gnome. Ich würde das Tool eher als Prototype bezeichnen, nach dem Motto „Hey, Fingerabdrucklesegeräte funktionieren auch unter Linux!“, aber mit Sicherheit hat das weniger zu tun. Mag sein, dass meine Frau auf meinem Laptop ohne mich keinen Zugriff mehr drauf hat, dass bedeutet aber nicht, dass es deswegen sicher ist.
Egal auf welchem BS, biometrische Daten dürfen nie als Ersatz für ein Passwort herhalten, sondern nur als kleine zusätzliche Absicherung (wenn überhaupt) zu dem min 8 stelligen Passwort (Zahlen,Groß+Kleinbuchstaben,Sonderzeichen). Eine Zweifaktor-Authentifizierung würde ich gegenüber meinem Fingerabdruck immer dem Vorrang geben.
Bzgl. fprint: Genau so sehe ich das auch. Das ist eine nette Experimentalstudie aber gehört nicht in die großen Desktopumgebungen und eigentlich müssten die Distributionen ihre Anwender vor so etwas schützen. Wozu haben wir denn sonst diese zentralen Kurationsstellen, wenn nicht für so etwas? Ich wollte nur nicht schon wieder einen „Distributions-Rant“ hier ablassen 😉 Deshalb habe ich es bei einer allgemeinen Warnung belassen.
Der einzige Lichtblick ist die nach wie vor schlechte Treibersituation, weshalb viele Anwender ihre Sensoren nicht richtig zum Laufen bekommen. Zum Glück 🙂
Gilt diese Warnung auch für Android? Das scheint mir hier das größere Problem zu sein.
Jaein:
Die grundsätzlich Warnung vor biometrischen Merkmalen schon. Leider keine Aussage ohne Einschränkung, daher: ABER bevor man sonst gar keine Sicherung verwendet, dann lieber biometrische Merkmale. Das ist ja nun mal die traurige Realität.
Denn Android speichert wie Fingerabdrücke im TEE (https://source.android.com/security/trusty). Genau das völlige Fehlen solcher Sicherungsmethoden kreide ich ja fprint an.
Dann ist die Überschrift des Artikels aber irreführend. War das bewusst so gewählt?
Inwiefern?
Für ihn scheint Android gleichbedeutend mit Linux zu sein.
Sie #7 https://curius.de/2022/02/standardargumente-bei-kritik-an-linux-und-die-folgen-dieser-diskussionsunfaehigkeit/
Ich werde über diese semantischen Nebelkerzen nicht mehr diskutieren.
Ein Gedanke der ja nicht vollständig abwegig ist („Android is a mobile operating system based on a modified version of the Linux kernel and other open source software“), oder?
Ich les den Artikel eher wie einen abfälligen Kommentar gegen fprint und deren versagende Programmierer, die Topic bashed aber im Gegensatz zum Fließtext einen Betriebssystemkernel und mir sind die Ausführungen des Autors einfach viel zu fuzzy um vermuten zu können was er den Lesenden sagen will oder ob das hier alles einfach Clickbait ist.
Semantische Nebelkerze. Ist dir schon mal aufgefallen, dass dieses semantische „Android ist aber irgendwie auch Linux“ nur von Linux-Anhängern genutzt wird, wenn man Leerstellen bei Linux wegdiskutieren möchte, weil man inhaltliche keine Argumente findet? Das ist so durchschaubar.
Nein, die Überschrift ist kein Clickbait, weil sie genau beschreibt worum es geht. Linux in seiner Desktop-, Server- und auch mobilen Inkarnation. Denn dieses Linux hat nur fprint und nichts anderes und darauf bauen die entsprechenden Funktionen in KDE und GNOME auf.
Ich habe mich gerade vor Lachen fast an meinem Kaffee verschluckt. Beim Blogpost zur Diskussionsunfähigkeit dachte ich mir noch: Wer diskutiert denn so? Und jetzt sieht man das seiner Reinform. Klasse! Die Diskussion hier und auch zu Vor- und Nachteilen von TPM war superspannend und sachlich, bis der eine Linux-Troll (das bist du!) erschien, der jede Kritik an Linux als Angriff auf seine Person versteht und mit einem superaggressiven Unterton alles wegschreiben will. Kannst du dir kein anderes Spielzeug suchen?
Lies den Artikel einfach mal, nicht nur die Überschrift, dann wird klar warum Gerrit explizit vor der Nutzung unter Linux warnt, und bei anderen Systemen nur davon abrät. Ist meinen Augen gut verständlich geschrieben.
Deshalb bleibe ich bei klassische verfahren, mit gute alte Passwort und Pin. 🙂
Generell nutze ich keine Biometrische Authentifizierung, weder mit diesem oder jenem System. Es fiel hier schon – Zitat: „Deshalb bleibe ich bei klassische verfahren, mit gute alte Passwort und Pin.“ Sehr clever!
Dennoch, können die Entwickler solcher Programme wie fprint nichts dafür das vorhandenes Hard- bzw Software Zeug proprietärer Krempel ist auf den Linux Entwickler keinen Zugriff bekommen um das vernünftig bauen zu können so das diese Kram sicher genug ist. Das betraf im laufe der Jahre viele Anwendungen, wie zB. Grafikkarten, Soundkarten usw usw … Nun trifft es dieses Login-Gedöns per Fingerabdruck, beim nächste mal was anderes … Ist immer gleich. Wenn die Hersteller solch Geräte bzw Software entsprechend entwickeln würden damit Entwickler aus der „Linux-Welt“ da ansetzen könnten, gäbe es so geartete Blogartikel nicht. Closed- Source ~ Open-Source
Das ist einfach nicht wahr, sondern nur eine dieser typischen Linux-Ausreden. TPM ist standardisiert, Lennart Poettering setzt inzwischen bei systemd ein und wenn man TPM nicht mag, könnte man immer noch mittels SELinux oder auch AppArmor zusätzliche Restriktionen vornehmen. Die Treiber der Lesegeräte sind nicht das Problem, die bieten bei proprietären Systemen auch keine groß anderen Funktionen.
Wie man in der oben verlinkten Diskussion sieht, interessiert das die fprint-Entwickler nur nicht. Sie vertreten die unter FOSS oft vertretene Ansicht, dass man sich um die Sicherheit kümmert, wenn eine Lücke bekannt ist. Bei biometrischen Daten reicht das aber nicht, weil einmal verloren gegangene Daten unwiederbringlich weg sind und sich nicht neu generieren lassen. Das notwendige Problembewusstsein fehlt hier ganz offenkundig.
Lieber Autor
Danke für diesen Beitrag. Das macht für mich alles Sinn, und ich habe mich nun auch mal etwas mehr in fprintd eingelesen – und danach den Fingerabdruck Dings wieder deaktiviert.
Danke fürs Aufmerksam machen.
Kennst du dich mit den Fingerprint-Reader-Verfahren genauer aus? Wenn ich das nach meiner oberflächlichen Recherche richtig verstanden habe, gibt es bei den Geräten ja u.a. die Unterscheidung in MOH (Match on Host?) und MOC (Match on Chip?). Wären MOC-Reader also in der Lage, meinen Fingerabdruck komplett im Sensor zu verarbeiten, so dass das Betriebssystem selbst nie an die Abdruck-Bilder rankommt? Sofern der Chip selbst dann keine SIcherheitslücken hat, wäre so eine Hardware doch auch gegen die von dir angesprochenen Sicherheitsprobleme bei libfprint abgesichert, oder?
Das wäre dann aber ein anderes Verfahren als die beschriebene fprint-Technik. Unterstützt Linux das überhaupt?
Wie da die Linux-Unterstützung aussieht, weiß ich nicht. Mein Eindruck ist, dass https://github.com/uunicorn/python-validity genau solche Match-on-Chip bzw. Match-in-Sensor-Geräte unterstützt, während fprint eben nur Match-on-Host-Geräte unterstützt. python-validity ist aber anscheinend noch in einer frühen Entwicklungsphase.
Aber mir geht es erstmal nur darum, ob der generelle Ansatz von MOC/MIS sinnvoll ist, um einen Fingerabdruck-Leser unter Linux sicher zum Laufen zu bringen. Zumindest könnte dieser Ansatz realistischer sein, als das fprint-Projekt „sicher“ zu machen, oder?
Wenn du der Firmware vertraust, dann schon.