Midea PortaSplit dans Home Assistant : pourquoi le token et la clé sont décisifs

La commande locale de la Midea PortaSplit repose sur deux valeurs spécifiques à l’appareil : le token et la clé. Lors de la configuration, l’intégration Home Assistant récupère ces deux valeurs via un point de terminaison privé du cloud Midea. Elle envoie ensuite les commandes directement sur le réseau local.

Le projet Midea AC LAN met en garde contre d’éventuelles modifications de ces interfaces cloud. Des analyses plus récentes montrent toutefois qu’il est impossible d’en déduire une feuille de route confirmée du fabricant ou une date précise d’arrêt. Cet article explique cette dépendance technique ; l’analyse détaillée de l’API replace les différentes dénominations « V2 » et la situation actuelle dans leur contexte.

La question du token en détail

Pourquoi Home Assistant pouvait-il jusqu’à présent obtenir le token ?

La communauté n’a jamais calculé le token. Elle a plutôt analysé le trafic réseau de l’application officielle et constaté que celle-ci ne génère pas elle-même le token, mais l’obtient depuis le cloud :

App
   ↓
Midea Cloud
   ↓
Cloud liefert Token
   ↓
App verwendet Token lokal

L’intégration Home Assistant a réimplémenté exactement cet appel au cloud. Elle se connecte au cloud avec les mêmes points de terminaison et selon le même processus que l’application, et obtient ainsi le même token et la même clé. Le fondement réel est donc une récupération reproduite, non un calcul. Si le point de terminaison disparaît, l’obtention disparaît également.

Pourrait-on extraire le token de l’application officielle ?

Théoriquement, oui. L’application doit connaître le token à un moment donné, faute de quoi elle ne pourrait pas communiquer localement avec l’appareil. Les méthodes envisageables seraient notamment :

• l’ingénierie inverse de l’application,
• l’écoute du trafic réseau, si celui-ci n’est pas protégé en plus,
• l’instrumentation de l’application à l’exécution, par exemple avec Frida ou Objection,
• le hooking des fonctions qui traitent le token.

C’est précisément ce que vise l’affirmation du développeur de Midea AC LAN selon laquelle la conception actuelle constitue, du point de vue de Midea, un problème de sécurité : un secret durable pouvant être extrait, avec des efforts raisonnables, d’une application largement distribuée est difficile à contrôler. Pour l’utilisateur individuel, ces méthodes sont toutefois complexes et ne remplacent pas la récupération pratique via le cloud.

Pourrait-on obtenir le token directement auprès de l’appareil ?

Ce serait la solution la plus élégante. Si l’appareil échangeait une clé publique lors du premier appairage local ou utilisait un code d’appairage unique via Bluetooth, le cloud ne serait pas nécessaire. De nombreux appareils IoT modernes fonctionnent exactement ainsi.

Midea a toutefois conçu le protocole LAN d’origine autrement : l’appareil n’accepte les commandes locales qu’avec les identifiants appropriés liés au cloud. Il n’existe aucun mécanisme d’appairage local documenté qui fournirait le token sans passer par le cloud. Le cloud n’est donc pas seulement une commodité, mais constitue sur le plan architectural la seule voie prévue vers le token.

La communauté pourrait-elle contourner des modifications du point de terminaison du token ?

Cela ne serait possible que si l’une des options suivantes était trouvée :

• une nouvelle API cloud qui continuerait de fournir des tokens,
• une méthode d’appairage locale jusqu’ici inconnue,
• une vulnérabilité dans l’appareil,
• ou si Midea publiait elle-même un jour une API locale officielle.

En revanche, il est très peu probable qu’il soit possible de simplement « recalculer » le token. Si c’était possible, la communauté l’aurait probablement mis en œuvre depuis longtemps et n’aurait jamais dépendu de l’API cloud. Le fait même que ce détour par le cloud ait été construit est l’indice le plus fort qu’il n’existe pas de voie locale plus simple.

L’avertissement de Midea AC LAN

Le dépôt de Midea AC LAN contient un « Important Notice » affiché de manière bien visible. Selon le développeur, Midea a déjà fermé les API de token côté serveur dans les clouds Meiju et SmartHome. L’intégration utilise donc actuellement les interfaces de token du cloud NetHome Plus, et celles-ci devraient elles aussi être fermées progressivement. Il en résulterait que les appareils déjà configurés continueraient à fonctionner localement, mais que de nouveaux appareils ne pourraient plus être ajoutés. Le développeur va plus loin et écrit que Midea souhaite à long terme passer à une nouvelle API Cloud Control, rendant ainsi inutilisable l’ancienne API LAN V1.

L’avertissement a une brève histoire. Le « Important Notice » bien visible a été ajouté au README le 19 mai 2025 (pull request no 578) et indiquait alors le cloud SmartHome comme solution de repli pour ajouter de nouveaux appareils. Le 14 juillet 2025 (no 639), il a été mis à jour ; depuis, il renvoie au cloud NetHome Plus, car Midea avait fermé d’autres points de terminaison. Le message principal est resté inchangé dans les deux versions : les interfaces de token disparaissent progressivement, seul le cloud encore utilisable change à chaque fois.

Il faut considérer cela avec nuance. Il s’agit de l’évaluation d’un projet open source, et non d’une feuille de route contraignante de Midea, et le calendrier est inconnu. Une future mise à jour du firmware peut modifier les fonctions locales ; un token déjà enregistré peut continuer à fonctionner, mais pas nécessairement indéfiniment. Un retour aux paramètres d’usine, le remplacement du module Wi-Fi ou un nouvel appareil peuvent nécessiter l’obtention d’un nouveau token.

Les trois mesures de l’encadré au début de l’article en découlent, chacune avec sa justification :

• Ne pas remplacer sans raison une configuration fonctionnelle. L’obtention du token est la seule étape qui passe obligatoirement par le cloud Midea. Des modifications du point de terminaison privé peuvent surtout affecter une nouvelle configuration ultérieure.
• Sauvegarder les identifiants. Home Assistant enregistre le token et la clé localement. Un système défectueux, une restauration ratée ou une intégration supprimée par erreur peuvent néanmoins rendre la commande locale inutilisable en l’absence de sauvegarde externe.
• Ne pas dissocier l’appareil à la légère. Il n’est pas entièrement documenté si une réinitialisation d’usine ou la suppression du compte Midea impose de nouveaux identifiants pour chaque modèle. Une sauvegarde avant de telles modifications est donc indispensable.

Le fonctionnement courant n’est pas affecté dans un premier temps : la commande locale utilise les valeurs déjà enregistrées et n’a plus besoin du point de terminaison du token. Un risque résiduel demeure si un futur firmware modifie le protocole local ou l’authentification. Le guide pratique sur la configuration explique comment sauvegarder le token, la clé et la configuration.

Ce que cela signifie pour la sécurité

Outre la disponibilité, l’avertissement comporte un aspect de sécurité. Selon Midea AC LAN, l’ancienne architecture LAN repose sur une hypothèse problématique : la communication client était initialement considérée comme suffisamment protégée, raison pour laquelle les tokens émis par le cloud n’avaient pas de date d’expiration.

Un token sans expiration n’est pas en soi une vulnérabilité. Il devient problématique lorsqu’il se retrouve dans des journaux ou des sauvegardes non protégées, tombe entre les mains de tiers, ou ne peut être ni révoqué ni renouvelé. Le développeur de Midea AC LAN suppose que Midea réagit à ces risques par des modifications des services de token et une architecture davantage fondée sur le cloud. Toutefois, aucune annonce correspondante du fabricant avec calendrier n’est établie.

La précision terminologique est importante. L’intégration communautaire ne « pirate » pas le climatiseur. Elle implémente un protocole propriétaire qui a été compris par ingénierie inverse. Le problème de sécurité vient du fait que des secrets durables peuvent être utilisés et enregistrés en dehors de l’application initialement prévue.

Pour l’exploitation sur son propre réseau, l’essentiel est ce que permettent le token et la clé. Ils authentifient tous deux la communication locale avec l’appareil. S’ils tombent entre de mauvaises mains, un attaquant pourrait, selon le protocole et sa position sur le réseau, détecter l’appareil, s’authentifier auprès de lui, lire des informations d’état, modifier des paramètres, allumer ou éteindre le climatiseur, changer de mode de fonctionnement et modifier la température de consigne. L’attaquant doit toutefois généralement pouvoir établir une connexion réseau avec l’appareil ; la seule possession du token et de la clé ne permet pas une attaque depuis l’ensemble d’Internet. Le token et la clé doivent donc être traités comme un mot de passe. Le deuxième volet traite de l’intégration de l’appareil au réseau afin que ces valeurs causent peu de dommages même en cas de problème.

Ce qui reste en pratique

La commande locale de la PortaSplit dépend entièrement du token et de la clé, qui ne peuvent actuellement être obtenus que via le cloud Midea. Ce détour fait partie de la conception du protocole : les commandes locales sont liées à des identifiants associés au cloud. Le point de terminaison étant privé et non documenté, la disponibilité à long terme de l’intégration non officielle reste incertaine.

En pratique, cela signifie : sauvegarder les identifiants et la configuration, ne pas dissocier inutilement une configuration fonctionnelle et surveiller les modifications de l’intégration et du firmware. Les appareils déjà configurés continuent de fonctionner localement. Le guide pratique sur la PortaSplit décrit la configuration, la sauvegarde et la protection réseau.