Erfahrung mit YubiKey etc. gesucht

[johndoe049]

Juhu,

der erste Kunde, der eine Zwei Faktor Authentifizerung will - und dann noch mit YubiKey.

:-D

Spass beiseite. Hat jemand Erfahrung, wie man YubiKey etc. einbindet?

Welche Bibliothekten sollte man nehmen und welche besser nicht
Was ist zu beachten
Welche Anfängerfehler sind üblich


So eine Art Tutorial für alle, die sich damit mal befassen wollen/sollen/dürfen/müssen.

[freimatz]

Wir haben Yubikey. Aber was meinst Du mit Einbindung? Du fragst hier in "Algorithmen, Datenstrukturen und Klassendesign". Bei uns wird aber nur die exe am Schluss signiert. :roll:

[Uwe Raabe]

Zitat:

Zitat von freimatz (Beitrag 1536253)

Aber was meinst Du mit Einbindung?

Ich vermute es geht um die Authentifizierung des Users gegenüber der Applikation?

[johndoe049]

Zitat:

Zitat von Uwe Raabe (Beitrag 1536255)

Zitat:

Zitat von freimatz (Beitrag 1536253)

Aber was meinst Du mit Einbindung?

Ich vermute es geht um die Authentifizierung des Users gegenüber der Applikation?

Richtig.
Wie kann man es einrichten, bzw. was muss man einrichten, damit ein Benutzer per YubiKey Authentifiziert wird.

[Phoenix]

Die einfachste Variante ist per WebAuthN. :wink:


Aber wir reden hier, befürchte ich, von Desktop-Anwendungen?

Der Yubikey (ist ja ein USB-Device) meldet sich als HID (Human Interface Device) an, und kann sozusagen wie eine Tastatur funktionieren.
Wenn Du ihn einsteckst und drauf drückst, generiert er Dir einen OTP (One-Time Password) und gibt ihn sozusagen als Keypresses an Deine Anwendung.

Das OTP basiert zum einen auf der ID des Keys, und zum anderen aus einem Shared Key, den Deine Applikation auf den Yubikey programmiert (bzw. auf einen sogenannten "Slot" setzt).
Wenn Du nun den User Authentifizieren willst, dann suchst Du den Shared Key zu dem User (und dessen Yubkey Key-ID).
Den Zeichensalat den der Yubikey an Deine Anwendung "tippt" kannst Du nun gegen diese zwei Werte validieren (steckt auch alles im Yubikey SDK drin), und das sagt Dir dann ob das wirklich von dem Key kam oder nicht.

Siehe auch: https://docs.yubico.com/yesdk/users-...redential.html
und
https://docs.yubico.com/yesdk/users-...onse-code.html

[johndoe049]

Zitat:

Zitat von Phoenix (Beitrag 1536258)

Aber wir reden hier, befürchte ich, von Desktop-Anwendungen?

Es geht um eine Desktopanwendung. Genauer die Konfiguration einer Maschinensteuerung.

Kann ich davon ausgehen, dass Yubikey eher für Webanwendungen konzipiert ist?

Ist das dann überhaupt so ein Sicherheitsgewinn, wie unser Kunde sich das Vorstellt, oder geht der von eine falschen Annahme aus?

Im Moment haben wir Passwort und RFID Karten für den Kunden geplant. Das ist dem aber nicht sicher genug.

[skybibo]

Hallo johndoe049,

die Frage wäre für mich, wie die Authentifikation ablaufen soll.

Soll der Yubikey nur zur Authentifikation genutzt werden (6 Stelliger Code), oder soll die Anwendung direkt mit dem USB Key kommunizieren.

Das einfachste wird sein, wenn du die Authenticotor APP von Yubikey verwendest (https://www.yubico.com/products/yubico-authenticator/) und einen Shared Key erzeugst, den du im Programm und im Yubikey speicherst. Der Yubikey erzeugt dann einen 6 Stelligen Code mit dem Google OTP Algorithmus. Für dein Programm könntest du z.B. die Unit aus https://github.com/BoscoBecker/Delph...-Authenticator nutzen.

Die direkte Kommunikation mit dem Yubikey wird wahrscheinlich aufwendiger.

[johndoe049]

Also der Kunde hat die Idee, dass der Bediener den Jubikey einsteckt, ein Passwort in die Steuerung eingibt und beides zusammen die Authentifizierung darstellt.

[Phoenix]

Zitat:

Zitat von johndoe049 (Beitrag 1536261)

Im Moment haben wir Passwort und RFID Karten für den Kunden geplant. Das ist dem aber nicht sicher genug.

Das sind doch schon 2 Faktoren.

Wenn ich jetzt einem Benutzer das Passwort abluchse ist es mir vollkommen egal ob ich ihm noch eine RFID-Karte, einen Yubikey oder im Zweifel einfach beides aus der Tasche klauen muss um an das System zu kommen.

[rabatscher]

Ich habe einen Wrapper für Yubikeys Library geschrieben:
https://github.com/mikerabat/DelphiFido2

Bitte gerne mal ausprobieren;)
Das Projekt beinhaltet auch ein Beispiel für Webauth incl
Wrapper für die Win API.

[TomyN]

Ich nutze den Rockey4ND. Da hat man mehrere Möglichkeiten zur Verifizierung:
- Eine fixe Seriennummer
- Eine programmierbare ID
- Die Möglichkeit, einfache Rechnungen zu programmieren und dann mit verschiedenen Werten durchzuführen
- Einen 1k RAM
- Enen Zufallsgenerator

Es gibt einige Fragen, die man vorher klären sollte:
- Wie soll sich die Anwendung verhalten, wenn der Key abgezogen wird?
- Gibt es verschiedene Level der Rechte, also z.B. Start des Programms erfordert Passwort, Programmierung erfordert zusätzlich Dongle, oder gibt's 'nur' Dongle + PW?
- Soll es nur einen Dongle, eine fest Anzahl von Dongles oder eine beliebige Anzahl von Dongles geben können?

Ansonsten ist das eigentliche Programmieren, wie so oft, wenn klar ist, was man genau will, (zumindest mit dem Rockey) kein wirkliches Problem.

Tomy

[johndoe049]

Zitat:

Das sind doch schon 2 Faktoren.

Wenn ich jetzt einem Benutzer das Passwort abluchse ist es mir vollkommen egal ob ich ihm noch eine RFID-Karte, einen Yubikey oder im Zweifel einfach beides aus der Tasche klauen muss um an das System zu kommen.

Ist auch unsere Meinung. Beim Kunden ist jemand in der Qualitätssicherung, der da eine andere Meinung hat und Fan vom Jubikey ist. Argumenten ist der nicht zugängig. Ist einer vom Typ "Ich will aber!".

Zitat:

Ich nutze den Rockey4ND. Da hat man mehrere Möglichkeiten zur Verifizierung:

Ist der Ähnlich wie Wibu? Die haben wir bei einigen im Einsatz. Aufwendig ist aber, dass bei jeder Änderung die Programmdatei, etc. neu verpackt werden muss und man den Masterkey dabei haben muss. Das macht Änderungen beim Kunden vor Ort aufwendig und teuer wegen den Masterkeys.

Zitat:

Es gibt einige Fragen, die man vorher klären sollte:
- Wie soll sich die Anwendung verhalten, wenn der Key abgezogen wird?
- Gibt es verschiedene Level der Rechte, also z.B. Start des Programms erfordert Passwort, Programmierung erfordert zusätzlich Dongle, oder gibt's 'nur' Dongle + PW?
- Soll es nur einen Dongle, eine fest Anzahl von Dongles oder eine beliebige Anzahl von Dongles geben können?

- Konfiguration/Logbuch wird dann geschlossen
- Programm startet auch ohne Anmeldung. Anmeldung ist nur für Konfigurationsanpassung oder Aufruf vom Logbuch notwendig.
- Der aus der Qualitätssicherung war überrascht, dass man pro Nutzer einen Jubikey benötigt, damit es sicher ist. Die wollten 1-2 Keys mit verschiedenen Passwörtern pro Benutzer verwenden. Key mit verschiedenen Fingerabrücken als erster Faktor und Passwort zur Identifizierung des Benutzers als zweiter Faktor.

[himitsu]

Wenn der USB-Stick keine physische Aktion bedingt, was bei YubiKey aber nötig sein kann,
könnte man auch eine USB-Weiterleitung verwenden. Virtueller USB-Port und dann lokal via LAN, VPN oder Dergleichen den echten USB-Stick irgendwo anders.

Ähnlich wie mit den neuen USB-Keys für Signierungen.

[rabatscher]

Zitat:

Zitat von johndoe049 (Beitrag 1536276)

Also der Kunde hat die Idee, dass der Bediener den Jubikey einsteckt, ein Passwort in die Steuerung eingibt und beides zusammen die Authentifizierung darstellt.

Also.. die Keys unterstützen prinzipiell den Fido2 Standard.
Dabei kann man diverseste Optionen überlegen:
* authentifikation mit Pin/biometrisch + einer Userinteraktion
* nur einstecken und ner Userinteraktion (ohne Pin/biometrie)
* nur test ob der key authentifiziert wird

Die Keys können auch per Webauthn also Fido2 übers Web
benutzt werden.

Die Yubikey (libfido) api implementiert das Ctap
Protokoll (also die Kommunikation zw. Key und
App) und auch die Verifikation der Challenges (assert verification)
Was nicht implementiert wurde ist das Ablegen der Keys
In ner Datenbank nur ein rudimentäres Ablegen der
Daten in Files wird in den Besipielen gezeigt… und auch konnte ich damit keine
Passkeys (z.b Apples Passkey per Biometrie)
per Webauthn verifizieren, da sie einen geringeren
Sicherheitsstamdard im Webauthnprotokoll inplementiert,
Der keine Info über den Key weiter gibt und nur den
Publik Key weiter gibt.
Diese Lücke sollte meine lib aber schließen (siehe anderes
Posting)

Prinzipiell bin ich ein riesen Fan von Fido2- nie werden
Passwörter übertragen, was es für Hacker EXTREM,
schwierig macht.

[Phoenix]

Zitat:

Zitat von johndoe049 (Beitrag 1536289)

Ist auch unsere Meinung. Beim Kunden ist jemand in der Qualitätssicherung, der da eine andere Meinung hat und Fan vom Jubikey ist. Argumenten ist der nicht zugängig. Ist einer vom Typ "Ich will aber!".
[...]
- Der aus der Qualitätssicherung war überrascht, dass man pro Nutzer einen Jubikey benötigt, damit es sicher ist. Die wollten 1-2 Keys mit verschiedenen Passwörtern pro Benutzer verwenden. Key mit verschiedenen Fingerabrücken als erster Faktor und Passwort zur Identifizierung des Benutzers als zweiter Faktor.

Ohwei.
Fan sein wollen, aber keine Ahnung haben, wie sowas in der Praxis ausschaut. :roll:

Der YubiKey selber hat zwar eine Touch-Fläche, die ist aber KEIN Fingerprint-Sensor. Die ist ausschließlich dafür da, dass der Key eine Benutzerinteraktion bestätigen kann. (Okay, es gibt YubiKey Bio Series mit Fingerprint-Sensor, da kostet ein einzelner aber > 90 € und die sind offenbar nicht so sicher wie die ohne, weil die ohne haben eine Zertifizierung für Behörden bekommen, die mit dem Sensor nicht, das spricht meines Erachtens Bände...).

Die Idee ist, dass der Key stecken bleiben kann, aber eine Authentifizierung am Bildschirm sagt: "Wenn Du wirklich willst, dann berühre jetzt den Stick..." - und technisch steht eigentlich dahinter ("... Damit Du Dein Passwort nicht eingeben musst.") - und wenn der User das nicht macht, passiert auch nix. Wenn der aber seinen Stick vergisst, ist es dem Yubikey an sich vollkommen wurscht, WER da die Touchfläche berührt. Deswegen sind die meisten OS-Integrationen von FIDO auch so implementiert, dass der User zu dem Stick auch nochmal eine PIN eingeben muss.

Kurzum: Yubikeys SIND cool. Keine Frage. Aber auch teuer (die alten fangen bei 25€ das Stück an, die aktuellen bei 50).
Der Kollege aus der QS beim Kunden darf gerne mal bei uns in eines unserer Webinare zu FIDO reinschauen: https://www.youtube.com/watch?v=_2i9ucyeveM, von einem Ex-Kollegen, was die Keys eigentlich machen sollen.

Wenn er es sicher will, dann ist es relativ egal, ob der zweite Faktor ein physikalisch beim Benutzer verorteter Yubikey oder eine RFID-Karte ist.
Benutzer kennt sein Passwort (Faktor 1) und hat sein Hardware-Stück dabei (Key oder Karte, Faktor 2) -> Drin.
Die Frage ist dann letzten Endes nur eine des Preises. Das würde ich beim Kunden auch bewusst eine Stufe über der QS aufhängen, weil wenn dem sein Chef raus bekommt das es statt für 50+ Euro pro Benutzer auch genauso sicher mit ein paar Cent für ne RFID-Karte gegangen wäre, die die Benutzer ggf. eh schon haben... , dann ist die Sache Betriebswirtschaftlich sehr schnell geregelt.

[johndoe049]

Zitat:

Zitat von Phoenix (Beitrag 1536294)

Ohwei.
Fan sein wollen, aber keine Ahnung haben, wie sowas in der Praxis ausschaut. :roll:

Der YubiKey selber hat zwar eine Touch-Fläche, die ist aber KEIN Fingerprint-Sensor. Die ist ausschließlich dafür da, dass der Key eine Benutzerinteraktion bestätigen kann. (Okay, es gibt YubiKey Bio Series mit Fingerprint-Sensor, da kostet ein einzelner aber > 90 € und die sind offenbar nicht so sicher wie die ohne, weil die ohne haben eine Zertifizierung für Behörden bekommen, die mit dem Sensor nicht, das spricht meines Erachtens Bände...).

Wir haben das bei uns heute morgen in unserer Besprechung auch so gesehen, das der aus der Qualitätssicherung keine Ahnung hat, aber sich wichtig macht.

Für eine rein lokale Desktopanwendung macht das mit dem Jubikey so keinen Sinn, da der Kunde von Wunschdenken ausgeht. Ohne einem Fingerprint Sensor sehen wir bei uns derzeit keinen Vorteil gebenüber einer RFID Karte. Beides kann von unberechtigten verwendet werden. Da ist es egal, ob USB Stick oder Karte. Fidu2 hört sich zwar interessant an, aber auch hier ist keine "Diebstahlsicherung" vorhanden, wenn kein Fingerprint oder anderes biometische Kennzeichen mit verwendet wird.

Der bekommt jetzt eine Kombinationslösung angeboten. Fingerprint und Gesichtserkennung. Wenn der Mitarbeiter vom Terminal weggeht oder sich wegdreht und das Gesicht nicht mehr erkannt wird, wird das Terminal der Steuerung gesperrt. Ist ein Zukaufteil, wo wir nur den API Aufurf anstelle der Kennwortabfrage einbinden.

[CCRDude]

Zitat:

Zitat von johndoe049 (Beitrag 1536289)

Zitat:

Das sind doch schon 2 Faktoren.

Wenn ich jetzt einem Benutzer das Passwort abluchse ist es mir vollkommen egal ob ich ihm noch eine RFID-Karte, einen Yubikey oder im Zweifel einfach beides aus der Tasche klauen muss um an das System zu kommen.

Ist auch unsere Meinung. Beim Kunden ist jemand in der Qualitätssicherung, der da eine andere Meinung hat und Fan vom Jubikey ist. Argumenten ist der nicht zugängig. Ist einer vom Typ "Ich will aber!".

Kann man ja eigentlich parallel zu jeder anderen Art von Account betrachten.

Eine RFID-Karte kann man kopieren (bis auf wenige Ausnahmen, aber hier wurde nichts spezielles erwähnt), evtl. sogar separat im Vorbeigehen "belauschen" und Kopie erstellen.

Den Yubikey nicht.

Bei Angst vor reinem Diebstahl des Tokens ist es egal ob Karte oder Yubikey. Hat man aber Angst vor Industriespionage, wo jemand schlauer vorgeht und den zweiten Faktor kopieren möchte, um erstmal unentdeckt zu bleiben, ist der Yubikey halt deutlich überlegen.

Auch besser als Fingerabdrücke oder Gesichtsscans, solange die nicht wirklich gut sind (vielleicht sogar dann).

[Rollo62]

Zitat:

Zitat von johndoe049 (Beitrag 1536295)

Der bekommt jetzt eine Kombinationslösung angeboten. Fingerprint und Gesichtserkennung.

Interessehalber:
- Habt Ihr schon so ein konkretes Teil getestet, das zuverlässig funktioniert, könntest Du da etwas empfehlen?
- Was macht man damit, wenn die Biometrik mal aus irgend einem Grund versagt, gibt es einen zweiten Zugangsweg?
Wäre so ein 2ter Zugangsweg nicht automatisch wieder genauso unsicher wie vorher?

[johndoe049]

Zitat:

Zitat von Rollo62 (Beitrag 1536297)

Zitat:

Zitat von johndoe049 (Beitrag 1536295)

Der bekommt jetzt eine Kombinationslösung angeboten. Fingerprint und Gesichtserkennung.

Interessehalber:
- Habt Ihr schon so ein konkretes Teil getestet, das zuverlässig funktioniert, könntest Du da etwas empfehlen?
- Was macht man damit, wenn die Biometrik mal aus irgend einem Grund versagt, gibt es einen zweiten Zugangsweg?
Wäre so ein 2ter Zugangsweg nicht automatisch wieder genauso unsicher wie vorher?

Wenn die Biometrik ausfällt gibt es einen Ersatzzugang. Hierfür braucht man aber einen entsprechend registrierten PC/Notebook, da ansonsten die Verschlüsselung nicht funktioniert.

Das System was wir verwenden dürfen arbeitet mit einer normalen Kamera und Wärmebildkamera um Lebendobjekte zu prüfen. Lt. Vertriebsvereinbarung können wir das nur unter eigenem Namen und für eigene Systeme verwenden, daher keine Empfehlung.

[Rollo62]

Ok, verstehe.

Du arbeitest also entweder für Fort Knox oder Area 51 :-D
Beneidenswert :thumb:

[johndoe049]

Zitat:

Zitat von Rollo62 (Beitrag 1536299)

Ok, verstehe.

Du arbeitest also entweder für Fort Knox oder Area 51 :-D
Beneidenswert :thumb:

Nee. Wir programmieren überwiegend Steuerungen für Produktionsmaschinen, automatische Produktionsauswertung, Dokumentationsnachweise für Produktionsprozesse, etc.

Je mehr es Cyber Angriffe auf Hersteller gibt und die Produktion lamgelegt wird oder einfach nur Parameter geändert werden umso neurotischer werden die Kunden. Parameter Änderungen wird als kritischer angesehen. Wenn dass nicht schnell genug auffällt, kann man komplette Produktionschargen entsorgen.

Wir machen keine aktive Werbung und setzen uns damit ab, dass wir halt "kreative" Sicherheit in die Steuerung einbauen. Daher war die Frage, ob wir Jubikey auch kreativ einsetzen können. Das System für die Gesichtserkennung haben wir nur in Verwendung, weil ich den Inhaber/Entwicker persönlich kenne. Ursprünglich wurde das für die Holzverarbeitung entwickelt. Sollte beim Sägen mögliche Überhitzungsquellen und Brandquellen frühzeitig erkennen und entsprechend Alarm auslösen. Daher Bild- und Wärme-Kamera.

Dass man das auch für was anderes verwenden kann, ist uns beim Grillen in den Sinn gekommen (Bei privaten Grillfesten und danach kann es ja auch "heiss" hergehen und bei ausreichend Alkohol kommt man halt auf Ideen, was man noch auf Temperatur prüfen kann. Damit meine ich natürlich nur das "Grillgut" - Also Steaks usw. :)).

[himitsu]

Zitat:

Zitat von Phoenix (Beitrag 1536294)

für ne RFID-Karte gegangen wäre

Bei den Karten kommt es dann auch nochmal drauf an.

Nur die Serial als Authentifizierung kann prinzipiell kopiert werden, wenn jemand kurz in die Nähe der Karte kommt.
Es lassen sich karten Simulieren, aber man kann auch aus China "inoffiziell" Karten bekommen, wo noch keine Serial eingebrannt ist, was man dann selbst nachholen kann, mit der kopierten Nummer.

Es gibt auch noch Karten mit einer Sicherheitsfunktion, wie z.B. Mifare DESFire, wo im Chip "versteckt" ein Schlüssel abgelegt werden kann, welcher bei der Authentifizierung für eine Berechnung genutzt werden kann, innerhalb der Karte.
Die Karte bekommt einen beliebigen Wert, verrechnet ihn mit dem Schlüssel, gibt das Ergebnis raus, das Programm macht das ebenfalls und vergleicht die Ergebnisse. (ja, für genug Geld und wenn dabei die Karte kaputtgehen darf, lässt sich auch dieser Schlüssel auslesen)

Und man kann es auch übertreiben und noch besserere Karten besorgen.


Es gibt auch nette USB-Fingerabdruckdinger, oder man könnte versuchen das Windows Hallo (Fingerabduck, Gesicht, RFIDkarte, oder ...) zu nutzen.
Ich hab hier auch einen, den man via Serial (oder USB ähhh Arduino) einbinden kann. Mit dem Fingerabdruck wird ein "Wert" verbunden, oder man kann die Fingerabdruckdaten selbst (also die kodierten "Merkmale") nutzen (jedes Mal wenn "neu" registriert wird, sind die anders) oder auch wirklich ein Image des Fingerabdrucks (bieten nicht alle Fingerprint-Reader und ich würde es auch nicht empfehlen).
Ja, da man die "kodierten Merkmale" auslesen und kopieren könnte oder sich auch in die Kommunikation mit dem PC einschleusen kann (wenn man physisch ans USB-Kabel ran kommt, bzw. ein Fake-USB-Gerät ansteckt),
aber auch beim YubiKey käme man eventuell ans USB-Kabel, z.B. eines Verlängerungskabels oder im PC bei den Frontusb ans Kabel und könnte eine Fake bzw. Reader zwischenschalten.
usw.

Fazit: Wenn man es genau nimmt, ist eigentlich NICHTS 100% sicher.

[Phoenix]

Zitat:

Zitat von himitsu (Beitrag 1536301)

Es gibt auch nette USB-Fingerabdruckdinger, oder man könnte versuchen das Windows Hallo (Fingerabduck, Gesicht, RFIDkarte, oder ...) zu nutzen.

Wir haben leider auch genug Kunden in der Branche.

Das eigentliche Problem ist nämlich, dass an dem Rechner immer, 24/7, ein technischer User angemeldet ist und dort immer eine Instanz der Software läuft.

Das ist der einzige Grund, warum sich der Benutzer überhaupt in der eigentlichen Anwendung anmelden muss, denn ansonsten könnte man sich dort "einfach" auf die Windows-Authentifizierung verlassen und den Windows-User verwenden.

Aber dann müsste sich der User ja wieder von Windows abmelden, der neue Anmelden, warten bis die Software unter seinem Account neu gestartet wurde und kann dann erst loslegen.
Das ist aus irgendwelchen Gründen meist nicht gewollt.

[himitsu]

Für Windows Hallo soll in WinRT z. UWP eine API existieren. (selber noch nichts gemacht, aber wir nutzen in Win32 ja auch schon einige WinRT-API, z.B. rechts, für die Benachrichtigungen oder Bluetooth, wenn ich mich nicht irre)
https://learn.microsoft.com/en-us/uw...ectedfrom=MSDN

ansonsten wohl auch über den Browser
https://learn.microsoft.com/de-de/wi.../webauthn-apis

[CCRDude]

Zitat:

Zitat von Phoenix (Beitrag 1536302)

Das eigentliche Problem ist nämlich, dass an dem Rechner immer, 24/7, ein technischer User angemeldet ist und dort immer eine Instanz der Software läuft.

Wenn es rund um die Uhr laufen soll, wäre das ja eine Sache für einen Systemdienst. Dann wäre die erste Trennschicht schon zwischen Dienst und Benutzeroberfläche, so dass der User-Account beispielsweise gar nicht mehr an die Dateien kommt, die der Servicenutzer nutzt. Und die Windows-Authentifizierung könnte eben doch genutzt werden, ggfls. inklusive erprobter Sicherheitshardware, die nicht nur Idee-beim-Grillen-Security-by-Obscurity ist. Und inklusive Protokollen und was alles fertig dazugehört.

[johndoe049]

Zitat:

Das eigentliche Problem ist nämlich, dass an dem Rechner immer, 24/7, ein technischer User angemeldet ist und dort immer eine Instanz der Software läuft.

Kein Problem. Maschinenrichtlinie bzw. Arbeitsschutz. Der Zustand einer Maschine muss immer direkt ersichtlich sein um Fehler frühzeitig bei der Bedienung/Nutzung zu erkennen. Muss man sich erst einloggen gibt es nette Gespräche mit der Gewerbeaufsicht bei Unfällen. Wenn Zustand, Fehler, etc. nicht über den Monitor dargestellt werden sind entsprechende Leuchtzeichen, z.B. Turmleuchten, zu verwenden. Dann wird aber die notwendige Prüfung nach CE, UL, UKCA, usw. wieder teurer, da mehr Komponenten dokumentiert und geprüft werden müssen.

Ausserhalb von Deutschland ist das noch restriktiver.

Zitat:

Die Karte bekommt einen beliebigen Wert, verrechnet ihn mit dem Schlüssel, gibt das Ergebnis raus, das Programm macht das ebenfalls und vergleicht die Ergebnisse. (ja, für genug Geld und wenn dabei die Karte kaputtgehen darf, lässt sich auch dieser Schlüssel auslesen)

Diese Karten sind Standard bei uns. Challenge - Response with Fake Responses.

Zitat:

da man die "kodierten Merkmale" auslesen und kopieren könnte oder sich auch in die Kommunikation mit dem PC einschleusen kann (wenn man physisch ans USB-Kabel ran kommt, bzw. ein Fake-USB-Gerät ansteckt),
aber auch beim YubiKey käme man eventuell ans USB-Kabel, z.B. eines Verlängerungskabels oder im PC bei den Frontusb ans Kabel und könnte eine Fake bzw. Reader zwischenschalten.
usw.

Mal ernsthaft, wenn ein RFID Reader, Fingerprint, etc. nicht mit asymetrischer Verschlüsselung und Session Key arbeitet ist das für uns kein Gerät, was wir verwenden. Das ist eher was für ERP Systeme oder Lernsysteme. Nichts, was wir für Produktionsmaschinen verwenden würden. Da sind die möglichen Haftungsprobleme mit so einem Spielzeug einfach zu hoch.

Zitat:

Wenn es rund um die Uhr laufen soll, wäre das ja eine Sache für einen Systemdienst.

So und nicht anders. Steuerung als Systemdienst, Bedieneroberfläche und Statusanzeige als Applikation, die sich direkt startet. Bei externen Anzeigen im Maschinenleitstand wird auch asymetrisch verschlüsselt übertragen.

Zitat:

erprobter Sicherheitshardware, die nicht nur Idee-beim-Grillen-Security-by-Obscurity ist

:)
Rate mal, womit man auch BSL-4 Labore absichern kann und so kleine unbedeutende Firmen wie BAE den Zugang absichern können.

Da ist nichts mit Security by Obscurity zu machen. Da braucht man schon nachweisliche Qualifikationen, Prüfungen, Zertifizierungen, möglichst auch Patente, einiges an Referenzen, usw.

Zurück zur Anfangsfrage:
Was bring Yubikey für einen Vorteil? Der "einfache" Key hat keinen Fingerprint und in der Dokumentation haben wir nichts gefunden, dass die Kommunikation asymetrisch verschlüsselt erfolgt. Wie sichert Yubikey einen Man in the middle Angriff ab und verhindert das kopieren von Daten auf ein Zweitterminal in Echtzeit. So wie wir das bisher verstanden haben, kann man mit einer entpsrechenden Schnittstelle (USB Kabel, Zwischenadapter mit Logic, ähnlich einem Keylogger, etc.) das Ergebnis vom Yubikey auch auf einen anderen PC mit verwenden. Da ist wird noch nicht mal das Zeitverhalten in der Kommunikation geprüft.

Gibt es Sicherheitszulassungen oder Prüfungen für diese Geräte und das SDK (FIPS 143, MISRA, DO178C, usw.). Bisher sehen wir hier keinen Sicherheitsgewinn für unsere Steuerungen. Das ist für uns bisher nur Security by Obscurity or Security by Marketing.

[rabatscher]

Zitat:

Zurück zur Anfangsfrage:
Was bring Yubikey für einen Vorteil? Der "einfache" Key hat keinen Fingerprint und in der Dokumentation haben wir nichts gefunden, dass die Kommunikation asymetrisch verschlüsselt erfolgt. Wie sichert Yubikey einen Man in the middle Angriff ab und verhindert das kopieren von Daten auf ein Zweitterminal in Echtzeit. So wie wir das bisher verstanden haben, kann man mit einer entpsrechenden Schnittstelle (USB Kabel, Zwischenadapter mit Logic, ähnlich einem Keylogger, etc.) das Ergebnis vom Yubikey auch auf einen anderen PC mit verwenden. Da ist wird noch nicht mal das Zeitverhalten in der Kommunikation geprüft.

Also prinzipiell implementieren die Keys den Fido2 Standard. D.h. Private Keys werden auf dem Key gespeichert, Public Keys an die Anwendung
weiter gegeben (Enrollment).
Die Authentifizierung findet in der App statt: Die Applikation kreiert eine Zufallschallenge (z.B. 32Byte Zeichenfolge)
-> diese wird an den Key übergeben -> der Verschlüsselt den Key mit seinem Private Key -> Das Ganze kommt zurück zur App und kann da
per Public Key wieder entschlüsselt werden.
(Assertion)

Also der Standard ist da eigentlich recht klar... Die Library unterstützt RSA und Elliptical Curves - ich bin bisher nur über die EC curves
bei Yubiko und SoloKeys und RSA beim IPhone Passkey gestolpert.

Wie wärs eigentlich mit IOS/Android Passkeys? Die sind sehr artverwandt (siehe Webauthn aka Fido2 übers Web) mit etwas weniger Sicherheit insgesamt. Die Biometrie übernimmt das Handy ;). Nur brauchen dann Client PC und Handy nen Internetzugang...

[Phoenix]

Zitat:

Zitat von johndoe049 (Beitrag 1536341)

Gibt es Sicherheitszulassungen oder Prüfungen für diese Geräte und das SDK (FIPS 143, MISRA, DO178C, usw.). Bisher sehen wir hier keinen Sicherheitsgewinn für unsere Steuerungen. Das ist für uns bisher nur Security by Obscurity or Security by Marketing.

Es gibt FIPS-Yubikeys: https://www.yubico.com/products/yubikey-fips/
Die sind halt etwas teurer als die nicht Zertifizerten (beginnen bei ca. 80€ das Stück).

Wenn man sowas richtig einbindet, dann ist das ein vernünftiger Zweitfaktor, oder (gekoppelt mit einem anderen Zweitfaktor), ein sinnvoller Passwortersatz.

Aber wenn man schon andere vernünftige Lösungen hat (wie eben die Karten), dann sehe ich da auch keinen riesigen Vorteil drin.

[johndoe049]

Zitat:

Also prinzipiell implementieren die Keys den Fido2 Standard. D.h. Private Keys werden auf dem Key gespeichert, Public Keys an die Anwendung
weiter gegeben (Enrollment).
Die Authentifizierung findet in der App statt: Die Applikation kreiert eine Zufallschallenge (z.B. 32Byte Zeichenfolge)
-> diese wird an den Key übergeben -> der Verschlüsselt den Key mit seinem Private Key -> Das Ganze kommt zurück zur App und kann da
per Public Key wieder entschlüsselt werden.
(Assertion)

Das machen wir mit unseren RFID Karten genauso.
Wir haben aber noch einen RFID Reader, der die Daten erst überträgt, wenn man noch eine Zufallspin vom Monitor eingibt. D.h. die Verbindung wird dann nochmal zusätzlich verschlüsselt. Klingt Paranoid, das ist aber die session key verschlüsselte Übertragung von einer verschlüsselten Antwort.

Zitat:

Wie wärs eigentlich mit IOS/Android Passkeys? Die sind sehr artverwandt (siehe Webauthn aka Fido2 übers Web) mit etwas weniger Sicherheit insgesamt. Die Biometrie übernimmt das Handy . Nur brauchen dann Client PC und Handy nen Internetzugang...

Wieso sollte man eine Produktionsmaschine in einem Inselnetzwerk in das Internet schalten? Selbst wenn das im regulären Firmennetzwerk wäre, würde keiner eine Produktionsmaschine ins Internet hängen und sich Hacker einladen.
Biometrie ohne Wärmeerfassung fassen wir nicht an. iPhone hat zwar FLIR Kameras im Zubehör, aber keine mit einer Zertifizierung. Gleiches bei Android. Cat hat auch keine Zertifizierung. Bei Lebensmittelherstellern würde uns auch z.B. BSL-2 Eignung ausreichen. Wenns gefährlichere Produktion, wie z.B. Presswerk/Stahlverarbeitung oder Wasserstrahlschneiden ist, sehen wir genauer hin.

Zitat:

Es gibt FIPS-Yubikeys: https://www.yubico.com/products/yubikey-fips/
Die sind halt etwas teurer als die nicht Zertifizerten (beginnen bei ca. 80€ das Stück).

Wäre kein Hindernis. Ist doch noch günstig.

Zitat:

Aber wenn man schon andere vernünftige Lösungen hat (wie eben die Karten), dann sehe ich da auch keinen riesigen Vorteil drin.

Sind wir dem Kunden auch so am erklären.