WireGuard-Schlüssel auf dem ESP32: pro Gerät oder ein fest eingebauter?

Der Sketch legt den privaten WireGuard-Schlüssel in einem Zeichenarray ab, und der Tunnel funktioniert – deshalb kommt die Frage immer wieder auf. Die Entscheidung, die Sie wirklich treffen müssen, lautet nicht „ist das sicher“, sondern „welche der drei Bedingungen trifft auf diese Bereitstellung zu“. Sie lauten: Wer kann das Gerät physisch in der Hand halten, was liefert ein Flash-Lesevorgang bei Ihrem Bauteil, und teilt der Bestand einen Schlüssel oder trägt jedes Gerät einen eigenen. Beantworten Sie das, und das Design folgt, denn jede Bedingung ändert die Kosten eines geleakten Schlüssels, nicht die Tatsache, dass er überhaupt durchsickern kann.

Was der Schlüssel autorisiert

WireGuard authentifiziert Peers über den öffentlichen Schlüssel. Der Server ordnet jedem Peer-Public-Key eine Adresse und eine AllowedIPs-Liste zu, daher erlaubt erst der private Schlüssel einem Client, Verkehr mit dieser Quelladresse zu senden.

Derselbe Eintrag entscheidet, welche Ziele das Gerät erreichen darf, daher legt ein geleakter Schlüssel sowohl das Netz hinter dem Tunnel als auch die Tunneladresse offen.

Bedingung eins: Wer kann das Gerät halten

Steht das Gerät in einem verschlossenen Schrank und niemand außerhalb Ihres Teams fasst es an, ist die Exposition vor allem eine Frage der Firmware-Verteilung. Wird es an Kunden ausgeliefert, steht es in einem Fahrzeug oder kommt es im Rahmen der Garantie zurück, ist der physische Besitz das Credential und die Geheimhaltung des Binaries zweitrangig. Wer das Gerät in der Hand hält, muss den Schlüssel nicht lesen, denn die laufende Firmware öffnet den Tunnel für ihn. Deshalb muss die Antwort auf der Serverseite Widerruf und eine begrenzte Lebensdauer enthalten, nicht nur ein geschütztes Image.

Entscheiden Sie diese Bedingung vor den beiden anderen, denn sie setzt das Budget für beide.

Bedingung zwei: Was ein Flash-Lesevorgang liefert

Wer das Flash-Image lesen kann, gewinnt einen als Literal gespeicherten Schlüssel zurück – über eine Debug-Verbindung, eine Update-Datei, ein Backup oder ein zurückgegebenes Gerät. Flash-Verschlüsselung erhöht die Kosten eines direkten Dumps, und die ESP-IDF-Dokumentation beschreibt, was das Feature für ein gegebenes Bauteil und eine Konfiguration abdeckt. Sie macht den Schlüssel nicht unter jedem Angriffsmodell unextrahierbar und hilft überhaupt nicht, wenn das Gerät in der Hand ist. Behandeln Sie sie als eine Schicht, die Kosten ändert, nicht als die Antwort.

Lesen Sie die Plattformdokumentation für Ihren genauen Chip und Ihre Konfiguration, bevor Sie in einem Design-Review eine Eigenschaft behaupten.

Bedingung drei: Wiederverwendung im Bestand

Ein Schlüssel für eine Produktionsserie bedeutet, dass jedes Gerät dieselbe Identität teilt. Der Server kann sie in den Logs nicht unterscheiden, kann einen nicht widerrufen, ohne alle zu widerrufen, und kann einen Klon nicht von einem Original unterscheiden. Schlüssel pro Gerät beheben alle drei, zum Preis eines Enrollment-Schritts und einer Zuordnung von Seriennummer zu Public Key. Diese Zuordnung ist der Vermögenswert, der einen Widerruf in eine einzeilige Änderung verwandelt statt in ein Neuflashen des gesamten Bestands.

Sind es fünf Geräte auf einer Werkbank, kann ein geteilter Schlüssel ein vernünftiger Kompromiss sein. Sind es fünfhundert im Feld, ist es überhaupt kein Kompromiss.

Das Enrollment-Muster, das Schlüssel pro Gerät praktikabel macht

Erzeugen Sie das Schlüsselpaar beim ersten Start auf dem Gerät, halten Sie die private Hälfte in geschütztem nichtflüchtigem Speicher und senden Sie nur den öffentlichen Schlüssel an einen Enrollment-Dienst, der eine Adresse zuweist und den Peer-Eintrag schreibt. Authentifizieren Sie die Enrollment-Antwort, sonst kann ein Angreifer im lokalen Netz seinen eigenen Schlüssel auf Ihr Konto registrieren. Geben Sie den privaten Schlüssel während der Bereitstellung niemals auf der seriellen Konsole aus. Notieren Sie die Seriennummer des Geräts neben dem öffentlichen Schlüssel, damit ein verlorenes Gerät genau einem Peer-Eintrag entspricht.

Das ist ein kleiner Dienst, und er ist der Unterschied zwischen einem Bestand, den Sie prüfen können, und einem, den Sie nur neu flashen können.

Zeit, Endpunkte und die Entscheidung

Das Beispiel synchronisiert die Zeit vor dem Start des Tunnels, und das zählt über TLS hinaus: WireGuard-Handshakes tragen einen Zeitstempel zum Schutz vor Replay, ein Gerät mit falscher Uhr kann also abgelehnte Handshakes bekommen. Der Endpunkt ist ein Hostname, was DNS in den Vertrauenspfad bringt, obwohl der öffentliche Schlüssel des Servers den Peer weiterhin authentifiziert. Eine falsche Adresse verschwendet Versuche und verrät, wann das Gerät online ist. Klären Sie beides, bevor Sie über den Schlüssel streiten.

Dann entscheiden Sie: ein gemeinsamer Schlüssel nur, solange der Besitz kontrolliert und der Bestand klein ist, Schlüssel pro Gerät, sobald eines von beidem nicht mehr gilt.