Punto de acceso (punto de acceso 2.0)

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

Soporte de dispositivos

Para admitir Passpoint, los fabricantes de dispositivos deben implementar hardware/interfaces/wifi/supplicant/1.0 o superior. El lenguaje de diseño de interfaz Wi-Fi HAL (HIDL) proporcionado en el Proyecto de código abierto de Android (AOSP) define un HAL para el solicitante. El suplicante brinda soporte para el estándar 802.11u, específicamente funciones de detección y selección 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 los dispositivos que ejecutan Android 10 o versiones anteriores, los fabricantes de dispositivos deben proporcionar compatibilidad con framework y 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 de Passpoint R1

Android es compatible con Passpoint R1 desde Android 6.0, lo que permite el aprovisionamiento de credenciales de Passpoint R1 (versión 1) a través de 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 de perfil contenida en el archivo se usa 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 es compatible con 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 estar protegido con TLS (HTTPS) porque puede contener una contraseña de texto sin cifrar o datos de clave privada. El contenido se compone de texto MIME multiparte envuelto representado en UTF-8 y codificado en codificación base64 según RFC-2045 sección 6.8.

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

  • Content-Type debe establecerse en application/x-wifi-config .
  • Content-Transfer-Encoding debe establecerse en base64 .
  • No se debe configurar 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 iniciarse tocando un elemento HTML, como un botón (no se admiten los redireccionamientos automáticos a una URL de descarga). Este comportamiento es específico de Google Chrome; otros navegadores web pueden o no proporcionar una funcionalidad similar.

Composición de archivos

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

Parte Tipo de contenido (menos comillas) Requerido Descripción
Perfil application/x-passpoint-profile Siempre Carga útil con formato SyncML de OMA-DM que contiene el MO con formato PerProviderSubscription de Passpoint R1 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 claro sin contraseña.

La sección Perfil debe transferirse como texto XML con codificación UTF-8 y codificación base64 que especifica partes de los subárboles HomeSP y Credential en la especificación técnica 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 . Un archivo XML de ejemplo aparece en Ejemplo de perfil OMA-DM XML .

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

  • FriendlyName : debe establecerse; utilizado como texto de visualización
  • FQDN : Obligatorio
  • RoamingConsortiumOI

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

  • Realm : debe ser una cadena no vacía

  • Nombre de UsernamePassword : Requerido para EAP-TTLS con los siguientes nodos establecidos:

    • Nombre de 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 ejemplo a continuación)
    • EAPMethod/EAPType : debe establecerse en 21
    • EAPMethod/InnerMethod : debe establecerse en uno de PAP , CHAP , MS-CHAP o MS-CHAP-V2

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

    • CertificateType establecido en x509v3
    • CertSHA256Fingerprint establecido en 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 establecerse en el tipo de EAP adecuado y la IMSI debe coincidir con una IMSI de una de las tarjetas SIM instaladas en el dispositivo en el momento del aprovisionamiento. La cadena IMSI puede constar completamente de dígitos decimales para forzar una coincidencia de igualdad total, o de cero o más dígitos decimales seguidos de un asterisco (*) para relajar la coincidencia IMSI solo con el prefijo. Por ejemplo, la cadena IMSI 123* coincide con cualquier tarjeta SIM con un IMSI que comience con 123.

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

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

Los administradores de red de 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 delimitada por punto y coma de FQDN en un nuevo nodo bajo el subárbol de 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 extensiones de Android

    • AAAServerTrustedNames : Requerido para los nombres de confianza del servidor AAA con los siguientes nodos establecidos:

      • 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 de Passpoint que administran sus certificados internamente pueden aprovisionar perfiles con una CA privada autofirmada para la autenticación AAA.
Permitir la instalación de perfiles sin un certificado de CA raíz
El certificado de CA raíz que está adjunto al perfil se usa para la autenticación del servidor AAA. Los administradores de red de Passpoint que deseen confiar en las CA raíz públicas de confianza para su autenticación de 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 la 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 sobre OSU ESS abierto.

Las funciones admitidas de Passpoint R2 solo requieren el código de referencia AOSP, no se requiere soporte adicional de controlador o firmware). 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 de Passpoint resultante al completarse con éxito.
  5. Se asocia a la red de Passpoint utilizando el perfil de 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 algunos lugares y lugares para proporcionar acceso a la red. Esta función permite que las implementaciones de red reemplacen los portales cautivos inseguros, que usan redes abiertas, con una red Passpoint segura. Se muestra una notificación al usuario cuando los términos y condiciones deben ser aceptados.

La URL de los términos y condiciones debe apuntar a un sitio web seguro mediante HTTPS. Si la URL apunta a un sitio web no seguro, 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 no seguro, el marco ignora la URL y no muestra una notificación.

Otras características 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.

Aplicación y notificación de la fecha de caducidad
Hacer cumplir las fechas de caducidad en los perfiles permite que el marco evite la conexión automática a los puntos de acceso con credenciales caducadas, que están destinadas a fallar. Esto evita el uso de tiempo aire y ahorra batería y ancho de banda de back-end. 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 varias identificaciones de redes móviles terrestres públicas (PLMN) pueden aprovisionar varios perfiles de Passpoint con el mismo FQDN, uno para cada identificación de PLMN, que se compara 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 de acuerdo con la especificación WBA para extensiones PPS-MO .
Manejo inminente de la desautenticación
Permite a los operadores de red señalar a un dispositivo que el servicio no está disponible para la credencial utilizada para autenticarse en la red durante un período determinado (especificado a través de 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 PerProviderSubscription-MO de OMA-DM

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

El siguiente ejemplo muestra un perfil para una red con:

  • Nombre descriptivo de la red establecido en Example Network
  • FQDN establecido en hotspot.example.net
  • OI de consorcio de roaming (para roaming)
  • Credencial con nombre de user , password codificada con Base64 y reino establecido en example.net
  • Método EAP establecido en 21 (EAP-TTLS)
  • Método interno de fase 2 establecido 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 muestra un perfil para una red con:

  • Nombre descriptivo de la red establecido en GlobalRoaming
  • FQDN establecido en globalroaming.net
  • OI de consorcio de roaming (para roaming)
  • Reino establecido en users.globalroaming.net
  • Credencial con certificado digital que cuenta con la huella 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 muestra un perfil para una red con:

  • Nombre descriptivo de la red establecido en Purple Passpoint
  • FQDN establecido en wlan.mnc888.mcc999.3gppnetwork.org
  • Credencial SIM con PLMN ID 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 autorizació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 de Passpoint. Este problema afecta a los usuarios, los operadores y los servicios al reducir la descarga de Wi-Fi.

Segmento Impacto Tamaño del impacto
Transportistas 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 costos de datos más altos. Cualquier usuario con un dispositivo que se ejecuta en una red de operador compatible con 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 coincidentes para EAP-SIM, EAP-AKA y EAP-AKA' son un conjunto parcial de reglas que se enfocan 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ó ninguna coincidencia 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 los 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 en el lado de la red para acelerar el tiempo de implementación. Una solución 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.

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

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

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

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

    • EAP-TTLS: EAPMethod(21) y los tipos de autenticación internos 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)

Arreglo de dispositivo/AOSP para OEM

Para implementar una solución alternativa del lado del dispositivo, los OEM deben seleccionar 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 recoge el parche, los OEM deben actualizar los dispositivos en el campo.