Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Se usó la API de Cloud Translation para traducir esta página.

Passpoint (Hotspot 2.0)

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

Asistencia para dispositivos

Para admitir Passpoint, los fabricantes de dispositivos deben implementar la interfaz de Supplicant. A partir de Android 13, la interfaz usa el AIDL para la definición de la HAL. En las versiones anteriores a Android 13, las interfaces y las particiones del proveedor usan 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 compatibilidad con el estándar 802.11u, específicamente con las funciones de descubrimiento y selección de red, como el servicio de publicidad genérica (GAS) y el protocolo de consulta de red (ANQP).

Implementación

Android 11 o versiones posteriores

Para admitir Passpoint en dispositivos que ejecutan Android 11 o versiones posteriores, los fabricantes de dispositivos deben proporcionar compatibilidad con el 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 con Android 10 o versiones anteriores, los fabricantes deben proporcionar compatibilidad con el framework y la HAL o el firmware:

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

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

Validación

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

Pruebas de servicio:

atest com.android.server.wifi.hotspot2

Pruebas del 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 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 le 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 usa para hacer coincidir los datos recuperados de los puntos de acceso compatibles con 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 se debe alojar en un servidor web y debe protegerse con TLS (HTTPS), ya que puede contener datos de contraseña de texto simple o clave privada. El contenido está compuesto por texto MIME de varias partes unido representado en UTF-8 y codificado en 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:

Se debe configurar Content-Type como application/x-wifi-config.
Se debe configurar Content-Transfer-Encoding como base64.
No se debe establecer Content-Disposition.

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 se debe activar 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 consistir en contenido MIME de varias partes con un Content-Type de multipart/mixed. Las siguientes partes conforman las partes individuales del contenido de varias partes.

Parte	Content-Type (menos comillas)	Obligatorio	Descripción
Perfil	`application/x-passpoint-profile`	Siempre	Carga útil con formato SyncML de OMA-DM que contiene la 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	Una sola carga útil de certificado X.509v3 codificada en base64
Clave EAP-TLS	`application/x-pkcs12`	Obligatorio para EAP-TLS	Una estructura ASN.1 PKCS #12 con codificación base64 que contiene una cadena de certificados de cliente con, al menos, el certificado de cliente y la clave privada asociada. El contenedor de PKCS 12, la clave privada y los certificados deben estar en texto claro y sin contraseña.

La sección Perfil se debe transferir como texto XML codificado en Base64 y UTF-8 que especifique partes de los subárboles HomeSP y Credential en la sección 9.1 de la Especificación Técnica Passpoint R2, versión 1.0.0.

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

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

FriendlyName: Se debe establecer y se usa como texto visible.
FQDN: Obligatorio
RoamingConsortiumOI

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

Realm: Debe ser una cadena no vacía.
UsernamePassword: Obligatorio para EAP-TTLS con los siguientes nodos configurados:
- Username: Es la cadena que contiene el nombre de usuario.
- Password: Es la string codificada en base64 (configurada como cGFzc3dvcmQ=, la string codificada en base64 para "contraseña", que se muestra en el siguiente ejemplo).
- EAPMethod/EAPType: Se debe configurar como 21.
- EAPMethod/InnerMethod: Se debe establecer en PAP, CHAP, MS-CHAP o MS-CHAP-V2.
DigitalCertificate: Obligatorio para EAP-TLS. Se deben configurar los siguientes nodos:
- CertificateType definida como x509v3
- CertSHA256Fingerprint establecido en el resumen SHA-256 correcto del certificado del 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 string de IMSI puede consistir solo en dígitos decimales para forzar la coincidencia de igualdad completa, o de 5 o 6 dígitos decimales seguidos de un asterisco (*) a fin de 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 funciones que hacen que el aprovisionamiento de Passpoint R1 sea más flexible.

Nombre de dominio de autenticación, autorización y contabilización (AAA) independiente: Los administradores de redes de 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 red de acceso (ANQP) pueden especificar una lista de FQDN delimitada por punto y coma en un nodo nuevo debajo del subárbol Extension. Este es un nodo opcional, y los dispositivos que ejecutan Android 10 o versiones anteriores lo ignoran.

Android: Subárbol de la extensión de Android
- AAAServerTrustedNames: Es obligatorio para los nombres de confianza del servidor AAA con los siguientes nodos configurados:
  - FQDN: Es una cadena que contiene los nombres de confianza del servidor AAA. Usa puntos y coma para separar los nombres de confianza. Por ejemplo, example.org;example.com.

AC raíz privadas autofirmadas: Los administradores de red de Passpoint que administran sus certificados de forma interna pueden aprovisionar perfiles con una AC privada autofirmada para la autenticación AAA.
Permite la instalación de perfiles sin un certificado de 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 red de Passpoint que quieran depender de AC raíz públicas de confianza para la autenticación de su servidor AAA pueden aprovisionar perfiles sin un certificado de AC raíz. En este caso, el sistema verifica los certificados de servidor AAA contra los certificados públicos de AC raíz 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 perfiles nuevos de Passpoint. Android 10 y versiones posteriores admiten el aprovisionamiento de perfiles EAP-TTLS con el protocolo SOAP-XML a través de ESS de OSU abierta.

Las funciones compatibles de Passpoint R2 solo requieren el código de referencia de AOSP (no se requiere compatibilidad con controladores o firmware adicionales). 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 R2 de Passpoint, el framework de Android hace lo siguiente:

Muestra una lista de los proveedores de servicios que anuncia el AP en el selector de Wi-Fi (además de mostrar los SSID).
Le solicita al usuario que presione uno de los proveedores de servicios para configurar un perfil de Passpoint.
Explica al usuario el flujo de configuración del perfil de Passpoint.
Instala el perfil de Passpoint resultante cuando se completa correctamente.
Se asocia a la red de 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

La aceptación de los Términos y Condiciones es un requisito legal en algunas ubicaciones y espacios 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 los 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 del lugar

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

La URL de información del lugar debe dirigir a un sitio web seguro que use HTTPS. Si la URL apunta a un sitio web no seguro, el framework la ignora y no muestra una notificación.

Otras funciones de Passpoint

Android 11 presenta las siguientes funciones 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 a puntos de acceso con credenciales vencidas, que están destinadas 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 una notificación al usuario 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 de Passpoint y usan varios IDs de redes móviles públicas por tierra (PLMN) pueden aprovisionar varios perfiles de Passpoint con el mismo FQDN, uno para cada ID de PLMN, que coincide automáticamente con la tarjeta SIM instalada y se usa para conectar la red.

Android 12 presenta las siguientes funciones 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 extendido 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 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 se venza el tiempo de espera. Por el contrario, los dispositivos que no admiten esta función pueden intentar volver a conectarse a la red de forma reiterada mientras el servicio no está disponible.

Ejemplos de perfiles XML de OMA-DM PerProviderSubscription-MO

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

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

Se estableció el nombre amigable de la red en Example Network
FQDN configurado en hotspot.example.net
OIs del consorcio de roaming (para roaming)
Credencial con el nombre de usuario user, la contraseña password codificada en Base64 y el reino establecido en example.net
Método EAP establecido en 21 (EAP-TTLS)
El método interno de la fase 2 se estableció en MS-CHAP-V2.
Los nombres de dominio AAA alternativos se establecieron 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 de una red con lo siguiente:

Se estableció el nombre amigable de la red en GlobalRoaming
FQDN establecido en globalroaming.net
OI del consorcio de roaming (para roaming)
Se estableció el dominio 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 de SIM (EAP-AKA)

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

Se estableció el nombre amigable de la red en Purple Passpoint
FQDN establecido en wlan.mnc888.mcc999.3gppnetwork.org
Credencial de SIM con el 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 Auth

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 de Passpoint. Este problema afecta a los usuarios, operadores y servicios, ya que reduce la descarga de Wi-Fi.

Segmentar	Impacto	Tamaño del impacto
Operadores y proveedores de servicios de Passpoint	Mayor 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 (AP) Wi-Fi del operador, lo que genera costos de datos más altos.	Cualquier usuario con un dispositivo que se ejecute 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 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 encontró coincidencias 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 reino del identificador de acceso a la red (NAI) a la información que publica 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 que el tiempo de implementación sea el más rápido posible. Una solución alternativa 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 que se vuelva a configurar la red para agregar el elemento ANQP del reino NAI como se especifica a continuación. Las especificaciones de Passpoint no requieren el elemento ANQP del reino 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.

Agrega el elemento ANQP del reino NAI.
Establece el subcampo de dominio de NAI para que coincida con el Realm del perfil instalado en el dispositivo.
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 OEM

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

Android 9
Android 8.x

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