Freigeben über

WiFiCx WPA3 SoftAP

  • Artikel

Die WPA3 SoftAP-Funktion ermöglicht Geräten das Einrichten eines Soft Access Point (SoftAP) mithilfe des WLAN-geschützten Zugriffs 3 – Gleichzeitige Authentifizierung des Wpa3-SAE-Sicherheitsprotokolls (WPA3-SAE). Dieser SoftAP kann entweder im 2,4-GHz- oder im 5-GHz-Band betrieben werden. Ab WDI Version 2.0.11 und WiFiCx, Version 1.1 können Sie WPA3 SoftAP-Funktionen in Ihren WiFiCx-Clienttreiber integrieren.

WPA3 SoftAP unterstützt WPA3-SAE und einen WPA3-SAE-Übergangsmodus zur Abwärtskompatibilität. Der Übergangsmodus unterstützt sowohl die Authentifizierungsmethoden WPA2-PSK als auch WPA3-SAE und stellt so eine sichere WLAN-Konnektivität über verschiedene Geräte und Umgebungen hinweg sicher.

WPA3 SoftAP ist nur im WiFiCx-Treibermodell verfügbar. In diesem Artikel wird beschrieben, wie Sie Unterstützung für WPA3 SoftAP in Ihrem WiFiCx-Treiber hinzufügen.

WPA3 SoftAP-Funktionserkennung

Ihr Clienttreiber gibt seine Unterstützung für WPA3 SoftAP an, wenn er WifiDeviceSetWiFiDirectCapabilities aufruft. Dieser Aufruf meldet Wi-Fi Direct-Funktionen an WiFiCx. Der Treiber muss das Authentifizierungs- und Verschlüsselungspaar DOT11_AUTH_ALGO_WPA3_SAE + DOT11_CIPHER_ALGO_CCMP in der UnicastAlgorithms-Liste innerhalb der WIFI_WIFIDIRECT_CAPABILITIES-Struktur enthalten.

Ein Treiber, der sowohl WPA2-PSK als auch WPA3-SAE mit SoftAP unterstützt, muss die folgenden Unicast-Algorithmuspaare melden:

  • DOT11_AUTH_ALGO_WPA3_SAE + DOT11_CIPHER_ALGO_CCMP
  • DOT11_AUTH_ALGO_RSNA_PSK + DOT11_CIPHER_ALGO_CCMP

Das Auflisten dieser Paare signalisiert WiFiCx, dass der Treiber die SoftAP-Funktion im WPA3-Übergangsmodus unterstützt.

AP-Startparameter

Windows ändert die OID_WDI_TASK_START_AP-Aufgabe wie folgt:

  • Der WDI_TLV_AUTH_ALGO_LIST TLV kann WDI_AUTH_ALGO_WPA3_SAE enthalten, wenn der Treiber Unterstützung für WPA3 SoftAP angibt.
  • Der WDI_TLV_AUTH_ALGO_LIST TLV kann sowohl WDI_AUTH_ALGO_WPA3_SAE als auch WDI_AUTH_ALGO_RSNA_PSK enthalten. In diesem Fall muss der Treiber Unterstützung für beide Sicherheitsprotokolle über Beacons und Testantworten ankündigen und die Clientauthentifizierung mithilfe von WPA2-PSK oder WPA3-SAE zulassen.

AKM-Support

AKM 0xac0f08 (RSNA_AKM_SAE_PMK256) ist das einzige AKM, das für WPA3 SoftAP unterstützt wird. Der Treiber darf keine Unterstützung für andere AKMs ankündigen.

Erkennung geschützter Verwaltungsframes (PMF)

Das Betriebssystem stellt in den AP-Startparametern kein bestimmtes Flag für PMF bereit. Der Treiber muss PMF-Funktionen wie folgt ankündigen:

Authentifizierungsalgorithmus vorhanden PMF erforderlich PMF-fähig
WPA2-PSK No No
WPA3-SAE + WPA2-PSK No Ja
WPA3-SAE Ja Ja

Wenn der Treiber die Funktion für WPA3-SAE auf SoftAP meldet, erwartet das Betriebssystem, dass der Treiber PMF unterstützt. Es gibt keine zusätzliche Treiberfunktion für PMF.

SAE-Authentifizierung für WPA3 SoftAP

In diesem Abschnitt werden SAE-Authentifizierungsupdates für WPA3-SoftAP-Szenarien beschrieben.

Hash-to-Element (H2E)- und Hunt and Peck-Unterstützung

Das Betriebssystem stellt kein spezielles Flag für die Verwendung von H2E nur in den AP-Startparametern bereit. Daher müssen Treiber durchgängig angeben, dass sie sowohl H2E- als auch Hunt-and-Peck-Methoden für SoftAP unterstützen.

Anti-Clogging-Token

Das Betriebssystem könnte auf eine Peer-Commit-Anforderung mit der Anforderung eines Anti-Clogging-Tokens reagieren. Das Betriebssystem ruft OID_WDI_SET_SAE_AUTH_PARAMS mit folgender Angabe auf:

  • Der Anforderungstyp WDI_SAE_REQUEST_TYPE_COMMIT_PARAMS oder WDI_SAE_REQUEST_TYPE_COMMIT_PARAMS_H2E (bei Verwendung von H2E).
  • Der Commit-Frame StatusCode (WDI_TLV_SAE_COMMIT_PARAMS>WDI_TLV_SAE_STATUS_CODE), der auf DOT11_FRAME_STATUS_ANTI_CLOGGING_TOKEN_REQUIRED festgelegt ist.

Der Peer stellt ein Anti-Clogging-Token als Teil der Commitparameter bereit.

Wenn in einem SoftAP-Szenario ein Anti-Clogging-Token in den Commit-Parametern enthalten ist, werden Skalar/Elementwerte nicht generiert. Daher sind diese Felder im TLV WDI_TLV_SAE_COMMIT_PARAMS optional und der Treiber sollte vor dem Zugriff auf sie überprüfen, ob sie vorhanden sind. Diese Änderung bleibt mit vorhandenen Treibern kompatibel. Neue Treiber sollten das Vorhandensein dieser optionalen Felder in allen Pfaden überprüfen.

Abgelehnte Gruppen

Das Betriebssystem unterstützt nur Gruppe 19. Wenn das Betriebssystem einen Commit-Frame von einem Peer empfängt, der eine Gruppe angibt, die vom Betriebssystem nicht unterstützt wird, sendet das Betriebssystem einen OID_WDI_SET_SAE_AUTH_PARAMS-Befehl. Im Befehl legt das Betriebssystem Folgendes fest:

  • WDI_SAE_REQUEST_TYPE auf WDI_SAE_REQUEST_TYPE_COMMIT_PARAMS oder WDI_SAE_REQUEST_TYPE_COMMIT_H2E_PARAMS (bei Verwendung von H2E).
  • SaeStatus auf WDI_SAE_STATUS_COMMIT_MESSAGE_UNSUPPORTED_FINITE_GROUP.
  • Der Commit-Frame StatusCode (WDI_TLV_SAE_COMMIT_PARAMS>WDI_TLV_SAE_STATUS_CODE) auf DOT11_FRAME_STATUS_UNSUPPORTED_FINITE_CYCLIC_GROUP.
  • Der Commit-Frame FiniteCyclicGroup (WDI_TLV_SAE_COMMIT_PARAMS>WDI_TLV_SAE_FINITE_CYCLIC_GROUP) für die abgelehnte Gruppe (nicht zu verwechseln mit dem Feld RejectedGroups, welches Gruppen enthält, die der Peer ablehnt).

Wenn das Betriebssystem einen Commit-Frame von einem Peer empfängt, der eine Gruppe innerhalb des Felds RejectedGroups enthält, das vom Betriebssystem tatsächlich unterstützt wird, schlägt das Betriebssystem die SAE-Authentifizierung weiterhin fehl. Das Betriebssystem sendet einen OID_WDI_SET_SAE_AUTH_PARAMS-Befehl mit:

  • WDI_SAE_REQUEST_TYPE, das aufWDI_SAE_REQUEST_TYPE_FAILURE festgelegt ist.
  • SaeStatus, der auf WDI_SAE_STATUS_COMMIT_MESSAGE_INVALID_REJECTED_GROUP festgelegt ist.

SAE-Authentifizierungssequenz

Nachdem die OID_WDI_TASK_START_AP-Aufgabe aufgerufen wurde, ermöglicht der Treiber Geräten das Senden von SAE-Authentifizierungsframes, wenn DOT11_AUTH_ALGO_WPA3_SAE in der Liste der Authentifizierungsalgorithmen in OID_WDI_TASK_START_AP festgelegt ist. Der Treiber verwendet die NDIS_STATUS_WDI_INDICATION_SAE_AUTH_PARAMS_NEEDED-Angabe, um die SAE-Authentifizierungsparameter an das Betriebssystem zu übergeben.

Windows ruft OID_WDI_SET_SAE_AUTH_PARAMS mit WDI_SAE_COMMIT_PARAMS und WDI_SAE_CONFIRM_PARAMS auf, um den SAE-Austausch abzuschließen.

Nachdem der Treiber die Bestätigungsparameter vom Betriebssystem erhalten und an den Peer gesendet hat, kann er eine Zuordnungsanforderung annehmen und sie dem Betriebssystem mitteilen.

Hochleistungs-SoftAP

Für Szenarien wie Augmented Reality (AR) oder Virtual Reality (VR) sollten Treiber die SoftAP-Leistung so weit wie möglich optimieren und über die STA-Verbindung priorisieren. Dieser Prozess umfasst strategische Entscheidungen beim Starten des SoftAP, z. B. die Auswahl von Band/Kanal und die Koexistenz mit der STA-Verbindung. Es umfasst auch eine Optimierung bei gleichzeitiger Aufrechterhaltung des SoftAP.

Das Betriebssystem weist mit einem neuen Flag auf Szenarien hin, die ein leistungsstarkes SoftAP unter Verwendung eines neuen favorOverSta in der OID_WDI_TASK_START_AP-Aufgabe erfordern.

Das Betriebssystem schreibt dem Treiber nicht vor, wie er die SoftAP-Verbindung optimieren soll, dies bleibt weitgehend dem Ermessen des Treibers überlassen. Der Treiber kann die STA-Verbindung beeinträchtigen, um die SoftAP-Verbindung zu verbessern.

Wenn das Betriebssystem SoftAP bei festgelegtem Set favorOverSta-Flag initiiert, wird der Treiber autorisiert und ermutigt, die STA-Verbindung mit einem anderen Band/Kanal zu roamen, wenn die SoftAP-Verknüpfung verbessert wird.

Wenn die vom Betriebssystem angeforderten Band-/Kanalparameter mit der aktuellen STA-Verbindung in Konflikt geraten, sollte der Treiber überlegen, ob das Roaming der STA-Verbindung es ermöglichen würde, das SoftAP mit den angeforderten Parametern zu starten.

Wenn ein SoftAP mit dem favorOverSta-Flag gestartet wird, sendet das Betriebssystem möglicherweise eine OID_WDI_SET_CONNECTION_QUALITY-Aufgabe, um eine optimierte Leistung in der SoftAP-Verbindung anzufordern. Der Treiber sollte diese Aufgabe berücksichtigen, aber auch versuchen, die SoftAP-Verbindung zu verbessern, auch wenn er keine spezifischen Anforderungen über eine OID_WDI_SET_CONNECTION_QUALITY-Aufgabe erhält.

Erwartetes Verhalten beim Roaming des STA-Ports

Das Betriebssystem fordert „jedes“ Band/„jeden“ Kanal an:

  • Der Treiber sollte den SoftAP unter Berücksichtigung der aktuellen Konfiguration und STA-Verbindung auf dem besten Band/Kanal starten. Normalerweise ist das beste Band/der beste Kanal das bzw. der von der STA-Verbindung verwendete. Der Treiber sollte dann die OID_WDI_TASK_START_AP-Aufgabe erfolgreich abschließen.

    Wenn das Verschieben des STA die SoftAP-Verbindung möglicherweise verbessern könnte, kann der Treiber eine Roaminganforderung mithilfe von NDIS_STATUS_WDI_INDICATION_ROAMING_NEEDED an das Betriebssystem senden. Wenn das Roaming erfolgreich verläuft, kann der Treiber die SoftAP-Verbindung zu einem neuen Band/Kanal verschieben, der die Leistung optimieren würde.

Das Betriebssystem fordert ein bestimmtes Band/einen bestimmten Kanal an:

  • Wenn der Treiber den SoftAP auf dem vom Betriebssystem angeforderten Band/Kanal mit einer angemessenen Leistung unterstützen kann, sollte er die OID_WDI_TASK_START_AP-Aufgabe erfolgreich abschließen.

  • Wenn der Treiber den SoftAP derzeit nicht auf dem angeforderten Band/Kanal erhalten kann, sollte überprüft werden, ob die folgenden Bedingungen erfüllt sind.

    1. Eine alternative BSS steht für das Roaming von STA zur Verfügung.
    2. Der Treiber kann den SoftAP auf dem vom Betriebssystem angeforderten Band/Kanal nach dem Roaming der STA-Verbindung erhalten.
    3. Es ist unwahrscheinlich, dass das Roaming fehlschlägt.

    Wenn diese Bedingungen erfüllt sind, sollte der Treiber OID_WDI_TASK_START_AP erfolgreich abschließen und eine Roaminganforderung senden, um die STA-Verbindung zu verschieben.

    Andernfalls sollte der Treiber die OID_WDI_TASK_START_AP-Aufgabe mit einem relevanten Fehlercode nicht ausführen.

Nachdem der Treiber die Aufgabe OID_WDI_TASK_START_AP abgeschlossen hat, kann er eine Roaming-Anfrage senden, um die STA-Verbindung zu verschieben und so die SoftAP-Leistung aufrechtzuerhalten oder zu verbessern.

Wenn das Roaming fehlschlägt und der Treiber den SoftAP nicht aufrechterhalten kann, ohne die STA-Verbindung zu verschieben, sollte der Treiber den SoftAP stoppen. Der Treiber informiert das Betriebssystem durch Senden von NDIS_STATUS_WDI_INDICATION_STOP_AP mit einem relevanten Grundcode (in der Regel WDI_STOP_AP_REASON_FREQUENCY_NOT_AVAILABLE).

Wenn der SoftAP beendet wird, bemerken Benutzer möglicherweise einen „flackernden“ Effekt, bei dem der SoftAP startet und dann fast umgehend anhält. Dieses Verhalten sollte möglichst vermieden werden. Wenn der Treiber ein Roaming erfordert, um den SoftAP aufrechtzuerhalten, sollte der Treiber sicher sein, dass das Roaming erfolgreich ist, bevor die OID_WDI_TASK_START_AP-Aufgabe abgeschlossen wird.

SoftAP-Fehlercodes

Wenn der SoftAP nicht gestartet werden kann, da das Band/der Kanal aus einem regulatorischen Grund nicht zulässig ist, sollte der Treiber die OID_WDI_TASK_START_AP-Aufgabe mit dem Fehlercode STATUS_NDIS_DOT11_AP_CHANNEL_NOT_ALLOWED oder STATUS_NDIS_DOT11_AP_BAND_NOT_ALLOWED nicht ausführen.

Wenn der SoftAP nicht gestartet werden kann, weil die STA auf einem Band/Kanal arbeitet, der mit dem angeforderten Band/Kanal nicht kompatibel ist, und kein geeigneter Kandidat für das Roaming verfügbar ist, sollte der Treiber die Aufgabe OID_WDI_TASK_START_AP mit dem Fehlercode STATUS_NDIS_DOT11_AP_CHANNEL_CURRENTLY_NOT_AVAILABLE oder STATUS_NDIS_DOT11_AP_BAND_CURRENTLY_NOT_AVAILABLE fehlschlagen lassen.

Wenn der SoftAP aus einem anderen Grund nicht gestartet werden kann (nicht unterstütztes Band/Kanal, allgemeines Treiberproblem usw.), sollte der Treiber einen generischen Fehlercode verwenden, z. B. STATUS_NOT_SUPPORTED.

Wenn der SoftAP nicht aufrechterhalten werden kann, weil ein Roaming der STA-Verbindung erforderlich war, das Roaming jedoch fehlgeschlagen ist, sollte der Treiber den SoftAP mit dem Ursachencode WDI_STOP_AP_REASON_FREQUENCY_NOT_AVAILABLE stoppen.