Compartir a través de


WiFiCx WPA3 SoftAP

La característica WPA3 SoftAP permite a los dispositivos configurar un punto de acceso temporal (SoftAP) mediante el protocolo de seguridad de acceso protegido Wi-Fi 3 - Autenticación simultánea de iguales (WPA3-SAE). Este SoftAP puede funcionar en la banda de 2,4 GHz o 5 GHz. A partir de la versión 2.0.11 de WDI y WiFiCx versión 1.1, puede integrar la funcionalidad WPA3 SoftAP en el controlador cliente WiFiCx.

WPA3 SoftAP admite WPA3-SAE y un modo de transición WPA3-SAE para la compatibilidad con versiones anteriores. El modo de transición admite los métodos de autenticación WPA2-PSK y WPA3-SAE, lo que garantiza la conectividad Wi-Fi segura en varios dispositivos y entornos.

WPA3 SoftAP solo está disponible en el modelo de controlador WiFiCx. En este artículo se describe cómo agregar compatibilidad con WPA3 SoftAP en el controlador WiFiCx.

Detección de la funcionalidad WPA3 SoftAP

El controlador cliente indica su compatibilidad con WPA3 SoftAP cuando llama a WifiDeviceSetWiFiDirectCapabilities. Esta llamada informa de las funcionalidades de Wi-Fi Direct a WiFiCx. El controlador debe incluir el par de autenticación y cifrado DOT11_AUTH_ALGO_WPA3_SAE + DOT11_CIPHER_ALGO_CCMP en la lista UnicastAlgorithms dentro de la estructura WIFI_WIFIDIRECT_CAPABILITIES.

Un controlador que admita WPA2-PSK y WPA3-SAE con SoftAP debe notificar los siguientes pares de algoritmos de unidifusión:

  • DOT11_AUTH_ALGO_WPA3_SAE + DOT11_CIPHER_ALGO_CCMP
  • DOT11_AUTH_ALGO_RSNA_PSK + DOT11_CIPHER_ALGO_CCMP

La inclusión de estos pares indica a WiFiCx que el controlador admite la función SoftAP en el modo de transición WPA3.

Parámetros de inicio de AP

Windows modifica la tarea OID_WDI_TASK_START_AP de la siguiente manera:

  • El TLV WDI_TLV_AUTH_ALGO_LIST TLV puede incluir WDI_AUTH_ALGO_WPA3_SAE si el controlador indica compatibilidad con WPA3 SoftAP.
  • El TLV de WDI_TLV_AUTH_ALGO_LIST puede incluir WDI_AUTH_ALGO_WPA3_SAE y WDI_AUTH_ALGO_RSNA_PSK. En este caso, el controlador debe anunciar compatibilidad con ambos protocolos de seguridad a través de balizas y respuestas de sondeo, y debe permitir la autenticación de cliente mediante WPA2-PSK o WPA3-SAE.

Soporte técnico de AKM

AKM 0xac0f08 (RSNA_AKM_SAE_PMK256) es el único AKM compatible con WPA3 SoftAP. El controlador no debe anunciar compatibilidad con otros AKM.

Detección de funcionalidades de marcos de administración protegidos (PMF)

El sistema operativo no proporciona una marca específica para PMF en los parámetros de inicio de AP. El controlador debe anunciar las funcionalidades de PMF de la siguiente manera:

Algoritmo de autenticación presente PMF requerido Compatible con PMF
WPA2-PSK No No
WPA3-SAE + WPA2-PSK No
WPA3-SAE

Si el controlador informa de la funcionalidad de WPA3-SAE en SoftAP, el sistema operativo espera que el controlador admita PMF. No hay ninguna funcionalidad de controlador adicional para PMF.

Autenticación SAE para WPA3 SoftAP

En esta sección se describen las actualizaciones de autenticación de SAE para escenarios de SOFTAP WPA3.

Compatibilidad con hash a elemento (H2E) y buscar las teclas una a una

El sistema operativo no proporciona una marca específica para usar H2E solo en los parámetros de inicio de AP. Por lo tanto, los controladores deben indicar de forma coherente que admiten métodos H2E y buscar las teclas una a una para SoftAP.

Tokens antiatasco

El sistema operativo puede responder a una solicitud de confirmación del mismo nivel solicitando un token de antiatasco. El sistema operativo llama a OID_WDI_SET_SAE_AUTH_PARAMS con:

  • El tipo de solicitud WDI_SAE_REQUEST_TYPE_COMMIT_PARAMS o WDI_SAE_REQUEST_TYPE_COMMIT_PARAMS_H2E (si se usa H2E).
  • El marco de confirmación frame StatusCode (WDI_TLV_SAE_COMMIT_PARAMS>WDI_TLV_SAE_STATUS_CODE) establecido en DOT11_FRAME_STATUS_ANTI_CLOGGING_TOKEN_REQUIRED.

El elemento del mismo nivel proporciona un token antiatasco como parte de los parámetros de confirmación.

En un escenario de SoftAP, cuando se incluye un token antiatasco en los parámetros de confirmación, no se generan valores escalares o de elemento. Por lo tanto, estos campos son opcionales en el TLV WDI_TLV_SAE_COMMIT_PARAMS y el controlador debe comprobar su presencia antes de acceder a ellos. Este cambio sigue siendo compatible con los controladores existentes. Los nuevos controladores deben validar la presencia de estos campos opcionales en todas las rutas de acceso.

Grupos rechazados

El sistema operativo solo admite el grupo 19. Si el sistema operativo recibe un marco de confirmación de un elemento del mismo nivel que indica un grupo que el sistema operativo no admite, el sistema operativo envía un comando OID_WDI_SET_SAE_AUTH_PARAMS. En el comando, el sistema operativo establece:

  • WDI_SAE_REQUEST_TYPE para WDI_SAE_REQUEST_TYPE_COMMIT_PARAMS o WDI_SAE_REQUEST_TYPE_COMMIT_H2E_PARAMS (si se usa H2E).
  • SaeStatus para WDI_SAE_STATUS_COMMIT_MESSAGE_UNSUPPORTED_FINITE_GROUP.
  • El marco de confirmación StatusCode (WDI_TLV_SAE_COMMIT_PARAMS>WDI_TLV_SAE_STATUS_CODE) en DOT11_FRAME_STATUS_UNSUPPORTED_FINITE_CYCLIC_GROUP.
  • El marco de confirmación FiniteCyclicGroup (WDI_TLV_SAE_COMMIT_PARAMS>WDI_TLV_SAE_FINITE_CYCLIC_GROUP) al grupo rechazado (no debe confundirse con el campo RejectedGroups, que contiene grupos que rechaza el elemento de mismo nivel).

Si el sistema operativo recibe un marco de confirmación de un par que incluye un grupo dentro del campo RejectedGroups que admite realmente el sistema operativo, el sistema operativo seguirá produciendo un error en la autenticación SAE. El sistema operativo enviará un comando OID_WDI_SET_SAE_AUTH_PARAMS con:

  • WDI_SAE_REQUEST_TYPE establecido en WDI_SAE_REQUEST_TYPE_FAILURE.
  • SaeStatus establecido en WDI_SAE_STATUS_COMMIT_MESSAGE_INVALID_REJECTED_GROUP.

Secuencia de autenticación de SAE

Una vez que se llama a la tarea OID_WDI_TASK_START_AP, el controlador permite que los dispositivos envíen marcos de autenticación SAE si DOT11_AUTH_ALGO_WPA3_SAE está establecido en la lista de algoritmos de autenticación de OID_WDI_TASK_START_AP. El controlador usa la indicación NDIS_STATUS_WDI_INDICATION_SAE_AUTH_PARAMS_NEEDED para pasar los parámetros de autenticación de SAE al sistema operativo.

Windows llama a OID_WDI_SET_SAE_AUTH_PARAMS con WDI_SAE_COMMIT_PARAMS y WDI_SAE_CONFIRM_PARAMS para completar el intercambio de SAE.

Una vez que el controlador recibe los parámetros de confirmación del sistema operativo y los envía al mismo nivel, puede aceptar una solicitud de asociación e indicarlo al sistema operativo.

SoftAP de alto rendimiento

En escenarios como realidad aumentada (AR) o realidad virtual (VR), los controladores deben optimizar el rendimiento de SoftAP tanto como sea posible y priorizarlo a través de la conexión STA. Este proceso implica decisiones estratégicas al iniciar softAP, como la selección de banda/canal y la coexistencia con la conexión STA. También implica la optimización al mantener softAP.

El sistema operativo indica escenarios que requieren SoftAP de alto rendimiento mediante una nueva marca, favorOverSta, en la tarea OID_WDI_TASK_START_AP.

El sistema operativo no indica cómo debe optimizar el controlador el vínculo de SoftAP, dejándolo en gran medida a discreción del controlador. El controlador puede degradar el vínculo STA para mejorar el vínculo de SoftAP.

Cuando el sistema operativo inicia SoftAP con la marca favorOverSta establecida, se autoriza al controlador y se recomienda mover la conexión STA a otra banda o canal si mejora el vínculo de SoftAP.

Si los parámetros de banda o canal solicitados por el sistema operativo entran en conflicto con la conexión STA actual, el controlador debe tener en cuenta si la conexión STA móvil le permitiría iniciar SoftAP con los parámetros solicitados.

Cuando se inicia un softAP con la marca favorOverSta, el sistema operativo podría enviar una tarea OID_WDI_SET_CONNECTION_QUALITY para solicitar un rendimiento optimizado en el vínculo de SoftAP. El controlador debe respetar esta tarea, pero también debe esforzarse por mejorar el vínculo de SoftAP incluso si no recibe requisitos específicos a través de una tarea OID_WDI_SET_CONNECTION_QUALITY.

Comportamiento esperado al mover el puerto STA

El sistema operativo solicita "cualquier" banda/canal:

  • El controlador debe iniciar softAP en la mejor banda o canal, teniendo en cuenta la configuración actual y la conexión STA. Normalmente, la mejor banda o canal es la que usa el vínculo STA. A continuación, el controlador debe completar correctamente la tarea OID_WDI_TASK_START_AP.

    Si mover el STA podría mejorar el vínculo de SoftAP, el controlador puede enviar una solicitud móvil al sistema operativo mediante NDIS_STATUS_WDI_INDICATION_ROAMING_NEEDED. Cuando el movimiento se realiza correctamente, el controlador puede mover el vínculo de SoftAP a una nueva banda o canal que optimizaría el rendimiento.

El sistema operativo solicita una banda o un canal específicos:

  • Si el controlador puede mantener SoftAP en el canal o banda solicitado por el sistema operativo con un rendimiento razonable, debe completar correctamente la tarea OID_WDI_TASK_START_AP.

  • Si el controlador no puede mantener el SoftAP en la banda o canal solicitados, debe comprobar si se cumplen las condiciones siguientes.

    1. Hay disponible un BSS alternativo al que mover el STA.
    2. El controlador puede mantener el SoftAP en el canal o banda solicitado por el sistema operativo después de mover el vínculo STA.
    3. Es poco probable que se produzca un error en el movimiento.

    Si se cumplen estas condiciones, el controlador debe completar OID_WDI_TASK_START_AP correctamente y enviar una solicitud de movimiento para mover la conexión STA.

    De lo contrario, el controlador debe producir un error en la tarea OID_WDI_TASK_START_AP con un código de error pertinente.

Una vez que el controlador complete la tarea OID_WDI_TASK_START_AP, puede enviar una solicitud de movimiento para mover la conexión STA para mantener o mejorar el rendimiento de SoftAP.

Si se produce un error en el movimiento y el controlador no puede mantener el SoftAP sin mover la conexión STA, el controlador debe detener el SoftAP. El controlador informa al sistema operativo enviando NDIS_STATUS_WDI_INDICATION_STOP_AP con un código de motivo pertinente (normalmente, WDI_STOP_AP_REASON_FREQUENCY_NOT_AVAILABLE).

Cuando el SoftAP se detiene, los usuarios pueden notar un efecto de "parpadeo", en el que el SoftAP se inicia y luego se detiene casi instantáneamente. Este comportamiento debe evitarse en la medida de lo posible. Si el controlador requiere un movimiento para mantener el SoftAP, el controlador debe estar seguro de que el movimiento se realizará correctamente antes de completar la tarea OID_WDI_TASK_START_AP.

Códigos de error de SoftAP

Si no se puede iniciar el SoftAP porque no se permite la banda o el canal por un motivo normativo, el controlador debe producir un error en la tarea OID_WDI_TASK_START_AP con el código de error STATUS_NDIS_DOT11_AP_CHANNEL_NOT_ALLOWED o STATUS_NDIS_DOT11_AP_BAND_NOT_ALLOWED.

Si no se puede iniciar el SoftAP porque STA está funcionando en un canal o banda que no es compatible con la banda o canal solicitados, y no hay ningún candidato razonable disponible para el movimiento, el controlador debe producir un error en la tarea OID_WDI_TASK_START_AP con el código de error STATUS_NDIS_DOT11_AP_CHANNEL_CURRENTLY_NOT_AVAILABLE o STATUS_NDIS_DOT11_AP_BAND_CURRENTLY_NOT_AVAILABLE.

Si el SoftAP no se puede iniciar por otro motivo (banda o canal no compatible, problema de controlador genérico, etc.), el controlador debe usar un código de error genérico, como STATUS_NOT_SUPPORTED.

Si no se puede mantener el SoftAP porque era necesario mover la conexión STA, pero se produjo un error en el movimiento, el controlador debe detener el SoftAP con el código de motivo WDI_STOP_AP_REASON_FREQUENCY_NOT_AVAILABLE.