SoftAP WPA3 WiFiCx
La fonctionnalité WPA3 SoftAP permet aux appareils de configurer un point d’accès logiciel (SoftAP) utilisant le protocole de sécurité Access 3 - Simultaneous Authentication of Equals (WPA3-SAE). Ce SoftAP peut fonctionner sur la bande de 2,4 GHz ou de 5 GHz. À partir de la version 2.0.11 de WDI et de la version 1.1 de WiFiCx, vous pouvez intégrer la fonctionnalité WPA3 SoftAP dans votre pilote client WiFiCx.
WPA3 SoftAP prend en charge WPA3-SAE et un mode de transition WPA3-SAE pour une compatibilité descendante. Le mode de transition s’adapte aux méthodes d’authentification WPA2-PSK et WPA3-SAE, garantissant une connectivité Wi-Fi sécurisée entre plusieurs appareils et environnements.
WPA3 SoftAP est disponible uniquement sur le modèle de pilote WiFiCx. Cet article explique comment ajouter la prise en charge WPA3 SoftAP à votre pilote WiFiCx.
Détection de la fonctionnalité SoftAP WPA3
Votre pilote client indique sa prise en charge de WPA3 SoftAP quand il appelle WifiDeviceSetWiFiDirectCapabilities. Cet appel communique les fonctionnalités directes Wi-Fi à WiFiCx. Le pilote doit inclure la paire d’authentification et de chiffrement DOT11_AUTH_ALGO_WPA3_SAE + DOT11_CIPHER_ALGO_CCMP dans la liste UnicastAlgorithms de la structure WIFI_WIFIDIRECT_CAPABILITIES.
Un pilote qui prend en charge à la fois WPA2-PSK et WPA3-SAE avec SoftAP doit communiquer les paires d’algorithmes monodiffusion suivantes :
- DOT11_AUTH_ALGO_WPA3_SAE + DOT11_CIPHER_ALGO_CCMP
- DOT11_AUTH_ALGO_RSNA_PSK + DOT11_CIPHER_ALGO_CCMP
Le fait de lister ces paires signale à WiFiCx que le pilote prend en charge la fonctionnalité SoftAP en mode de transition WPA3.
Paramètres de démarrage du point d'accès
Windows modifie la tâche OID_WDI_TASK_START_AP de la manière suivante :
- La TLV WDI_TLV_AUTH_ALGO_LIST peut inclure WDI_AUTH_ALGO_WPA3_SAE si le pilote indique la prise en charge de WPA3 SoftAP.
- La TLV WDI_TLV_AUTH_ALGO_LIST peut inclure à la fois WDI_AUTH_ALGO_WPA3_SAE et WDI_AUTH_ALGO_RSNA_PSK. Dans ce cas, le pilote doit annoncer la prise en charge des deux protocoles de sécurité via des balises et des réponses probe, et doit autoriser l’authentification du client avec WPA2-PSK ou WPA3-SAE.
Prise en charge de AKM
AKM 0xac0f08 (RSNA_AKM_SAE_PMK256) est le seul AKM pris en charge pour WPA3 SoftAP. Le pilote ne doit pas annoncer la prise en charge d’autres AKM.
Détection de la fonctionnalité Trames de gestion protégées (PMF)
Le système d’exploitation ne fournit pas d’indicateur spécifique pour PMF dans les paramètres de démarrage du point d'accès. Le pilote doit annoncer les fonctionnalités PMF comme suit :
Algorithme d’authentification présent | PMF requis | Prise en charge PMF |
---|---|---|
WPA2-PSK | Non | Non |
WPA3-SAE + WPA2-PSK | Non | Oui |
WPA3-SAE | Oui | Oui |
Si le pilote indique la fonctionnalité WPA3-SAE sur SoftAP, le système d’exploitation s'attend à ce que le pilote prenne en charge PMF. Il n’y a aucune autre fonctionnalité de pilote pour PMF.
Authentification SAE pour WPA3 SoftAP
Cette section décrit les mises à jour de l’authentification SAE pour les scénarios WPA3 SoftAP.
Prise en charge des méthodes Hash-to-Element (H2E) et Hunt and Peck
Le système d’exploitation ne fournit pas d’indicateur spécifique pour la seule utilisation de H2E dans les paramètres de démarrage du point d'accès. Par conséquent, les pilotes doivent constamment indiquer qu’ils prennent en charge à la fois la méthode H2E et la méthode Hunt and Peck pour SoftAP.
Jetons anti-clogging
Le système d’exploitation peut répondre à une requête de validation d’homologue en demandant un jeton anti-clogging. Le système d’exploitation appelle OID_WDI_SET_SAE_AUTH_PARAMS avec :
- Le type de requête WDI_SAE_REQUEST_TYPE_COMMIT_PARAMS ou WDI_SAE_REQUEST_TYPE_COMMIT_PARAMS_H2E (si H2E est utilisé).
- La trame de validation StatusCode (WDI_TLV_SAE_COMMIT_PARAMS>WDI_TLV_SAE_STATUS_CODE) définie sur DOT11_FRAME_STATUS_ANTI_CLOGGING_TOKEN_REQUIRED.
L’homologue fournit un jeton anti-clogging inclus dans les paramètres de validation.
Dans un scénario SoftAP, lorsqu’un jeton anti-clogging est inclus dans les paramètres de validation, les valeurs Scalar/Element ne sont pas générées. Pour cette raison, les champs sont facultatifs dans la TLV WDI_TLV_SAE_COMMIT_PARAMS, et le pilote doit vérifier leur présence avant d'y accéder. Cette modification reste compatible avec les pilotes existants. Les nouveaux pilotes doivent valider la présence de ces champs facultatifs dans tous les chemins d’accès.
Groupes rejetés
Le système d’exploitation ne prend en charge que le Groupe 19. Si le système d’exploitation reçoit une trame de validation d’un homologue indiquant un groupe qu'il ne prend pas en charge, il envoie une commande OID_WDI_SET_SAE_AUTH_PARAMS. Dans cette commande, le système d’exploitation définit :
- WDI_SAE_REQUEST_TYPE sur WDI_SAE_REQUEST_TYPE_COMMIT_PARAMS ou WDI_SAE_REQUEST_TYPE_COMMIT_H2E_PARAMS (si c'est H2E qui est utilisé).
- SaeStatus sur WDI_SAE_STATUS_COMMIT_MESSAGE_UNSUPPORTED_FINITE_GROUP.
- La trame de validation StatusCode (WDI_TLV_SAE_COMMIT_PARAMS>WDI_TLV_SAE_STATUS_CODE) sur DOT11_FRAME_STATUS_UNSUPPORTED_FINITE_CYCLIC_GROUP.
- La trame de validation FiniteCyclicGroup (WDI_TLV_SAE_COMMIT_PARAMS>WDI_TLV_SAE_FINITE_CYCLIC_GROUP) sur le groupe rejeté (ne pas confondre avec le champ RejectedGroups, qui contient les groupes rejetés par l'homologue).
Si le système d’exploitation reçoit une trame de validation d’un homologue incluant un groupe qu'il prend en charge dans le champ RejectedGroups, il échouera toujours à l’authentification SAE. Le système d’exploitation envoie une commande OID_WDI_SET_SAE_AUTH_PARAMS avec :
- WDI_SAE_REQUEST_TYPE sur WDI_SAE_REQUEST_TYPE_FAILURE.
- SaeStatus sur WDI_SAE_STATUS_COMMIT_MESSAGE_INVALID_REJECTED_GROUP.
Séquence d’authentification SAE
Une fois la tâche OID_WDI_TASK_START_AP appelée, le pilote permet aux appareils d'envoyer des trames d'authentification SAE si DOT11_AUTH_ALGO_WPA3_SAE est inclus dans la liste des algorithmes d'authentication de OID_WDI_TASK_START_AP. Le pilote utilise l’indication NDIS_STATUS_WDI_INDICATION_SAE_AUTH_PARAMS_NEEDED pour transmettre les paramètres d’authentification SAE au système d’exploitation.
Windows appelle OID_WDI_SET_SAE_AUTH_PARAMS avec WDI_SAE_COMMIT_PARAMS et WDI_SAE_CONFIRM_PARAMS pour mettre fin à l’échange SAE.
Une fois que le pilote reçoit les paramètres de confirmation du système d’exploitation et les envoie à l’homologue, il peut accepter une requête d’association et l’indiquer au système d’exploitation.
SoftAP à haute performance
Pour les scénarios de type réalité augmentée (AR) ou réalité virtuelle (VR), les pilotes doivent autant que possible optimiser les performances du SoftAP et lui donner la priorité sur la connexion STA. Ce processus implique des décisions stratégiques lors du démarrage du SoftAP, comme la sélection de la bande ou du canal et la coexistence avec la connexion STA. Il implique également une optimisation tant que le SoftAP est conservé.
Le système d’exploitation indique des scénarios nécessitant un SoftAP à haute performance à l’aide d’un nouvel indicateur, favorOverSta, dans la tâche OID_WDI_TASK_START_AP.
Le système d’exploitation ne dicte pas la façon dont le pilote doit optimiser la liaison SoftAP, et laisse ce choix dans une large mesure à celui-ci. Le pilote peut dégrader la liaison STA en faveur de la liaison SoftAP.
Lorsque le système d’exploitation lance SoftAP avec l’indicateur favorOverSta, le pilote est autorisé et encouragé à activer l'itinérance de la connexion STA pour l'acheminer vers une autre bande ou un autre canal en vue d'améliorer la liaison SoftAP.
Si les paramètres de bande/canal requis par le système d’exploitation sont en conflit avec la connexion STA actuelle, le pilote doit déterminer si l’itinérance de la connexion STA lui permettrait de démarrer le SoftAP avec les paramètres requis.
Lorsqu’un SoftAP ayant démarré avec l’indicateur favorOverSta est en cours d’exécution, le système d’exploitation peut envoyer une tâche OID_WDI_SET_CONNECTION_QUALITY pour demander une optimisation des performances sur la liaison SoftAP. Le pilote doit respecter cette tâche, mais il doit aussi s’efforcer d’améliorer la liaison SoftAP, même s’il ne reçoit pas d’exigences spécifiques à travers une tâche OID_WDI_SET_CONNECTION_QUALITY.
Comportement attendu pendant l’itinérance du port STA
Le système d’exploitation demande une bande ou un canal « quelconque » :
Le pilote doit démarrer le SoftAP sur la meilleure bande ou le meilleur canal, compte tenu de la configuration actuelle et de la connexion STA. En règle générale, la meilleure bande/le meilleur canal est celle/celui utilisé(e) par la liaison STA. Le pilote doit ensuite mettre fin de façon satisfaisante à la tâche OID_WDI_TASK_START_AP.
Si le déplacement de la connexion STA peut potentiellement améliorer la liaison SoftAP, le pilote peut envoyer une requête d'itinérance au système d’exploitation à travers NDIS_STATUS_WDI_INDICATION_ROAMING_NEEDED. Une fois l’itinérance réussie, le pilote peut déplacer la liaison SoftAP vers une nouvelle bande/un nouveau canal susceptible d'optimiser les performances.
Le système d’exploitation envoie une requête de bande/canal spécifique :
Si le pilote peut maintenir le SoftAP sur la bande/le canal demandé(e) par le système d’exploitation avec des performances raisonnables, il doit mettre fin correctement à la tâche OID_WDI_TASK_START_AP.
Si le pilote ne peut actuellement pas maintenir le SoftAP sur la bande/le canal demandé(e), il doit vérifier si les conditions suivantes sont remplies.
- Une autre solution BSS est disponible pour pouvoir y acheminer la STA.
- Le pilote peut maintenir le SoftAP sur la bande/le canal demandé(e) par le système d’exploitation après avoir activé l'itinérance de la liaison STA.
- Il est peu probable que l’itinérance échoue.
Si ces conditions sont remplies, le pilote doit mettre fin de façon satisfaisante à OID_WDI_TASK_START_AP et envoyer une requête d'itinérance pour déplacer la connexion STA.
Dans le cas contraire, le pilote doit faire échouer la tâche OID_WDI_TASK_START_AP en produisant un code d’erreur approprié.
Une fois que le pilote a exécuté la tâche OID_WDI_TASK_START_AP, il peut envoyer une requête d'itinérance pour déplacer la connexion STA en vue de maintenir ou d'améliorer les performances du SoftAP.
Si l’itinérance échoue et que le pilote ne peut pas maintenir le SoftAP sans déplacer la connexion STA, il doit arrêter le SoftAP. Le pilote informe le système d’exploitation en envoyant NDIS_STATUS_WDI_INDICATION_STOP_AP avec un code de motif approprié (généralement, WDI_STOP_AP_REASON_FREQUENCY_NOT_AVAILABLE).
Lorsque le SoftAP s’arrête, les utilisateurs peuvent remarquer un effet de « scintillement », dans lequel le SoftAP démarre pour s’arrêter presque instantanément. Ce comportement doit être évité autant que possible. Si le pilote a besoin d’une itinérance pour maintenir le SoftAP, il doit être sûr que l’itinérance va réussir avant de mettre fin à la tâche OID_WDI_TASK_START_AP.
Codes d’erreur SoftAP
Si le SoftAP ne peut pas être démarré car la bande/le canal n’est pas autorisé(e) pour un motif d'ordre réglementaire, le pilote doit faire échouer la tâche OID_WDI_TASK_START_AP en produisant le code d'erreur STATUS_NDIS_DOT11_AP_CHANNEL_NOT_ALLOWED ou STATUS_NDIS_DOT11_AP_BAND_NOT_ALLOWED.
Si le SoftAP ne peut pas être démarré, car le STA fonctionne sur une bande ou un canal incompatible avec la bande ou le canal demandé et qu'aucun candidat raisonnable n’est disponible pour l’itinérance, le pilote doit faire échouer la tâche OID_WDI_TASK_START_AP en produisant le code d'erreur STATUS_NDIS_DOT11_AP_CHANNEL_CURRENTLY_NOT_AVAILABLE ou STATUS_NDIS_DOT11_AP_BAND_CURRENTLY_NOT_AVAILABLE.
Si le SoftAP ne peut pas être démarré pour tout autre motif (bande ou canal non pris en charge, problème générique du pilote, etc.), le pilote doit utiliser un code d’erreur générique, tel que STATUS_NOT_SUPPORTED.
Si le SoftAP ne peut pas être maintenu, car il aurait fallu activer l’itinérance de la connexion STA, mais que le mode d'itinérance a échoué, le pilote doit arrêter le SoftAP avec le code de motif WDI_STOP_AP_REASON_FREQUENCY_NOT_AVAILABLE.