Comment fonctionne la configuration intelligente TI CC3000 wifi?

La puce wifi ti cc3000 a un mode de configuration intelligent spécial, c'est pour permettre la configuration initiale des détails d'accès wifi.

La page wiki cc3000 donne quelques détails sur le fonctionnement du processus,

1. La puce entre en mode d'écoute de configuration intelligente
2. L'application sur le téléphone intelligent envoie un paquet "UDP" avec les paramètres du point d'accès
3. La puce capture ces données et se configure

Je suis au courant de la capture de paquets et du reniflage wifi, mais comment la puce "décrypte" -elle le paquet brut pour en tirer des informations? J'utilise wpa2-personal avec AES sur mon routeur.

Comme @Colin mentionne le schéma que TI utilise maintenant pour communiquer un SSID réseau et une phrase clé à partir d'une application de configuration vers un appareil compatible CC3000 est appelé Smart Config.

Smart Config doit communiquer des informations (le SSID du réseau et la phrase clé) d'un réseau wifi sécurisé à un appareil compatible CC3000 qui n'est pas encore en mesure de décrypter le trafic sur ce réseau.

Initialement, le CC3000 n'est pas connecté au réseau (mais peut surveiller le trafic), de sorte que l'application Smart Config ne peut pas envoyer ses informations directement à l'appareil. Au lieu de cela, il envoie des paquets UDP à une autre machine existante sur le réseau - le point d'accès wifi (AP). Que l'AP ne souhaite pas les recevoir n'est pas pertinent, il est juste important que les paquets soient visibles sur le réseau.

Bien que le CC3000 puisse surveiller le trafic, il ne peut pas le déchiffrer, il ne peut même pas dire avec certitude qu'un paquet chiffré donné contient des données UDP. Alors, comment peut-il choisir les paquets UDP ou faire quelque chose d'utile avec eux?

Fondamentalement, Smart Config code ses informations non pas dans le contenu des paquets qu'il envoie mais dans leur longueur. Le cryptage Wifi affecte la longueur des paquets, mais de manière cohérente, c'est-à-dire qu'il ajoute L octets supplémentaires à la taille de chaque paquet, où L est une constante.

L'application Smart Config code le SSID et la phrase clé en longueurs de paquets d'une séquence de paquets UDP. Le CC3000 peut voir les paquets chiffrés et leurs tailles.

Dans de nombreux environnements, le CC3000 sera en mesure de voir le trafic provenant de plusieurs réseaux à proximité, alors comment peut-il détecter le trafic pertinent? Même après le chiffrement, on peut toujours voir les adresses MAC de la source et de la destination d'un paquet afin de pouvoir regrouper le trafic de cette façon. En plus des informations principales que Smart Config essaie d'envoyer, il envoie également des motifs répétitifs de longueurs de paquets, de sorte que le CC3000 regroupe le trafic comme décrit, puis recherche ces modèles lorsqu'il les trouve dans le trafic d'un paire source et destination dans laquelle il se concentre pour récupérer les informations principales.

Il y a évidemment plus que cela, par exemple, même une fois que le CC3000 a trouvé la paire source et destination, qui correspond à l'AP et à la machine exécutant l'application Smart Config, comment filtre-t-il les paquets Smart Config des autres trafics sans rapport entre le AP et la machine? J'ai tout écrit dans une série de billets de blog.

Le plus détaillé techniquement couvre le cœur de Smart Config - comment il code le SSID et la phrase clé et les transmet de sorte qu'un CC3000 puisse les récupérer:

http://depletionregion.blogspot.ch/2013/10/cc3000-smart-config-transmitting-ssid.html

Ensuite, j'ai un article moins technique, plus un article d'opinion sur la raison pour laquelle vous devriez toujours utiliser une clé AES avec Smart Config:

http://depletionregion.blogspot.ch/2013/10/cc3000-smart-config-and-aes.html

Il y a un élément technique au milieu qui décrit brièvement comment configurer un chiffrement en Java avec la transformation AES nécessaire pour fonctionner comme le CC3000 le souhaite.

Et enfin la preuve du pudding - j'ai écrit une application pour émuler le comportement lié à Smart Config du CC3000, c'est-à-dire qu'il peut récupérer le SSID et la phrase clé transmis par n'importe quelle application Smart Config sans avoir besoin de pouvoir décrypter le trafic réseau pertinent. Vous pouvez trouver où télécharger la source et tous les détails ici:

http://depletionregion.blogspot.ch/2013/10/cc3000-smart-config-and-keyphrase.html

Cela devrait permettre de tester le comportement de toute application Smart Config que l'on écrit, c'est-à-dire que l'on peut voir ce qu'un CC3000 pourrait reconstruire à partir des données transmises par l'application.

J'ai également quelques autres articles liés à Smart Config / CC3000:

http://depletionregion.blogspot.ch/search/label/CC3000

Pour quelques informations générales, il peut également être intéressant de lire ces discussions sur le forum TI concernant le CC3000.

Premier couvrant Smart Config lui-même:

http://e2e.ti.com/support/low_power_rf/f/851/t/253463.aspx

Et un sur mDNS, le mécanisme par lequel une application Smart Config détecte qu'un appareil compatible CC3000 a rejoint le réseau:

http://e2e.ti.com/support/low_power_rf/f/851/p/290584/1020839.aspx

Dans les deux fils, certains messages initiaux peuvent ne pas sembler si pertinents, mais il y a aussi des informations intéressantes mélangées. Mais il y a aussi beaucoup d'informations inexactes, alors ne présumez pas qu'elles sont toutes correctes, même les informations des employés de TI ou de moi (j'ai finalement beaucoup appris mais j'ai commencé avec des hypothèses / croyances incorrectes).

Les brevets ont été mentionnés à plusieurs reprises, mais je ne trouve aucune preuve qu'il y a des brevets en instance ou accordés sur cette technologie.

NB Comme indiqué dans les commentaires de cette réponse et dans les autres réponses, la réponse ci-dessous ne reflète pas la procédure actuelle. Laissant cela pour le dossier historique.

Il semble que le CC3000 écoute réellement (en "mode promiscuité") sur tous les canaux wifi une demande de sonde AP, le SSID de l'AP sondé (et faux) contenant les informations dont le CC3000 a besoin pour se configurer pour se connecter au "vrai". AP via lequel il se connectera à Internet.

Après avoir cherché un peu, j'ai trouvé cette description de la première configuration de l'appareil qui devrait être claire:

http://processors.wiki.ti.com/index.php/CC3000_First_Time_Configuration

Bit le plus intéressant:

Un périphérique tel qu'un téléphone mobile ou une tablette utilisé pour effectuer une première configuration doit être configuré pour se connecter à un point d'accès avec un SSID spécialement conçu. Ce SSID comprend le nom du SSID auquel nous voulons que le CC3000 se connecte, ainsi que des informations sur les options de sécurité telles que le type et la clé de sécurité.

Regardez cette page pour plus d'informations.

L'AP n'est pas impliqué dans ce processus. Le CC3000 écoute les paquets UDP à partir du téléphone mobile ou d'un autre appareil. Cette communication est cryptée avec AES, les deux appareils l'ayant. Le téléphone mobile envoie des informations sur la clé WPA2 du routeur dans ces paquets. Le CC3000 connaît la clé AES utilisée par le téléphone mobile, décode les données et se connecte au routeur.

La réponse de @Greg Sadetsky (décrivant la "Première configuration") résume bien le processus de base. Mais il a été révélé lors de la discussion sur le forum TI que le CC3000 a changé le processus par lequel cette configuration automatique est effectuée. Le nouveau processus est appelé "smartconfig" au lieu de la première configuration, et TI prépare apparemment une demande de brevet pour la technologie. Il semble utiliser un schéma similaire où des demandes spéciales de "sonde" Wi-Fi sont envoyées, qui codent intelligemment les informations d'identification réseau pour le CC3000.

Si vous choisissez de ne pas utiliser de clé de chiffrement AES pour la configuration automatique, l'algorithme smartconfig utilise une méthode non documentée pour masquer le SSID du point d'accès et la clé de sécurité. Ce n'est pas intrinsèquement sûr car si quelqu'un apprend l'algorithme d'obscurcissement, par rétro-ingénierie ou par d'autres moyens, la sécurité du réseau sans fil est compromise. Une fois la demande de brevet déposée, elle appartient au domaine public et vous devez utiliser une clé de cryptage AES avec le mode de configuration automatique CC3000 pour être sécurisé.

En septembre 2013, la demande de brevet n'avait pas été déposée, sur la base de l'examen des demandes de brevet 2012-2013 par Texas Instruments ( Google Patent Search Link: Texas Instruments, trié par date de dépôt la plus récente ).

TI a reconnu l'insécurité du mode de configuration non AES et a déclaré qu'il recommanderait d'utiliser AES et en ferait la valeur par défaut à l'avenir .