Passpoint (Hotspot 2.0)

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

Dispositivos compatibles

Para admitir Passpoint, los fabricantes de dispositivos deben implementar la interfaz de Supplicant. A partir de Android 13, la interfaz usa AIDL para la definición de HAL. En las versiones anteriores a Android 13, las interfaces y las particiones del proveedor usan HIDL. Los archivos HIDL se encuentran en hardware/interfaces/supplicant/1.x, y los archivos AIDL, en hardware/interfaces/supplicant/aidl. El solicitante proporciona compatibilidad con el estándar 802.11u, específicamente con las funciones de descubrimiento y selección de redes, como el servicio de publicidad genérico (GAS) y el protocolo de consulta de acceso a la red (ANQP).

Implementación

La implementación de Passpoint varía según la versión de Android.

Android 11 o una versión posterior

Para admitir Passpoint en dispositivos que ejecutan Android 11 o versiones posteriores, los fabricantes de dispositivos deben proporcionar compatibilidad con firmware para 802.11u. Todos los demás requisitos para admitir Passpoint se incluyen en AOSP.

Android 10 o anterior

En el caso de los dispositivos que ejecutan Android 10 o versiones anteriores, los fabricantes de dispositivos deben proporcionar compatibilidad con el framework, HAL y el firmware:

  • Framework: Habilita Passpoint (requiere una marca de función).
  • Firmware: Compatibilidad con 802.11u

Para admitir Passpoint, implementa la HAL de Wi-Fi y habilita la marca de función para Passpoint. En device.mk ubicado en device/<oem>/<device>, modifica la PRODUCT_COPY_FILES variable de entorno 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 se incluyen en AOSP.

Validación

Para validar tu implementación de la función Passpoint, ejecuta las siguientes pruebas unitarias del paquete Passpoint:

Pruebas de servicio:

atest com.android.server.wifi.hotspot2

Pruebas de administrador:

atest android.net.wifi.hotspot2

Aprovisionamiento de Passpoint R1

Android admite 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 la 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 que el usuario vea partes de la información antes de aceptar o rechazar el contenido.

La información del perfil que contiene 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 a 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 alojarse en un servidor web y debe protegerse con TLS (HTTPS), ya que puede contener datos de contraseña o clave privada de texto simple. El contenido se compone de texto MIME de varias partes envuelto representado en UTF-8 y codificado en codificación base64 según la sección 6.8 de RFC-2045.

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

  • Content-Type debe establecerse en application/x-wifi-config.
  • Content-Transfer-Encoding debe establecerse en base64.
  • Content-Disposition no debe establecerse.

El método HTTP que se usa para recuperar el archivo debe ser GET. Cada vez que una solicitud HTTP GET del navegador recibe una respuesta con estos encabezados MIME, se inicia la app de instalación. La descarga debe activarse presionando 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. Es posible que otros navegadores web proporcionen o no una funcionalidad similar.

Composición de archivos

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

Parte Content-Type (sin comillas) Obligatorio Descripción
Perfil application/x-passpoint-profile Siempre Es una carga útil con formato OMA-DM SyncML que contiene el MO con formato PerProviderSubscription de Passpoint R1 para HomeSP y Credential.
Certificado de confianza application/x-x509-ca-cert Obligatorio para EAP-TLS y EAP-TTLS Es una sola carga útil de certificado X.509v3 codificada en base64.
Clave EAP-TLS application/x-pkcs12 Obligatorio para EAP-TLS Es 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, la clave privada y los certificados deben estar en texto simple 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 versión 1.0.0 de la especificación técnica de Passpoint R2, sección 9.1.

El nodo de nivel superior debe ser MgmtTree, y el subnodo inmediato debe ser PerProviderSubscription. En el ejemplo de perfil OMA-DM XML, se muestra un archivo en formato XML de ejemplo.

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

  • FriendlyName: Debe establecerse y se usa como texto visible.
  • FQDN: Obligatorio
  • RoamingConsortiumOI

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

  • Realm: Debe ser una cadena no vacía.

  • UsernamePassword: Obligatorio para EAP-TTLS con los siguientes nodos establecidos:

    • Username: Es una cadena que contiene el nombre de usuario.
    • Password: Es una cadena codificada en Base64 (en el ejemplo siguiente, se establece en cGFzc3dvcmQ=, la cadena codificada en base64 para "contraseña").
    • EAPMethod/EAPType: Debe establecerse en 21.
    • EAPMethod/InnerMethod: Debe establecerse en PAP, CHAP, MS-CHAP, o MS-CHAP-V2.

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

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

  • SIM: Obligatorio para EAP-SIM, EAP-AKA y EAP-AKA'. El campo EAPType debe establecerse en el tipo de EAP adecuado, y IMSI debe coincidir con un 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 la coincidencia de igualdad completa o de 5 o 6 dígitos decimales seguidos de un asterisco (*) para relajar la coincidencia de IMSI solo a 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 de autenticación, autorización y contabilidad (AAA) independiente

Los administradores de redes Passpoint que requieren un nombre de dominio AAA especificado de forma independiente del nombre de dominio completamente calificado (FQDN) que anuncia la red a través del protocolo de consulta de acceso a la red (ANQP) pueden especificar una lista de FQDN delimitada por punto y coma en un nodo nuevo en el subárbol Extension. Este es un nodo opcional, y los dispositivos que ejecutan Android 10 o versiones anteriores lo ignoran.

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

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

      • FQDN: Es una cadena que contiene los nombres de confianza del servidor AAA. Usa puntos y comas para separar los nombres de confianza. Por ejemplo, example.org;example.com.
CAs raíz privadas autofirmadas

Los administradores de redes Passpoint que administran sus certificados de forma interna pueden aprovisionar perfiles con una CA privada autofirmada para la autenticación AAA.

Permite la instalación de perfiles sin un certificado de la AC raíz

El certificado de la AC raíz que se adjunta al perfil se usa para la autenticación del servidor AAA. Los administradores de redes Passpoint que desean depender de las CAs raíz de confianza públicas para la autenticación de su servidor AAA pueden aprovisionar perfiles sin un certificado de la AC raíz. En este caso, el sistema verifica los certificados de servidor AAA contra los certificados públicos de CA raíz instalados en el almacén de confianza.

Aprovisionamiento de Passpoint R2

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

Las funciones compatibles de Passpoint R2 solo requieren código de referencia de AOSP (no se requiere compatibilidad adicional con controladores ni firmware). El código de referencia de AOSP también incluye una implementación predeterminada de la IU de Passpoint R2 en la app de Configuración.

Cuando Android detecta un punto de acceso Passpoint R2, el framework de Android hace lo siguiente:

  1. Muestra una lista de los proveedores de servicios que anuncia el AP en el selector de Wi-Fi (además de mostrar los SSID).
  2. Le solicita al usuario que presione 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 cuando se completa correctamente.
  5. Se asocia a la red Passpoint con el perfil de Passpoint aprovisionado recientemente.

Funciones de Passpoint R3

Android 12 introduce 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

En algunas ubicaciones y lugares, la aceptación de los Términos y Condiciones es un requisito legal para proporcionar acceso a la red. Esta función permite que las implementaciones de redes reemplacen portales cautivos no seguros, que usan redes abiertas, por una red segura de Passpoint. Se le muestra una notificación al usuario cuando debe aceptar términos y condiciones.

La URL de los Términos y Condiciones debe dirigir a un sitio web seguro que use HTTPS. Si la URL dirige a un sitio web no seguro, el framework se desconecta y bloquea la red de inmediato.

URL de información de lugares

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

La URL de información de lugares debe dirigir a un sitio web seguro que use HTTPS. Si la URL dirige a un sitio web no seguro, el framework 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.

Aplicación y notificación de la fecha de vencimiento
La aplicación de fechas de vencimiento en los perfiles permite que el framework evite la conexión automática con puntos de acceso con credenciales vencidas, que están destinados a fallar. Esto evita el uso de tiempo de comunicación y permite ahorrar batería y ancho de banda de backend. El framework muestra al usuario una notificación cuando una red que coincide con su perfil está dentro del rango y el perfil venció.
Varios perfiles con FQDN idéntico
Los operadores que implementan redes Passpoint y usan varios IDs de red móvil terrestre pública (PLMN) pueden aprovisionar varios perfiles de Passpoint con el mismo FQDN, uno para cada ID de PLMN, que se hace coincidir automáticamente con la tarjeta SIM instalada y se usa para conectar la red.

Android 12 introduce 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
Cuando te autenticas en redes extendidas con un prefijo, el prefijo con identidad decorado permite que los operadores de red actualicen el identificador de acceso a la red (NAI) para realizar el enrutamiento explícito a través de varios proxies dentro de una red AAA (consulta RFC 7542). Android 12 implementa esta función según la especificación de WBA para extensiones PPS-MO.
Manejo inminente de la desautenticación
Permite que los operadores de red le indiquen a un dispositivo que el servicio no está disponible para la credencial que se usa 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 venza el retraso de tiempo de espera. Por el contrario, los dispositivos que no admiten esta función podrían intentar volver a conectarse a la red de forma repetida mientras el servicio no esté disponible.

Ejemplos de perfiles XML de OMA-DM PerProviderSubscription-MO

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

En el siguiente ejemplo, se muestra un perfil para una red con lo siguiente:

  • Nombre descriptivo de la red establecido en Example Network
  • FQDN establecido en hotspot.example.net
  • OIs del consorcio de roaming (para roaming)
  • Credencial con nombre de usuario user, contraseña password codificada con Base64 y dominio 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 establecidos 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 una credencial de certificado digital (EAP-TLS)

En el siguiente ejemplo, se muestra un perfil para una red con lo siguiente:

  • Nombre descriptivo de la red establecido en GlobalRoaming
  • FQDN establecido en globalroaming.net
  • OIs del consorcio de roaming (para roaming)
  • Dominio establecido en users.globalroaming.net
  • Credencial con un certificado digital que tiene la huella digital 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 una credencial SIM (EAP-AKA)

En el siguiente ejemplo, se muestra un perfil para una red con lo siguiente:

  • Nombre descriptivo de la red establecido en Purple Passpoint
  • FQDN establecido en wlan.mnc888.mcc999.3gppnetwork.org
  • Credencial SIM con ID de 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 EAP-SIM, EAP-AKA o EAP-AKA' de Passpoint R1 no se conectarán automáticamente a la red Passpoint. Este problema afecta a los usuarios, los operadores y los servicios, ya que reduce la descarga de Wi-Fi.

Segmento Impacto Tamaño del impacto
Operadores y proveedores de servicios de Passpoint Aumento de la carga en la red móvil Cualquier operador que use Passpoint R1
Usuarios Se perdió la oportunidad de conectarse automáticamente a los puntos de acceso Wi-Fi del operador (APs), lo que generó costos de datos más altos. 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 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 se modificó 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 observó ninguna coincidencia para los proveedores de servicios que funcionaban 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 el AP de Passpoint.

La solución recomendada es que los proveedores de servicios de red implementen una solución alternativa del lado de la red para obtener el tiempo de implementación más rápido. Una solución alternativa del lado del dispositivo depende de que los OEMs tomen 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 alternativa del lado de la red requiere volver a configurar la red para agregar el elemento ANQP del dominio NAI de la siguiente manera. 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 compatibles con las especificaciones no deberían interrumpirse.

  1. Agrega el elemento ANQP del dominio NAI.
  2. Establece el subcampo del dominio NAI para que coincida con el Realm del perfil instalado en el dispositivo.
  3. Establece la siguiente información según cada tipo de EAP:
    • EAP-TTLS: Establece EAPMethod(21) y los tipos de autenticación interna admitidos (PAP, CHAP, MS-CHAP o MS-CHAP-V2).
    • EAP-TLS: Establece EAPMethod(13)
    • EAP-SIM: Establece EAPMethod(18)
    • EAP-AKA: Establece EAPMethod(23)
    • EAP-AKA': Establece EAPMethod(50).

Corrección de dispositivo/AOSP para OEMs

Para implementar una solución alternativa del lado del dispositivo, los OEMs deben elegir la CL de parche aosp/718508. Este parche se puede aplicar sobre las siguientes versiones (no se aplica a Android 10 ni a versiones posteriores):

  • Android 9
  • Android 8.x

Cuando se toma el parche, los OEMs deben actualizar los dispositivos en el campo.