Passpoint est un protocole de la Wi-Fi Alliance (WFA) qui permet aux appareils mobiles de détecter et de s'authentifier sur les points d'accès Wi-Fi qui fournissent un accès à Internet.
Assistance relative aux appareils
Pour prendre en charge Passpoint, les fabricants d'appareils doivent implémenter l'interface Supplicant. À partir d'Android 13, l'interface utilise AIDL pour la définition HAL.
Pour les versions antérieures à Android 13, les interfaces et les partitions de fournisseurs utilisent le HIDL.
Les fichiers HIDL se trouvent dans hardware/interfaces/supplicant/1.x
et les fichiers AIDL dans hardware/interfaces/supplicant/aidl
.
Le demandeur est compatible avec la norme 802.11u, en particulier avec les fonctionnalités de détection et de sélection de réseau telles que le service d'annonces génériques (GAS, Generic Advertisement Service) et le protocole de requête de réseau d'accès (ANQP, Access Network Query Protocol).
Implémentation
Android 11 ou version ultérieure
Pour prendre en charge Passpoint sur les appareils équipés d'Android 11 ou version ultérieure, les fabricants d'appareils doivent fournir une prise en charge du micrologiciel pour la norme 802.11u. Toutes les autres exigences pour la prise en charge de Passpoint sont incluses dans AOSP.
Android 10 ou version antérieure
Pour les appareils équipés d'Android 10 ou version antérieure, les fabricants d'appareils doivent fournir une compatibilité avec le framework et le HAL/micrologiciel:
- Framework: Activer Passpoint (nécessite un flag de fonctionnalité)
- Micrologiciel: prise en charge de la norme 802.11u
Pour prendre en charge Passpoint, implémentez le HAL Wi-Fi et activez le flag de fonctionnalité pour Passpoint. Dans device.mk
situé dans device/<oem>/<device>
, modifiez la variable d'environnement PRODUCT_COPY_FILES
pour inclure la prise en charge de la fonctionnalité Passpoint:
PRODUCT_COPY_FILES +=
frameworks/native/data/etc/android.hardware.wifi.passpoint.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.wifi.passpoint.xml
Toutes les autres exigences pour la prise en charge de Passpoint sont incluses dans AOSP.
Validation
Pour valider votre implémentation de la fonctionnalité Passpoint, exécutez les tests unitaires du package Passpoint suivants:
Tests du service:
atest com.android.server.wifi.hotspot2
Tests administrateur:
atest android.net.wifi.hotspot2
Provisionnement Passpoint R1
Android est compatible avec Passpoint R1 depuis Android 6.0, ce qui permet de provisionner des identifiants Passpoint R1 (version 1) en téléchargeant un fichier spécial sur le Web contenant des informations sur le profil et les identifiants. Le client lance automatiquement un programme d'installation spécial pour les informations Wi-Fi et permet à l'utilisateur de consulter certaines d'entre elles avant d'accepter ou de refuser le contenu.
Les informations de profil contenues dans le fichier sont utilisées pour faire correspondre les données récupérées à partir des points d'accès compatibles avec Passpoint. Les identifiants sont automatiquement appliqués à tout réseau correspondant.
L'implémentation de référence Android est compatible avec EAP-TTLS, EAP-TLS, EAP-SIM, EAP-AKA et EAP-AKA'.
Mécanisme de téléchargement
Le fichier de configuration Passpoint doit être hébergé sur un serveur Web et doit être protégé par TLS (HTTPS), car il peut contenir un mot de passe en texte clair ou des données de clé privée. Le contenu est constitué de texte MIME en plusieurs parties encapsulé, représenté au format UTF-8 et encodé en base64 conformément à la section 6.8 du document RFC-2045.
Les champs d'en-tête HTTP suivants sont utilisés par le client pour lancer automatiquement un programme d'installation Wi-Fi sur l'appareil:
Content-Type
doit être défini surapplication/x-wifi-config
.Content-Transfer-Encoding
doit être défini surbase64
.Content-Disposition
ne doit pas être défini.
La méthode HTTP utilisée pour récupérer le fichier doit être GET. Chaque fois qu'une requête HTTP GET du navigateur reçoit une réponse avec ces en-têtes MIME, l'application d'installation est lancée. Le téléchargement doit être déclenché en appuyant sur un élément HTML, comme un bouton (les redirections automatiques vers une URL de téléchargement ne sont pas acceptées). Ce comportement est spécifique à Google Chrome. D'autres navigateurs Web peuvent ou non fournir des fonctionnalités similaires.
Composition des fichiers
Le contenu encodé en base64 doit consister en un contenu MIME multiparti avec un Content-Type
de multipart/mixed
. Les parties suivantes constituent les parties individuelles du contenu multipart.
Partie | Content-Type (moins de guillemets) | Obligatoire | Description |
---|---|---|---|
Profil |
application/x-passpoint-profile
|
Toujours | Charge utile au format SyncML OMA-DM contenant l'ordre de mise à jour au format PerProviderSubscription de Passpoint R1 pour HomeSP et Credential . |
Certificat de confiance |
application/x-x509-ca-cert
|
Obligatoire pour EAP-TLS et EAP-TTLS | Charge utile de certificat X.509v3 unique encodée en base64. |
Clé EAP-TLS |
application/x-pkcs12
|
Obligatoire pour EAP-TLS | Structure ASN.1 PKCS #12 encodée en base64 contenant une chaîne de certificats client comprenant au moins le certificat client et la clé privée associée. Le conteneur PKCS 12, ainsi que la clé privée et les certificats, doivent tous être au format texte brut sans mot de passe. |
La section "Profil" doit être transférée sous forme de texte XML encodé en base64 et en UTF-8 qui spécifie des parties des sous-arborescences HomeSP
et Credential
dans la section 9.1 de la spécification technique Passpoint R2 version 1.0.0.
Le nœud de niveau supérieur doit être MgmtTree
et le sous-nœud immédiat doit être PerProviderSubscription
. Un exemple de fichier XML apparaît dans Exemple de fichier XML OMA-DM de profil.
Les nœuds de sous-arbre suivants sont utilisés sous HomeSP
:
FriendlyName
: doit être défini et utilisé comme texte à afficherFQDN
: obligatoireRoamingConsortiumOI
Les nœuds de sous-arbre suivants sont utilisés sous Credential
:
Realm
: doit être une chaîne non videUsernamePassword
: obligatoire pour EAP-TTLS avec les nœuds suivants définis:Username
: chaîne contenant le nom d'utilisateurPassword
: chaîne encodée en base64 (définie surcGFzc3dvcmQ=
, la chaîne encodée en base64 pour "password", dans l'exemple ci-dessous).EAPMethod/EAPType
: doit être défini sur21
EAPMethod/InnerMethod
: doit être défini surPAP
,CHAP
,MS-CHAP
ouMS-CHAP-V2
.
DigitalCertificate
: obligatoire pour EAP-TLS. Les nœuds suivants doivent être définis:CertificateType
défini surx509v3
CertSHA256Fingerprint
défini sur le condensé SHA-256 correct du certificat client dans la section MIME de la clé EAP-TLS
SIM
: obligatoire pour EAP-SIM, EAP-AKA et EAP-AKA'. Le champEAPType
doit être défini sur le type EAP approprié, etIMSI
doit correspondre à un IMSI de l'une des cartes SIM installées sur l'appareil au moment du provisionnement. La chaîne IMSI peut consister entièrement en chiffres décimaux pour forcer une correspondance complète, ou en cinq ou six chiffres décimaux suivis d'un astérisque (*) pour assouplir la correspondance IMSI avec le MCC/MNC uniquement. Par exemple, la chaîne IMSI 123456* correspond à n'importe quelle carte SIM ayant le code MCC 123 et MNC 456.
Android 11 introduit des fonctionnalités qui rendent le provisionnement de Passpoint R1 plus flexible.
- Nom de domaine distinct pour l'authentification, l'autorisation et la traçabilité (AAA)
Les administrateurs de réseau Passpoint qui exigent un nom de domaine AAA spécifié indépendamment du nom de domaine complet (FQDN) annoncé par le réseau via le protocole ANQP (Access Network Query Protocol) peuvent spécifier une liste de FQDN séparés par une virgule dans un nouveau nœud sous le sous-arbre
Extension
. Il s'agit d'un nœud facultatif. Les appareils équipés d'Android 10 ou version antérieure l'ignorent.
Android
: sous-arbre de l'extension AndroidAAAServerTrustedNames
: obligatoire pour les noms approuvés du serveur AAA avec les nœuds suivants définis:FQDN
: chaîne contenant les noms de confiance du serveur AAA. Utilisez des points-virgules pour séparer les noms de confiance. Par exemple,example.org;example.com
.
- Autorités de certification racine privées autosignées
- Les administrateurs réseau Passpoint qui gèrent leurs certificats en interne peuvent provisionner des profils avec une autorité de certification autosignée privée pour l'authentification AAA.
- Autoriser l'installation de profils sans certificat CA racine
- Le certificat de l'autorité de certification racine associé au profil est utilisé pour l'authentification du serveur AAA. Les administrateurs réseau Passpoint qui souhaitent s'appuyer sur des autorités de certification racine publiques approuvées pour l'authentification de leur serveur AAA peuvent provisionner des profils sans certificat d'autorité de certification racine. Dans ce cas, le système vérifie les certificats de serveur AAA par rapport aux certificats d'autorité de certification racine publique installés dans le magasin de confiance.
Provisionnement Passpoint R2
Android 10 a introduit la prise en charge des fonctionnalités Passpoint R2. Passpoint R2 implémente l'inscription en ligne (OSU), une méthode standard pour provisionner de nouveaux profils Passpoint. Android 10 et versions ultérieures prennent en charge le provisionnement de profils EAP-TTLS à l'aide du protocole SOAP-XML sur l'ESS OSU ouvert.
Les fonctionnalités Passpoint R2 compatibles ne nécessitent que le code de référence AOSP (aucune prise en charge de pilote ou de micrologiciel supplémentaire n'est requise). Le code de référence AOSP inclut également une implémentation par défaut de l'UI Passpoint R2 dans l'application Paramètres.
Lorsqu'Android détecte un point d'accès Passpoint R2, le framework Android:
- Affiche la liste des fournisseurs de services annoncés par le point d'accès dans le sélecteur Wi-Fi (en plus des SSID).
- Invite l'utilisateur à appuyer sur l'un des fournisseurs de services pour configurer un profil Passpoint.
- Guide l'utilisateur tout au long du processus de configuration du profil Passpoint.
- Installe le profil Passpoint obtenu une fois l'opération terminée.
- S'associe au réseau Passpoint à l'aide du profil Passpoint nouvellement provisionné.
Fonctionnalités de Passpoint R3
Android 12 introduit les fonctionnalités Passpoint R3 suivantes, qui améliorent l'expérience utilisateur et permettent aux réseaux de se conformer aux lois locales:
- Conditions d'utilisation
L'acceptation des conditions d'utilisation est légalement obligatoire dans certains emplacements et dans certaines voies pour fournir un accès au réseau. Cette fonctionnalité permet aux déploiements réseau de remplacer les portails captifs non sécurisés, qui utilisent des réseaux ouverts, par un réseau Passpoint sécurisé. Une notification s'affiche lorsque l'utilisateur doit accepter les conditions d'utilisation.
L'URL des conditions d'utilisation doit rediriger vers un site Web sécurisé via HTTPS. Si l'URL pointe vers un site Web non sécurisé, le framework se déconnecte immédiatement et bloque le réseau.
- URL des informations sur le lieu
Permet aux opérateurs de réseaux et aux sites de fournir des informations supplémentaires à l'utilisateur, telles que des cartes de sites, des annuaires, des promotions et des bons de réduction. Une notification s'affiche lorsque le réseau est connecté.
L'URL des informations sur le lieu doit rediriger vers un site Web sécurisé utilisant le protocole HTTPS. Si l'URL pointe vers un site Web non sécurisé, le framework l'ignore et n'affiche aucune notification.
Autres fonctionnalités Passpoint
Android 11 introduit les fonctionnalités Passpoint suivantes qui améliorent l'expérience utilisateur, la consommation d'énergie et la flexibilité de déploiement.
- Application des dates d'expiration et notification
- L'application de dates d'expiration aux profils permet au framework d'éviter la connexion automatique aux points d'accès avec des identifiants expirés, qui sont voués à échouer. Cela évite d'utiliser du temps d'antenne, et économise la batterie et la bande passante du backend. Le framework affiche une notification à l'utilisateur lorsqu'un réseau correspondant à son profil est à portée et que le profil a expiré.
- Plusieurs profils avec un FQDN identique
- Les opérateurs qui déploient des réseaux Passpoint et utilisent plusieurs ID de réseau mobile terrestre public (PLMN) peuvent provisionner plusieurs profils Passpoint avec le même FQDN, un pour chaque ID PLMN, qui est automatiquement mis en correspondance avec la carte SIM installée et utilisé pour connecter le réseau.
Android 12 introduit les fonctionnalités Passpoint suivantes, qui améliorent l'expérience utilisateur, la consommation d'énergie et la flexibilité de déploiement:
- Préfixe d'identité décoré
- Lors de l'authentification sur des réseaux avec une décoration de préfixe, le préfixe d'identité décoré permet aux opérateurs réseau de mettre à jour l'identifiant d'accès réseau (NAI) pour effectuer un routage explicite via plusieurs proxys dans un réseau AAA (voir la RFC 7542). Android 12 implémente cette fonctionnalité conformément à la spécification WBA pour les extensions PPS-MO.
- Gestion imminente de la déconnexion
- Permet aux opérateurs réseau d'indiquer à un appareil que le service n'est pas disponible pour les identifiants utilisés pour s'authentifier sur le réseau pendant une certaine durée (spécifiée via un délai avant expiration). Après avoir reçu ce signal, les appareils ne tenteront pas de se reconnecter au réseau avec les mêmes identifiants tant que le délai d'expiration n'est pas écoulé. À l'inverse, les appareils qui ne prennent pas en charge cette fonctionnalité peuvent tenter de se reconnecter de manière répétée au réseau lorsque le service est indisponible.
Exemples de profils XML OMA-DM PerProviderSubscription-MO
Profil avec identifiants de nom d'utilisateur/mot de passe (EAP-TTLS)
L'exemple suivant illustre un profil pour un réseau avec:
- Nom de réseau convivial défini sur
Example Network
- Nom de domaine complet défini sur
hotspot.example.net
- OI du consortium d'itinérance (pour l'itinérance)
- Identifiants avec le nom d'utilisateur
user
, le mot de passepassword
encodé en base64 et le domaine défini surexample.net
- Méthode EAP définie sur
21
(EAP-TTLS) - Méthode interne de phase 2 définie sur
MS-CHAP-V2
- Autres noms de domaine AAA définis sur
trusted.com
ettrusted.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>
Profil avec des identifiants de certificat numérique (EAP-TLS)
L'exemple suivant illustre un profil pour un réseau avec:
- Nom de réseau convivial défini sur
GlobalRoaming
- Nom de domaine complet défini sur
globalroaming.net
- OI du consortium Roaming (pour l'itinérance)
- Domaine défini sur
users.globalroaming.net
- Identifiants avec un certificat numérique contenant l'empreinte spécifiée
<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>
Profil avec des identifiants SIM (EAP-AKA)
L'exemple suivant illustre un profil pour un réseau avec:
- Nom de réseau convivial défini sur
Purple Passpoint
- Nom de domaine complet défini sur
wlan.mnc888.mcc999.3gppnetwork.org
- Identifiants de la carte SIM avec l'ID PLMN
999888
- Méthode EAP définie sur
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>
Conseils d'authentification
Les appareils exécutant Android 8.x ou Android 9 avec un profil EAP-SIM, EAP-AKA ou EAP-AKA' Passpoint R1 ne se connectent pas automatiquement au réseau Passpoint. Ce problème affecte les utilisateurs, les opérateurs et les services en réduisant le déchargement Wi-Fi.
Segment | Conséquences | Étendue de l'impact |
---|---|---|
Opérateurs et fournisseurs de services Passpoint | Augmentation de la charge sur le réseau mobile | Tout opérateur utilisant Passpoint R1 |
Utilisateurs | Opportunité manquée de se connecter automatiquement aux points d'accès (PA) Wi-Fi de l'opérateur, ce qui entraîne des coûts de données plus élevés. | Tout utilisateur disposant d'un appareil fonctionnant sur un réseau de l'opérateur compatible avec Passpoint R1 |
Cause de l'échec
Passpoint spécifie un mécanisme permettant de faire correspondre un fournisseur de services annoncé (ANQP) à un profil installé sur l'appareil. Les règles de mise en correspondance suivantes pour EAP-SIM, EAP-AKA et EAP-AKA' constituent un ensemble partiel de règles axées sur les échecs 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.
Le deuxième critère a été modifié dans Android 8.0:
Else: If the PLMN ID (3GPP Network) matches AND the NAI Realm matches
then the service is a Roaming Service Provider.
Avec cette modification, le système n'a détecté aucune correspondance pour les fournisseurs de services qui fonctionnaient auparavant. Par conséquent, les appareils Passpoint ne se sont pas connectés automatiquement.
Solutions de contournement
Pour contourner le problème des critères de correspondance modifiés, les opérateurs et les fournisseurs de services doivent ajouter le domaine de l'identifiant d'accès au réseau (NAI) aux informations publiées par l'AP Passpoint.
La solution recommandée est que les fournisseurs de services réseau mettent en œuvre une solution de contournement côté réseau pour que le déploiement soit le plus rapide possible. Un correctif côté appareil dépend des OEM qui récupèrent une liste de modifications (CL) à partir d'AOSP, puis mettent à jour les appareils sur le terrain.
Correction de problème de réseau pour les opérateurs et les fournisseurs de services Passpoint
La solution de contournement côté réseau nécessite de reconfigurer le réseau pour ajouter l'élément ANQP du domaine NAI, comme indiqué ci-dessous. Les spécifications Passpoint n'exigent pas l'élément ANQP de domaine NAI, mais l'ajout de cette propriété est conforme aux spécifications Passpoint. Les implémentations client conformes aux spécifications ne devraient donc pas être interrompues.
- Ajoutez l'élément ANQP du domaine NAI.
- Définissez le sous-champ de domaine NAI pour qu'il corresponde au
Realm
du profil installé sur l'appareil. Définissez les informations suivantes en fonction de chaque type d'EAP:
- EAP-TTLS:définissez
EAPMethod(21)
et les types d'authentification interne compatibles (PAP
,CHAP
,MS-CHAP
ouMS-CHAP-V2
). - EAP-TLS:définissez
EAPMethod(13)
. - EAP-SIM:définir
EAPMethod(18)
- EAP-AKA:définissez
EAPMethod(23)
. - EAP-AKA' : définissez
EAPMethod(50)
.
- EAP-TTLS:définissez
Correction de l'appareil/AOSP pour les OEM
Pour implémenter un correctif côté appareil, les OEM doivent sélectionner le correctif CL aosp/718508. Ce correctif peut être appliqué aux versions suivantes (il ne s'applique pas à Android 10 ou version ultérieure):
- Android 9
- Android 8.x
Lorsque le correctif est récupéré, les OEM doivent mettre à jour les appareils sur le terrain.