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.