feat(2.9.2): Nur geprueft in Hardware entstandene Schluessel als zweiter Faktor

Befund aus dem Betrieb: Ein Passkey aus 1Password liess sich als
Hardwarekey registrieren. Fuer das Deploymentcenter hinnehmbar, fuer ein
Protokoll, das ausdruecklich Hardware fordert, nicht.

Zwei Dinge, die wie eine Pruefung aussahen und keine waren - beide seit
2.9.0 gesetzt: authenticatorAttachment "cross-platform" steuert, was der
Browser anbietet, und ein Passwortverwalter meldet sich ebenso. Und
response.authenticatorAttachment setzt der Client, also genau die Instanz,
gegen die sich nichts beweisen laesst.

Was traegt, ist Basic Attestation. Neu geprueft wird die Kette bis zu einer
hinterlegten Herstellerwurzel; die drei FIDO-Wurzeln von Yubico liegen bei.
Ein x5c allein genuegt ausdruecklich nicht: Der Fall "eigenes Zertifikat,
Name Yubico, AAGUID eines echten YubiKey 5, gueltige Unterschrift" wurde
nachgebaut und wird abgewiesen - an der Kette, nicht an der Signatur.

Drei Stufen statt eines Schalters, weil alle bisher registrierten
Schluessel als nicht nachgewiesen gelten - auch echte Yubikeys. Bei
attestation "none" ersetzt der Browser die Geraetekennung durch Nullbytes,
bevor der Server sie sieht; es gab also nie eine Herkunft. Ein einzelner
Schalter haette beim Umlegen den eigenen Zugang gesperrt. Der Wechsel nach
"strict" wird zusaetzlich abgelehnt, solange das eigene Konto keinen
nachgewiesenen Schluessel hat.

- Attestation.php: packed und fido-u2f, Kettenpruefung gegen eigene
  Wurzeln statt gegen den Speicher des Betriebssystems, Gueltigkeit,
  Gegenprobe der AAGUID aus der Zertifikatserweiterung
- HardwarePolicy.php: off / register / strict, optionale Modellliste,
  Wurzeln aus der Konfiguration erweiterbar
- Migration 021: attested und drei Anzeigespalten, Vorgabe 0
- WebUI: Herkunft je Schluessel, Regel vor der Beruehrung angesagt
- testctl clear_credentials, damit ein Testlauf den naechsten nicht
  aussperrt
- Testreihe "hardware", 5 Faelle, ohne Krypto-Bibliothek

184 von 184 Testfaellen gruen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

public/docs/changelog.json

@@ -1,8 +1,65 @@
 {
   "_comment": "Einzige Quelle der Wahrheit fuer den Changelog. Wird von /docs/changelog.php gerendert und von GET /api/updateservice/v1/changelog?since=X ausgeliefert. Neue Eintraege oben einfuegen.",
   "schema": 1,
-  "current": "2.9.1",
+  "current": "2.9.2",
   "versions": [
+    {
+      "version": "2.9.2",
+      "date": "2026-09-21",
+      "summary": "Das WebUI kann jetzt verlangen, dass ein zweiter Faktor wirklich in Hardware entstanden ist. Bisher liess sich auch ein Passwortverwalter als Hardwarekey registrieren - fuer das Deploymentcenter hinnehmbar, fuer ein Protokoll, das ausdruecklich Hardware fordert, nicht.",
+      "actionRequired": true,
+      "changes": [
+        {
+          "area": "security",
+          "breaking": false,
+          "title": "Attestation wird geprueft, wenn die Regel es verlangt",
+          "text": "Bis 2.9.1 forderte die Registrierung attestation \"none\" an und pruefte nichts. Der Kommentar im Code begruendete das damit, dass der Betreiber seinen eigenen Schluessel an seinem eigenen Server registriert - das stimmte und uebersah, was daraus im Betrieb wird: Ein 1Password-Passkey liess sich ebenso anstandslos aufnehmen wie ein Yubikey. Neu prueft der Server auf Wunsch die Basic Attestation: Der Authenticator unterschreibt bei der Aufnahme mit einem Schluessel, der ab Werk in seinem Sicherheitselement liegt, und das zugehoerige Zertifikat muss auf eine hinterlegte Herstellerwurzel ketten. Mitgeliefert werden die drei FIDO-Wurzeln von Yubico.",
+          "action": "Migration 021 ausfuehren. Danach unter System -> Benutzer die gewuenschte Stufe waehlen; ohne Umstellen bleibt das Verhalten von vorher."
+        },
+        {
+          "area": "security",
+          "breaking": false,
+          "title": "Warum die Kette geprueft wird und nicht nur das Vorhandensein eines Zertifikats",
+          "text": "Ein x5c allein beweist nichts: Jeder Authenticator kann sich selbst ein Zertifikat ausstellen, es \"Yubico U2F EE\" nennen, die AAGUID eines echten YubiKey 5 eintragen und kryptografisch einwandfrei unterschreiben. Genau dieser Fall wurde nachgebaut und gegen den Server gefahren - er wird abgewiesen, und zwar an der Kette, nicht an der Signatur. Was Software nicht herstellen kann, ist eine Kette, die bei Yubicos Wurzel endet; dafuer braeuchte es deren privaten Schluessel. Deshalb ist die Wurzeldatei kein Beiwerk, sondern der Kern der Pruefung.",
+          "action": null
+        },
+        {
+          "area": "security",
+          "breaking": false,
+          "title": "Drei Stufen, damit sich niemand aussperrt",
+          "text": "off laesst jeden Authenticator zu (das Verhalten bis 2.9.1). register verlangt den Nachweis nur bei NEUEN Aufnahmen - bestehende Schluessel melden sich weiter an. strict laesst auch zur Anmeldung nur noch geprueft in Hardware entstandene Schluessel zu. Die Zwischenstufe ist nicht Bequemlichkeit, sondern notwendig: Alle vor dieser Fassung registrierten Schluessel gelten als nicht nachgewiesen, auch echte Yubikeys, weil bei attestation \"none\" der Browser die Geraetekennung durch Nullbytes ersetzt, bevor der Server sie sieht. Ein einzelner Schalter haette in dem Moment, in dem man ihn umlegt, den eigenen Zugang gesperrt. Der Wechsel nach strict wird zusaetzlich abgelehnt, solange das eigene Konto keinen nachgewiesenen Schluessel hat.",
+          "action": "Wer strict nutzen will: erst auf register stellen, den Hardwarekey einmal neu aufnehmen, dann auf strict."
+        },
+        {
+          "area": "security",
+          "breaking": false,
+          "title": "cross-platform war nie eine Pruefung",
+          "text": "In den Registrierungsvorgaben stand seit 2.9.0 authenticatorAttachment = \"cross-platform\". Das sieht aus wie eine Beschraenkung auf angesteckte Hardware und ist keine: Die Angabe steuert, was der Browser ANBIETET, und ein Passwortverwalter meldet sich ebenfalls als cross-platform. Auch response.authenticatorAttachment traegt nicht - das setzt der Client, und der Client ist genau die Instanz, gegen die sich hier nichts beweisen laesst. Der Kommentar an dieser Stelle sagt das jetzt ausdruecklich, damit die Angabe nicht ein zweites Mal fuer eine Zusicherung gehalten wird.",
+          "action": null
+        },
+        {
+          "area": "webui",
+          "breaking": false,
+          "title": "Die Herkunft steht in der Schluesselliste",
+          "text": "Jeder registrierte Schluessel zeigt, ob er sich als Hardware ausgewiesen hat, bei welcher Herstellerwurzel die Kette endete und welche Geraetekennung er nennt. Die Kennung steht dort in derselben Schreibweise, in der die Modellliste sie erwartet - sie laesst sich also uebernehmen, statt sie irgendwo nachschlagen zu muessen. Die Regel wird ausserdem beim Registrieren angesagt, BEVOR jemand seinen Schluessel beruehrt: Wer erst danach erfaehrt, dass nur Hardware zaehlt, sucht den Fehler beim Schluessel statt bei der Einstellung.",
+          "action": null
+        },
+        {
+          "area": "security",
+          "breaking": false,
+          "title": "Modellliste optional - und mit Warnhinweis",
+          "text": "Zusaetzlich zur Wurzelpruefung lassen sich einzelne AAGUIDs zulassen. Die Liste ist leer voreingestellt und soll es meist bleiben: Yubico weist neuen Firmwarestaenden neue Kennungen zu, eine ungepflegte Liste weist also irgendwann einen echten Schluessel ab. Wo sie benutzt wird, wird die Kennung aus den Authenticator-Daten gegen die im Zertifikat gegengeprueft - sonst filterte man nach einer Behauptung statt nach einer Eigenschaft. Weitere Hersteller lassen sich ueber security.webauthn_root_files in der config.php ergaenzen, bewusst dort und nicht im WebUI: Eine Vertrauenswurzel ueber dieselbe Oberflaeche austauschbar zu machen, die sie schuetzt, hiesse die Pruefung dort aushebelbar zu machen.",
+          "action": null
+        },
+        {
+          "area": "tests",
+          "breaking": false,
+          "title": "Neue Testreihe \"hardware\" und testctl clear_credentials",
+          "text": "Fuenf Faelle pruefen die Gegenueberstellung, auf die es ankommt: dieselben Bytes eines Authenticators ohne Herkunftsnachweis, einmal mit und einmal ohne Regel. Sie kommen ohne Krypto-Bibliothek aus, weil bei fmt \"none\" keine Signatur geprueft wird. Der Fall mit vorgetaeuschtem Zertifikat laeuft in einem eigenen Werkzeug ausserhalb der Suite. testctl bekommt clear_credentials: Ein Testlauf, der einen Schluessel registriert, sperrt sonst den naechsten aus, und dafuer den ganzen Datenbestand zu loeschen waere ein hoher Preis fuer eine Tabelle.",
+          "action": null
+        }
+      ]
+    },
     {
       "version": "2.9.1",
       "date": "2026-09-20",