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

Punto de acceso (Hotspot 2.0)

Passpoint es una conexión Wi-Fi Alliance (WFA) protocolo que permite a los dispositivos móviles para descubrir y autenticar a puntos de acceso Wi-Fi que permiten el acceso a Internet.

Soporte de dispositivo

Para apoyar Passpoint, los fabricantes de dispositivos necesitan implementar hardware/interfaces/wifi/supplicant/1.0 o superior. El Wi-Fi lenguaje de diseño de la interfaz de HAL (HIDL) proporcionada en el proyecto de código abierto Android (AOSP) define un HAL al suplicante. El solicitante proporciona soporte para el estándar 802.11u, específicamente funciones de detección y selección de redes como el Servicio de publicidad genérico (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 compatibilidad de firmware para 802.11u. Todos los demás requisitos para admitir Passpoint se incluyen en AOSP.

Android 10 o inferior

Para los 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 una marca de función)
  • Firmware: soporte para 802.11u

Para admitir Passpoint, implemente Wi-Fi HAL y habilite la marca de función para Passpoint. En device.mk situado en device/<oem>/<device> , modificar el PRODUCT_COPY_FILES variable de entorno para incluir el soporte para la característica 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 su implementación de la función Passpoint, utilice el conjunto de pruebas unitarias y pruebas de integración que se proporcionan 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 administrador:

atest android.net.wifi.hotspot2

Pruebas de integración (ACTS)

Los actos banco de pruebas Passpoint, situada en tools/test/connectivity/acts/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) mediante la descarga basada en web de un archivo especial que contiene información de perfil y credencial. 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 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 envuelto de varias partes representado en UTF-8 y codificado en codificación 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 establecerse en application/x-wifi-config .
  • Content-Transfer-Encoding debe establecerse en base64 .
  • Content-Disposition no se debe establecer.

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 los 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 de archivos

El Base64 codificado contenido debe constar de contenido multiparte MIME con un Content-Type de 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 OMA-DM SyncML carga útil formato que contiene el Passpoint R1 PerProviderSubscription MO formateado 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 sin contraseña.

La sección de perfil debe ser transferido como codificado en base 64, texto XML UTF-8-codificada que especifica las partes de la HomeSP y Credential subárboles en la versión Passpoint R2 Especificación Técnica 1.0.0, sección 9.1.

El nodo de nivel superior debe ser MgmtTree y el nodo secundario inmediato debe ser PerProviderSubscription . Un ejemplo de archivo XML aparece en Ejemplo XML perfil OMA-DM .

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

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

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

  • Realm : debe ser una cadena no vacía
  • UsernamePassword : Requerido para EAP-TTLS con los siguientes nodos establecidos:

    • Username : Cadena que contiene el nombre de usuario
    • Password : Base64 codificado cadena (SET para cGFzc3dvcmQ= , la cadena codificado en base 64 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. Deben configurarse los siguientes nodos:

    • CertificateType establece en x509v3
    • CertSHA256Fingerprint conjunto para el correcto SHA-256 digerir del certificado de cliente en la sección MIME clave EAP-TLS
  • SIM : Obligatorio para EAP-SIM, EAP-AKA, y EAP-AKA'. El EAPType campo debe establecerse en el tipo de EAP apropiado y IMSI debe coincidir con un IMSI de una de las tarjetas SIM instaladas en el dispositivo en el momento de aprovisionamiento. La cadena IMSI puede constar completamente de dígitos decimales para forzar la 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 una IMSI que comience con 123.

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 especificarse independientemente del nombre de dominio completo (FQDN) anunciado por la red a través del protocolo de consultas de acceso a la red (ANQP) puede especificar una lista por punto y coma de nombres completos de dominio en un nuevo nodo bajo la Extension subárbol . Este es un nodo opcional y los dispositivos que ejecutan la versión 10 de Android o una versión anterior ignoran este nodo.

  • Android : Android subárbol extensión

    • AAAServerTrustedNames : Requerido para el servidor AAA confiar en los nombres con los siguientes nodos establecidos:

      • FQDN : Cadena que contiene el servidor AAA confiaba nombres. 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 puntos de acceso 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 se adjunta al perfil se utiliza para la autenticación del servidor AAA. Los administradores de red de puntos de acceso que deseen confiar en las CA raíz públicas de confianza para la autenticación de su servidor AAA pueden proporcionar perfiles sin un certificado de CA raíz. En este caso, el sistema verifica los certificados de servidor AAA con los certificados de CA raíz pública instalados en el almacén de confianza.

Aprovisionamiento de Passpoint R2

Android 10 introdujo soporte para 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 superior admite el aprovisionamiento de perfiles EAP-TTLS mediante el protocolo SOAP-XML sobre OSU ESS abierto.

Las funciones de Passpoint R2 admitidas 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 cuando se completa con éxito.
  5. Se asocia a la red Passpoint utilizando el perfil Passpoint recién aprovisionado.

Características de 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 los 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.
URL de información del lugar
Permite que los operadores de redes y lugares proporcionen 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.

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.

Cumplimiento 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 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 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 expirado.
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 aprovisionar varios perfiles de Passpoint con el mismo FQDN, uno para cada ID PLMN, que se empareja automáticamente con la tarjeta SIM instalada y se utiliza 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
Cuando la autenticación en redes con una decoración prefijo, el prefijo de la identidad decorada permite a los operadores de red para actualizar la red de acceso Identificador (NAI) para realizar encaminamiento explícito a través de múltiples servidores proxy dentro de una red AAA (ver RFC 7542 ). Android 12 implementa esta característica de acuerdo con la especificación de la AMB para las extensiones de 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 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 muestra un perfil para una red con:

  • Red nombre descriptivo conjunto de Example Network
  • FQDN conjunto de hotspot.example.net
  • OI de consorcio de itinerancia (para itinerancia)
  • Credencial con nombre de usuario user , contraseña password codificada con Base64, y el conjunto de reino para example.net
  • EAP conjunto método para 21 (EAP-TTLS)
  • Fase-2 método interior conjunto a MS-CHAP-V2
  • Nombres de dominio AAA alternativos establecidos a 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:

  • CONFIGURACIÓN DE LA RED nombre descriptivo a GlobalRoaming
  • FQDN conjunto de globalroaming.net
  • OI del consorcio de itinerancia (para itinerancia)
  • Conjunto ámbito de users.globalroaming.net
  • Credencial con 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 credencial SIM (EAP-AKA)

El siguiente ejemplo muestra un perfil para una red con:

  • Red nombre descriptivo conjunto de Purple Passpoint
  • FQDN conjunto de wlan.mnc888.mcc999.3gppnetwork.org
  • Credencial SIM con PLMN ID de 999888
  • EAP conjunto método para 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.xo 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 de 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 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 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 ámbito 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 lograr el menor tiempo de implementación. Una solución alternativa del lado del dispositivo depende de que los OEM obtengan 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 Passpoint

La solución alternativa del lado de la red requiere reconfigurar 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 dominio 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 deben romperse.

  1. Agregue el elemento ANQP del reino NAI.
  2. Ajuste el subcampo ámbito 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: Conjunto EAPMethod(21) y apoyados tipos de autenticación interiores ( PAP , CHAP , MS-CHAP , o MS-CHAP-V2 )
    • EAP-TLS: Conjunto EAPMethod(13)
    • EAP-SIM: Conjunto EAPMethod(18)
    • EAP-AKA: Conjunto EAPMethod(23)
    • EAP-AKA ': Conjunto EAPMethod(50)

Corrección de dispositivo / AOSP para OEM

Para poner en práctica una solución del lado del dispositivo, los fabricantes de equipos tienen que recoger el parche CL AOSP / 718508 . Este parche se puede aplicar además de las siguientes versiones (no se aplica a Android 10 o superior):

  • Android 9
  • Android 8.x

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