Zusammenfassung

  • RFC 9966 lässt einen TLS-Server Kenntnis des öffentlichen BSK-Schlüssels und ein Gerät Besitz des zugehörigen privaten Schlüssels nachweisen.
  • Wie dieser öffentliche Schlüssel beschafft, einem Gerät zugeordnet und für ein Netz zugelassen wurde, beantwortet der Nachweis nicht; diese Fragen bleiben bei eigenen Aufzeichnungen und Verantwortlichen.

Ein unversorgtes Gerät kann beim ersten Anschluss in einen Zirkel geraten: Für EAP-Zugang fehlt ihm ein Credential, für dessen Erhalt fehlt ihm der Zugang. Dan Harkins und Owen Friel beschreiben in RFC 9966 einen schmalen Einstieg für verkabelte Netze. TLS Proof of Knowledge, TLS-POK, nutzt dazu einen elliptischen Bootstrap Key, kurz BSK, und eine TLS-1.3-Sitzung, bevor ein später nutzbares Credential ausgestellt werden kann.

Die Schlüsselrollen sind klar verteilt. Nur das Gerät kennt den privaten Teil. Den öffentlichen Teil kennen Gerät sowie Eigentümer oder Halter; der Betreiber des TLS-Servers provisioniert ihn im Server. Der Server zeigt dem Client, dass er den öffentlichen Schlüssel kennt. Der Client zeigt dem Server, dass er den privaten Teil besitzt. Aus dem öffentlichen Schlüssel wird ein EPSK abgeleitet; das Gerät verwendet den BSK anschließend als Raw Public Key. Das ist ein Protokollbeleg für spezifisches Schlüsselwissen, nicht ein Beleg für Eigentum an der Sache.

Den vorangehenden Übergabepunkt normiert der RFC gerade nicht. Der genaue Weg, auf dem der Server den BSK Public Key erhält, ist außerhalb seines Geltungsbereichs. QR-Code-Scan und Upload einer Stückliste, eines BOM, nennt er als mögliche Wege. Ist das Etikett physisch am Gerät angebracht, nimmt das Modell an, physischer Besitz bedeute rechtmäßiges Eigentum. Diese Annahme verkürzt den Startvorgang, doch sie prüft weder Lieferkette, Inventar, Übergabe, Etikettentausch noch lokale Freigabe.

Die Security Considerations machen den Unterschied praktisch. Auf Client-Seite beruht Vertrauen darauf, dass der BSK Public Key nicht weithin bekannt ist. Kennt ein Angreifer ihn und bringt den Client zu seinem Server, kann er den TLS-POK-Ablauf abschließen und den Client gegen sein Netz bootstrappen. Wird in der früheren Bootstrap-Methode der Public Key eines ehrlichen Geräts durch den eines fremden Geräts ersetzt, kann der reguläre Server das falsche Gerät aufnehmen. Der kryptographische Nachweis kann vollständig korrekt sein und trotzdem eine verdorbene Zuordnung als Eingabe haben.

Auch die Detailregeln vermeiden keine Verantwortung durch Magie. Der Client darf seinen BSK Public Key erst nach Verarbeitung von ServerHello und Prüfung des TLS-Schlüsselplans senden; schlägt die PSK-Prüfung fehl, muss er ohne Offenlegung abbrechen. Hersteller sollten einen einzelnen BSK pro Gerät verwenden. Bei einem geteilten BSK kann der Betreiber Geräte nicht unterscheiden und nicht sichern, dass nur bestimmte autorisierte Geräte verbinden. Das begrenzt Offenlegung und technische Verwechslung, ersetzt aber keine Verwahrungsprüfung.

Nach erfolgreichem Ablauf kann der Server ein Credential für spätere EAP-Authentisierungen provisionieren. Der BSK dient nach RFC 9966 nur dem Bootstrap. Beschaffung des Public Key, Server-Provisionierung, TLS-Ergebnis, Credential-Ausgabe, EAP-Entscheidung und Durchsetzung am Anschluss bleiben damit getrennte Ereignisse. Ein positives Ereignis ist kein Beleg für alle folgenden.

Das öffentliche IETF-Profil ordnet Harkins dem RFC zu; ein öffentliches IEEE-802.11-Anerkennungsfoto ist die Identitätsreferenz des redaktionellen Porträts. Daraus folgt keine Kontrolle über laufende Systeme. Die relevante Leistung des gemeinsam verfassten Standards ist bescheidener und wertvoller: Er macht einen Anfangsnachweis nutzbar, ohne ihm eine nicht geprüfte Verwahrungsgeschichte anzudichten.

Quellen