Sind lokale Anwendungen mit Fido2-Lösungen sinnvoll abzusichern?

gibt es für hierfür fertigen Java Code?
wenn ja Link hier einstellen, denn nur wenn es schnell geht ist die Wahrscheinlichkeit hoch, daß sowas umgesetzt wird

Der Private Key wird im Hardwaretoken erstellt, dort gespeichert und verlässt es nicht. Das Hardwaretoken gibt nur den Public Key heraus bzw. signiert mit diesem Nachrichten. Die (lokale) Anwendung agiert in diesem Fall als Server.

Es wäre klasse, könnte man Hibiscus oder andere ZV Programme damit absichern. Schöner wäre es aber, würden die Banken selbst Fido2 unterstützen (man wird ja mal träumen dürfen).
https://fidoalliance.org/psd2-compliance/

Eine Zusammenstellung weiterer Informationen, Libs, ... findet sich auch bei WebAuthn Awesome

PS: Ich wollte diese Info noch bei dem obigen Beitrag ergänzen, jedoch ist die Änderungsmöglichkeit nach dem Erstellen eines Beitrags zeitlich begrenzt.

Das isses ja, was ich sage bzw. glaube. Signierung und damit Anmeldung an einer Remote-Maschine, auf die ich keinen Zugriff habe, ist etwas völlig anderes als Datenverschlüsselung auf einen Datenbestand, auf den ich auf der lokalen Maschine vollen Zugriff habe. Wenn ich lokalen Zugriff habe, dann kann ich doch die Prüfung des Zertifikates usw. problemlos aushebeln... Da benötige ich dann ein Passwort, mit dem letztlich die Daten verschlüsselt sind und nicht ein Zertifikat bzw. die Antwort auf eine Anfrage, weil ich keine integere Instanz habe, die das prüft...

Das ändert aber nichts daran, dass es keine passende API für lokale Verschlüsselung gibt, weil der FIDO-Key nicht dafür gedacht ist sondern für Authentifizierung (via Signierung).
Hierfür wird der Standard WebAuthn verwendet. Der ist direkt in Browsern integriert. Die übernehmen die Kommunikation mit dem Token.

Für die Verschlüsselung von Daten (und darum geht's hier) braucht man entweder Zugriff auf den Private Key (den hat man nicht und den soll man auch nicht haben - das ist ja genau der Sinn solcher Hardware) oder wenigstens eine API, mit der man via USB direkt auf die Hardware zugreifen und damit die Daten verschlüsseln lassen kann (also ohne Umweg über den Browser). Mir ist aber keine solche API bekannt. Für Android scheint es eine API zu geben (https://developers.google.com/identity/fido/android/native-apps). Aber nichtmal dort scheint es Support für Verschlüsselung zu geben.

Solange mir keiner fachlich und technisch fundiert darlegen kann, wie das aus Java heraus funktonieren soll, brauchen wir hier nicht weiter spekulieren. Es ist ja nicht so, dass ich mich mit Verschlüsselung und Programmierung nicht auskenne. Und ich habe keinen Weg gefunden, wie das in Java funktionieren soll. Lasse mich aber gern vom Gegenteil überzeugen. Dann würde ich so einen Key vielleicht auch selbst nutzen.

Ehrlich jetzt? Ein Browser-basiertes Login für eine lokale Anwendung? Mit Verlaub - aber das klingt absurd. Man muss ja nicht alles umsetzen, was irgendwie technisch möglich ist. Ich scanne ja auch keinen QR-Code für ne TAN, um mein Mailprogramm zu starten.

Der öffnet aber kein Browser-Fenster mit einem lokalen Webserver dafür. Wenn ich überlege, was man allein durch dieses technische Konstrukt an Komplexität an Bord holt, möchte ich nicht wissen, welche Angriffsmöglichkeiten sich allein dadurch ergeben.

Wenn jemand einen Pull-Request bei Github erstellen möchte, gern. Bis dahin fehlt mir ehrlich gesagt die Zeit für solche Experimente.

Das weiß ich, deshalb habe ich es bereits in meinem ersten Post erwähnt.

Was nach dem Post kam (ohne Bezug zu einer Person) hatte jedoch den Tenor "macht keinen Sinn", "ist nicht möglich", "ist nicht realisierbar".

Ich finde es schade, wenn von Anfang an eine derart ablehnende Haltung vorherrscht, da es ja eine Lösung gibt - wenn auch nicht auf triviale Weise. Und dass 2-Faktor-/Mehrfaktor-Authentifizierung einen Sinn macht, steht meiner Meinung nach auch außer Frage.

Weil es keine vernünftige Lösung dafür gibt. Weil eine Lösung möglich ist, muss sie noch nicht sinnvoll sein. Ehrlich, ich finde die Idee mit Hardware-Tokens auch charmant und würde gerne damit was machen. Es ist also nicht so, dass ich da eine grundsätzliche Abneigung hätte. Im Gegenteil. Ich sehe aber keine technische Lösung, die mehr Probleme löst als sie neu erschafft. Die Lösung mit dem lokalen Webserver ist trivial angreifbar.