Punto de acceso (punto de acceso 2.0)

Passpoint es un protocolo de Wi-Fi Alliance (WFA) que permite a los dispositivos móviles descubrir y autenticarse en puntos de acceso Wi-Fi que brindan acceso a Internet.

Soporte de dispositivo

Para admitir Passpoint, los fabricantes de dispositivos deben implementar la interfaz Supplicant. A partir de Android 13, la interfaz utiliza AIDL para la definición de HAL. Para versiones anteriores a Android 13, las interfaces y particiones de proveedores utilizan HIDL. Los archivos HIDL están en hardware/interfaces/supplicant/1.x y los archivos AIDL están en hardware/interfaces/supplicant/aidl . El solicitante brinda soporte para el estándar 802.11u, específicamente funciones de selección y descubrimiento de redes, como el Servicio de publicidad genérica (GAS) y el protocolo de consulta de red de acceso (ANQP).

Implementación

Android 11 o superior

Para admitir Passpoint en dispositivos con Android 11 o superior, los fabricantes de dispositivos deben proporcionar soporte de firmware para 802.11u. Todos los demás requisitos para admitir Passpoint están incluidos en AOSP.

Android 10 o inferior

Para dispositivos que ejecutan Android 10 o versiones anteriores, los fabricantes de dispositivos deben proporcionar soporte tanto para el marco como para HAL/firmware:

  • Marco: habilitar Passpoint (requiere un indicador de función)
  • Firmware: soporte para 802.11u

Para admitir Passpoint, implemente Wi-Fi HAL y habilite el indicador de función para Passpoint. En device.mk ubicado en device/<oem>/<device> , modifique la variable de entorno PRODUCT_COPY_FILES para incluir compatibilidad con la función Passpoint:

PRODUCT_COPY_FILES +=
frameworks/native/data/etc/android.hardware.wifi.passpoint.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.wifi.passpoint.xml

Todos los demás requisitos para admitir Passpoint están incluidos en AOSP.

Validación

Para validar su implementación de la función Passpoint, utilice el conjunto de pruebas unitarias y pruebas de integración proporcionadas en Android Comms Test Suite (ACTS).

Pruebas unitarias

Ejecute las siguientes pruebas unitarias del paquete Passpoint.

Pruebas de servicio:

atest com.android.server.wifi.hotspot2

Pruebas de gerente:

atest android.net.wifi.hotspot2

Pruebas de integración (ACTS)

El conjunto de pruebas ACTS Passpoint, ubicado en tools/test/connectivity/acts_tests/tests/google/wifi/WifiPasspointTest.py , implementa un conjunto de pruebas funcionales.

Aprovisionamiento del punto de paso R1

Android ha admitido Passpoint R1 desde Android 6.0, lo que permite el aprovisionamiento de credenciales de Passpoint R1 (versión 1) mediante la descarga basada en web de un archivo especial que contiene información de perfil y credenciales. El cliente inicia automáticamente un instalador especial para la información de Wi-Fi y permite al usuario ver partes de la información antes de aceptar o rechazar el contenido.

La información del perfil contenida en el archivo se utiliza para hacer coincidir los datos recuperados de los puntos de acceso habilitados para Passpoint, y las credenciales se aplican automáticamente para cualquier red coincidente.

La implementación de referencia de Android admite EAP-TTLS, EAP-TLS, EAP-SIM, EAP-AKA y EAP-AKA'.

Mecanismo de descarga

El archivo de configuración de Passpoint debe estar alojado en un servidor web y debe protegerse con TLS (HTTPS) porque puede contener contraseñas de texto sin cifrar o datos de clave privada. El contenido se compone de texto MIME multiparte empaquetado representado en UTF-8 y codificado en base64 según la sección 6.8 de RFC-2045.

El cliente utiliza los siguientes campos de encabezado HTTP para iniciar automáticamente un instalador de Wi-Fi en el dispositivo:

  • Content-Type debe configurarse en application/x-wifi-config .
  • Content-Transfer-Encoding debe configurarse en base64 .
  • No se debe establecer Content-Disposition .

El método HTTP utilizado para recuperar el archivo debe ser GET. Cada vez que un HTTP GET del navegador recibe una respuesta con estos encabezados MIME, se inicia la aplicación de instalación. La descarga debe activarse tocando un elemento HTML, como un botón (no se admiten redireccionamientos automáticos a una URL de descarga). Este comportamiento es específico de Google Chrome; otros navegadores web pueden proporcionar o no una funcionalidad similar.

Composición del archivo

El contenido codificado en Base64 debe consistir en contenido MIME multiparte con un Content-Type multipart/mixed . Las siguientes partes constituyen las partes individuales del contenido de varias partes.

Parte Tipo de contenido (menos comillas) Requerido Descripción
Perfil application/x-passpoint-profile Siempre Carga útil formateada OMA-DM SyncML que contiene el MO formateado Passpoint R1 PerProviderSubscription para HomeSP y Credential .
Certificado de confianza application/x-x509-ca-cert Requerido para EAP-TLS y EAP-TTLS Una única carga útil de certificado codificado en base64 X.509v3.
Clave EAP-TLS application/x-pkcs12 Requerido para EAP-TLS Una estructura PKCS #12 ASN.1 codificada en base64 que contiene una cadena de certificados de cliente con al menos el certificado de cliente y la clave privada asociada. El contenedor PKCS 12, así como la clave privada y los certificados, deben estar en texto sin cifrar y sin contraseña.

La sección Perfil debe transferirse como texto XML codificado en base64 y UTF-8 que especifica partes de los subárboles HomeSP y Credential en la Especificación técnica de Passpoint R2, versión 1.0.0, sección 9.1.

El nodo de nivel superior debe ser MgmtTree y el subnodo inmediato debe ser PerProviderSubscription . Aparece un archivo XML de ejemplo en Perfil de ejemplo OMA-DM XML .

Los siguientes nodos de subárbol se utilizan en HomeSP :

  • FriendlyName : debe configurarse; utilizado como texto de visualización
  • FQDN : Requerido
  • RoamingConsortiumOI

Los siguientes nodos de subárbol se utilizan en Credential :

  • Realm : debe ser una cadena no vacía

  • UsernamePassword : Requerido para EAP-TTLS con los siguientes nodos configurados:

    • Username : Cadena que contiene el nombre de usuario
    • Password : cadena codificada en Base64 (establecida en cGFzc3dvcmQ= , la cadena codificada en base64 para "contraseña", en el siguiente ejemplo)
    • EAPMethod/EAPType : debe establecerse en 21
    • EAPMethod/InnerMethod : debe configurarse en uno de PAP , CHAP , MS-CHAP o MS-CHAP-V2

  • DigitalCertificate : requerido para EAP-TLS. Se deben configurar los siguientes nodos:

    • CertificateType establecido en x509v3
    • CertSHA256Fingerprint configurado con el resumen SHA-256 correcto del certificado del cliente en la sección MIME de la clave EAP-TLS

  • SIM : Requerido para EAP-SIM, EAP-AKA y EAP-AKA'. El campo EAPType debe configurarse en el tipo de EAP apropiado y IMSI debe coincidir con el IMSI de una de las tarjetas SIM instaladas en el dispositivo en el momento del aprovisionamiento. La cadena IMSI puede constar enteramente de dígitos decimales para forzar una coincidencia de igualdad total, o de 5 o 6 dígitos decimales seguidos de un asterisco (*) para relajar la coincidencia de IMSI solo con MCC/MNC. Por ejemplo, la cadena IMSI 123456* coincide con cualquier tarjeta SIM con MCC como 123 y MNC como 456.

Android 11 presenta capacidades que hacen que el aprovisionamiento de Passpoint R1 sea más flexible.

Nombre de dominio separado de autenticación, autorización y contabilidad (AAA)

Los administradores de red Passpoint que requieren un nombre de dominio AAA especificado independientemente del nombre de dominio completo (FQDN) anunciado por la red a través del Protocolo de consulta de red de acceso (ANQP) pueden especificar una lista de FQDN delimitada por punto y coma en un nuevo nodo en el subárbol Extension . . Este es un nodo opcional y los dispositivos que ejecutan la versión 10 de Android o inferior ignoran este nodo.

  • Android : subárbol de extensión de Android

    • AAAServerTrustedNames : obligatorio para los nombres de confianza del servidor AAA con los siguientes nodos configurados:

      • FQDN : Cadena que contiene los nombres de confianza del servidor AAA. Utilice punto y coma para separar los nombres de confianza. Por ejemplo, example.org;example.com .
CA raíz privadas autofirmadas
Los administradores de red Passpoint que administran sus certificados internamente pueden proporcionar perfiles con una CA privada autofirmada para la autenticación AAA.
Permitir la instalación de perfiles sin certificado de CA raíz
El certificado de CA raíz adjunto al perfil se utiliza para la autenticación del servidor AAA. Los administradores de red Passpoint que deseen confiar en CA raíz públicas confiables para la autenticación de su servidor AAA pueden aprovisionar perfiles sin un certificado de CA raíz. En este caso, el sistema verifica los certificados del servidor AAA con los certificados de CA raíz públicos instalados en el almacén de confianza.

Aprovisionamiento de Passpoint R2

Android 10 introdujo compatibilidad con las funciones de Passpoint R2. Passpoint R2 implementa el registro en línea (OSU), un método estándar para aprovisionar nuevos perfiles de Passpoint. Android 10 y versiones posteriores admiten el aprovisionamiento de perfiles EAP-TTLS mediante el protocolo SOAP-XML a través de OSU ESS abierto.

Las funciones admitidas de Passpoint R2 solo requieren el código de referencia AOSP (no se requiere soporte de controlador o firmware adicional). El código de referencia de AOSP también incluye una implementación predeterminada de la interfaz de usuario de Passpoint R2 en la aplicación Configuración.

Cuando Android detecta un punto de acceso Passpoint R2, el marco de Android:

  1. Muestra una lista de los proveedores de servicios anunciados por el AP en el selector de Wi-Fi (además de mostrar los SSID).
  2. Solicita al usuario que toque uno de los proveedores de servicios para configurar un perfil de Passpoint.
  3. Guía al usuario a través del flujo de configuración del perfil de Passpoint.
  4. Instala el perfil Passpoint resultante al finalizar correctamente.
  5. Se asocia a la red Passpoint utilizando el perfil Passpoint recién aprovisionado.

Características del Passpoint R3

Android 12 presenta las siguientes funciones de Passpoint R3 que mejoran la experiencia del usuario y permiten que las redes cumplan con las leyes locales:

Términos y condiciones

La aceptación de los términos y condiciones es un requisito legal en algunas ubicaciones y lugares para proporcionar acceso a la red. Esta característica permite que las implementaciones de red reemplacen portales cautivos inseguros, que utilizan redes abiertas, con una red Passpoint segura. Se muestra una notificación al usuario cuando es necesario aceptar los términos y condiciones.

La URL de términos y condiciones debe apuntar a un sitio web seguro mediante HTTPS. Si la URL apunta a un sitio web inseguro, el marco se desconecta inmediatamente y bloquea la red.

URL de información del lugar

Permite a los operadores de redes y lugares proporcionar información adicional al usuario, como mapas de lugares, directorios, promociones y cupones. Se muestra una notificación al usuario cuando la red está conectada.

La URL de información del lugar debe apuntar a un sitio web seguro mediante HTTPS. Si la URL apunta a un sitio web inseguro, el marco ignora la URL y no muestra una notificación.

Otras funciones de Passpoint

Android 11 presenta las siguientes capacidades de Passpoint que mejoran la experiencia del usuario, el uso de energía y la flexibilidad de implementación.

Ejecución y notificación de la fecha de vencimiento
Hacer cumplir las fechas de vencimiento en los perfiles permite que el marco evite la conexión automática a puntos de acceso con credenciales vencidas, que seguramente fallarán. Esto evita el uso de tiempo aire y ahorra batería y ancho de banda de backend. El marco muestra una notificación al usuario cuando una red que coincide con su perfil está dentro del alcance y el perfil ha caducado.
Múltiples perfiles con FQDN idéntico
Los operadores que implementan redes Passpoint y utilizan múltiples ID de redes móviles terrestres públicas (PLMN) pueden proporcionar múltiples perfiles de Passpoint con el mismo FQDN, uno para cada ID de PLMN, que se relaciona automáticamente con la tarjeta SIM instalada y se usa para conectar la red.

Android 12 presenta las siguientes capacidades de Passpoint que mejoran la experiencia del usuario, el uso de energía y la flexibilidad de implementación:

Prefijo de identidad decorado
Al autenticarse en redes con una decoración de prefijo, el prefijo de identidad decorado permite a los operadores de red actualizar el Identificador de acceso a la red (NAI) para realizar un enrutamiento explícito a través de múltiples servidores proxy dentro de una red AAA (consulte RFC 7542 ). Android 12 implementa esta función según la especificación WBA para extensiones PPS-MO .
Manejo inminente de desautenticación
Permite a los operadores de red indicar a un dispositivo que el servicio no está disponible para la credencial utilizada para autenticarse en la red durante un período determinado (especificado mediante un retraso de tiempo de espera). Después de recibir esta señal, los dispositivos no intentarán volver a conectarse a la red con la misma credencial hasta que expire el tiempo de espera. Por el contrario, los dispositivos que no admiten esta función pueden intentar volver a conectarse repetidamente a la red mientras el servicio no está disponible.

Ejemplos de perfiles XML OMA-DM PerProviderSubscription-MO

Perfil con credencial de nombre de usuario/contraseña (EAP-TTLS)

El siguiente ejemplo demuestra un perfil para una red con:

  • Nombre descriptivo de red establecido en Example Network
  • FQDN configurado en hotspot.example.net
  • OI del consorcio de roaming (para roaming)
  • Credencial con nombre de usuario user , password codificada con Base64 y dominio configurado en example.net
  • Método EAP establecido en 21 (EAP-TTLS)
  • Método interno de fase 2 configurado en MS-CHAP-V2
  • Nombres de dominio AAA alternativos configurados en trusted.com y trusted.net
<MgmtTree xmlns="syncml:dmddf1.2">
  <VerDTD>1.2</VerDTD>
  <Node>
    <NodeName>PerProviderSubscription</NodeName>
    <RTProperties>
      <Type>
        <DDFName>urn:wfa:mo:hotspot2dot0-perprovidersubscription:1.0</DDFName>
      </Type>
    </RTProperties>
    <Node>
      <NodeName>i001</NodeName>
      <Node>
        <NodeName>HomeSP</NodeName>
        <Node>
          <NodeName>FriendlyName</NodeName>
          <Value>Example Network</Value>
        </Node>
        <Node>
          <NodeName>FQDN</NodeName>
          <Value>hotspot.example.net</Value>
        </Node>
        <Node>
          <NodeName>RoamingConsortiumOI</NodeName>
          <Value>112233,445566</Value>
        </Node>
      </Node>
      <Node>
        <NodeName>Credential</NodeName>
        <Node>
          <NodeName>Realm</NodeName>
          <Value>example.net</Value>
        </Node>
        <Node>
          <NodeName>UsernamePassword</NodeName>
          <Node>
            <NodeName>Username</NodeName>
            <Value>user</Value>
          </Node>
          <Node>
            <NodeName>Password</NodeName>
            <Value>cGFzc3dvcmQ=</Value>
          </Node>
          <Node>
            <NodeName>EAPMethod</NodeName>
            <Node>
              <NodeName>EAPType</NodeName>
              <Value>21</Value>
            </Node>
            <Node>
              <NodeName>InnerMethod</NodeName>
              <Value>MS-CHAP-V2</Value>
            </Node>
          </Node>
        </Node>
      </Node>
      <Node>
        <NodeName>Extension</NodeName>
        <Node>
            <NodeName>Android</NodeName>
            <Node>
                <NodeName>AAAServerTrustedNames</NodeName>
                <Node>
                    <NodeName>FQDN</NodeName>
                    <Value>trusted.com;trusted.net</Value>
                </Node>
            </Node>
        </Node>
      </Node>
    </Node>
  </Node>
</MgmtTree>

Perfil con credencial de certificado digital (EAP-TLS)

El siguiente ejemplo demuestra un perfil para una red con:

  • Nombre descriptivo de red configurado en GlobalRoaming
  • FQDN configurado en globalroaming.net
  • OI del Consorcio de Roaming (para roaming)
  • Reino configurado en users.globalroaming.net
  • Credencial con certificado digital que tenga la huella dactilar especificada
<MgmtTree xmlns="syncml:dmddf1.2">
  <VerDTD>1.2</VerDTD>
  <Node>
    <NodeName>PerProviderSubscription</NodeName>
    <RTProperties>
      <Type>
        <DDFName>urn:wfa:mo:hotspot2dot0-perprovidersubscription:1.0</DDFName>
      </Type>
    </RTProperties>
    <Node>
      <NodeName>i001</NodeName>
      <Node>
        <NodeName>HomeSP</NodeName>
        <Node>
          <NodeName>FriendlyName</NodeName>
          <Value>GlobalRoaming</Value>
        </Node>
        <Node>
          <NodeName>FQDN</NodeName>
          <Value>globalroaming.net</Value>
        </Node>
        <Node>
          <NodeName>RoamingConsortiumOI</NodeName>
          <Value>FFEEDDCC0,FFEEDDCC1,009999,008888</Value>
        </Node>
      </Node>
      <Node>
        <NodeName>Credential</NodeName>
        <Node>
          <NodeName>Realm</NodeName>
          <Value>users.globalroaming.net</Value>
        </Node>
        <Node>
          <NodeName>DigitalCertificate</NodeName>
          <Node>
            <NodeName>CertificateType</NodeName>
            <Value>x509v3</Value>
          </Node>
          <Node>
            <NodeName>CertSHA256Fingerprint</NodeName>
            <Value>0ef08a3d2118700474ca51fa25dc5e6d3d63d779aaad8238b608a853761da533</Value>
          </Node>
        </Node>
      </Node>
    </Node>
  </Node>
</MgmtTree>

Perfil con credencial SIM (EAP-AKA)

El siguiente ejemplo demuestra un perfil para una red con:

  • Nombre descriptivo de red configurado en Purple Passpoint
  • FQDN configurado en wlan.mnc888.mcc999.3gppnetwork.org
  • Credencial SIM con ID PLMN de 999888
  • Método EAP establecido en 23 (EAP-AKA)
<MgmtTree xmlns="syncml:dmddf1.2">
  <VerDTD>1.2</VerDTD>
  <Node>
    <NodeName>PerProviderSubscription</NodeName>
    <RTProperties>
      <Type>
        <DDFName>urn:wfa:mo:hotspot2dot0-perprovidersubscription:1.0</DDFName>
      </Type>
    </RTProperties>
    <Node>
      <NodeName>i001</NodeName>
      <Node>
        <NodeName>HomeSP</NodeName>
        <Node>
          <NodeName>FriendlyName</NodeName>
          <Value>Purple Passpoint</Value>
        </Node>
        <Node>
          <NodeName>FQDN</NodeName>
          <Value>purplewifi.com</Value>
        </Node>
      </Node>
      <Node>
        <NodeName>Credential</NodeName>
        <Node>
          <NodeName>Realm</NodeName>
          <Value>wlan.mnc888.mcc999.3gppnetwork.org</Value>
        </Node>
        <Node>
          <NodeName>SIM</NodeName>
          <Node>
            <NodeName>IMSI</NodeName>
            <Value>999888*</Value>
          </Node>
          <Node>
            <NodeName>EAPType</NodeName>
            <Value>23</Value>
          </Node>
        </Node>
      </Node>
    </Node>
  </Node>
</MgmtTree>

Aviso de autenticación

Los dispositivos que ejecutan Android 8.x o Android 9 con un perfil Passpoint R1 EAP-SIM, EAP-AKA o EAP-AKA no se conectarán automáticamente a la red Passpoint. Este problema afecta a los usuarios, operadores y servicios al reducir la descarga de Wi-Fi.

Segmento Impacto Tamaño del impacto
Operadores y proveedores de servicios Passpoint Mayor carga en la red celular. Cualquier operador que utilice Passpoint R1.
Usuarios Oportunidad perdida de conectarse automáticamente a los puntos de acceso (AP) Wi-Fi del operador, lo que genera mayores costos de datos. Cualquier usuario con un dispositivo que se ejecute en una red de operador que admita Passpoint R1.

Causa de la falla

Passpoint especifica un mecanismo para hacer coincidir un proveedor de servicios anunciado (ANQP) con un perfil instalado en el dispositivo. Las siguientes reglas de coincidencia para EAP-SIM, EAP-AKA y EAP-AKA' son un conjunto parcial de reglas que se centran en las fallas de EAP-SIM/AKA/AKA':

If the FQDN (Fully Qualified Domain Name) matches
    then the service is a Home Service Provider.
Else: If the PLMN ID (3GPP Network) matches
    then the service is a Roaming Service Provider.

El segundo criterio fue modificado en Android 8.0:

Else: If the PLMN ID (3GPP Network) matches AND the NAI Realm matches
    then the service is a Roaming Service Provider.

Con esta modificación, el sistema no encontró coincidencias con los proveedores de servicios que trabajaban anteriormente, por lo que los dispositivos Passpoint no se conectaron automáticamente.

Soluciones alternativas

Para solucionar el problema de los criterios de coincidencia modificados, los operadores y proveedores de servicios deben agregar el dominio del identificador de acceso a la red (NAI) a la información publicada por Passpoint AP.

La solución recomendada es que los proveedores de servicios de red implementen una solución alternativa en el lado de la red para acelerar la implementación. Una solución alternativa del lado del dispositivo depende de que los OEM recojan una lista de cambios (CL) de AOSP y luego actualicen los dispositivos en el campo.

Solución de red para operadores y proveedores de servicios Passpoint

La solución alternativa del lado de la red requiere reconfigurar la red para agregar el elemento ANQP del ámbito NAI como se especifica a continuación. Las especificaciones de Passpoint no requieren el elemento ANQP del ámbito NAI, pero la adición de esta propiedad cumple con las especificaciones de Passpoint, por lo que las implementaciones de cliente que cumplen con las especificaciones no deberían fallar.

  1. Agregue el elemento ANQP del reino NAI.
  2. Configure el subcampo de dominio NAI para que coincida con el Realm del perfil instalado en el dispositivo.

  3. Configure la siguiente información según cada tipo de EAP:

    • EAP-TTLS: establezca EAPMethod(21) y los tipos de autenticación interna admitidos ( PAP , CHAP , MS-CHAP o MS-CHAP-V2 ).
    • EAP-TLS: Establecer EAPMethod(13)
    • EAP-SIM: Establecer EAPMethod(18)
    • EAP-AKA: Establecer EAPMethod(23)
    • EAP-AKA': Establecer EAPMethod(50)

Solución de dispositivo/AOSP para OEM

Para implementar una solución alternativa en el lado del dispositivo, los OEM deben elegir el parche CL aosp/718508 . Este parche se puede aplicar además de las siguientes versiones (no se aplica a Android 10 o superior):

  • androide 9
  • Android 8.x

Cuando se implementa el parche, los OEM deben actualizar los dispositivos en el campo.