Wie @Colin erwähnt, wird das Schema, das TI jetzt verwendet, um eine Netzwerk-SSID und eine Schlüsselphrase von einer Setup-Anwendung an ein CC3000-fähiges Gerät zu übertragen, als Smart Config bezeichnet.
Smart Config muss Informationen (die Netzwerk-SSID und die Schlüsselphrase) von einem sicheren WLAN-Netzwerk an ein CC3000-fähiges Gerät übertragen, das den Datenverkehr in diesem Netzwerk noch nicht entschlüsseln kann.
Anfänglich ist der CC3000 nicht mit dem Netzwerk verbunden (kann jedoch den Datenverkehr überwachen ), sodass die Smart Config-Anwendung ihre Informationen nicht direkt an das Gerät senden kann. Stattdessen werden UDP-Pakete an einen anderen vorhandenen Computer im Netzwerk gesendet - den Wifi Access Point (AP). Dass der AP nicht daran interessiert ist, sie zu empfangen, ist irrelevant. Es ist nur wichtig, dass die Pakete im Netzwerk sichtbar sind.
Während der CC3000 den Datenverkehr überwachen kann, kann er ihn nicht entschlüsseln, er kann jedoch nicht sicher sagen, dass ein bestimmtes verschlüsseltes Paket UDP-Daten enthält. Wie kann es also die UDP-Pakete heraussuchen oder irgendetwas Nützliches damit anfangen?
Grundsätzlich codiert Smart Config seine Informationen nicht im Inhalt der gesendeten Pakete, sondern in ihrer Länge. Die WLAN-Verschlüsselung wirkt sich auf die Länge der Pakete aus, jedoch auf konsistente Weise, dh, sie fügt der Größe jedes Pakets L zusätzliche Bytes hinzu, wobei L eine Konstante ist.
Die Smart Config-Anwendung codiert die SSID und die Schlüsselphrase in die Paketlängen einer Sequenz von UDP-Paketen. Der CC3000 kann die verschlüsselten Pakete und ihre Größen sehen.
In vielen Umgebungen kann der CC3000 Datenverkehr von mehreren in der Nähe befindlichen Netzwerken sehen. Wie kann er den relevanten Datenverkehr erkennen? Selbst nach der Verschlüsselung kann man die MAC-Adressen der Quelle und des Ziels eines Pakets sehen, so dass man den Verkehr auf diese Weise gruppieren kann. Zusätzlich zu den primären Informationen, die Smart Config zu senden versucht, werden auch regelmäßig wiederkehrende Muster mit Paketlängen gesendet. Daher gruppiert der CC3000 den Datenverkehr wie beschrieben und sucht dann nach solchen Mustern, wenn er sie im Datenverkehr eines bestimmten Typs findet Das Quell- und Zielpaar wird dann fokussiert, um die primären Informationen wiederherzustellen.
Natürlich gibt es auch mehr als das: Wie filtert der CC3000 die Smart Config-Pakete aus anderem, nicht miteinander in Beziehung stehendem Datenverkehr zwischen dem AP und die Maschine? Ich habe das alles in einer Reihe von Blog-Posts geschrieben.
Das technisch ausführlichste behandelt das Herz von Smart Config - wie es die SSID und die Schlüsselphrase codiert und so überträgt, dass ein CC3000 sie abholen kann:
http://depletionregion.blogspot.ch/2013/10/cc3000-smart-config-transmitting-ssid.html
Dann habe ich einen Beitrag, der weniger technisch ist, als vielmehr eine Meinung dazu, warum Sie in Smart Config immer einen AES-Schlüssel verwenden sollten:
http://depletionregion.blogspot.ch/2013/10/cc3000-smart-config-and-aes.html
In der Mitte befindet sich ein technisches Teil, in dem kurz beschrieben wird, wie Sie eine Verschlüsselung in Java mit der erforderlichen AES-Umwandlung konfigurieren, die für den erwarteten Betrieb des CC3000 erforderlich ist.
Und schließlich der Beweis für den Pudding: Ich habe eine Anwendung geschrieben, mit der das Smart Config-bezogene Verhalten des CC3000 nachgebildet werden kann, dh die SSID und die Schlüsselphrase, die von jeder Smart Config-Anwendung übertragen werden, können wiederhergestellt werden, ohne dass der relevante Netzwerkverkehr entschlüsselt werden muss. Hier können Sie den Quellcode und alle Details herunterladen:
http://depletionregion.blogspot.ch/2013/10/cc3000-smart-config-and-keyphrase.html
Dies sollte es einem ermöglichen, das Verhalten jeder Smart Config-Anwendung zu testen, die man schreibt, dh man kann sehen, was ein CC3000 aus den von der Anwendung übertragenen Daten rekonstruieren kann.
Ich habe auch ein paar weitere Beiträge zu Smart Config / CC3000:
http://depletionregion.blogspot.ch/search/label/CC3000
Für einige Hintergrundinformationen kann es auch interessant sein, diese Threads im für den CC3000 relevanten TI-Forum durchzulesen.
Erste, die Smart Config selbst behandelt:
http://e2e.ti.com/support/low_power_rf/f/851/t/253463.aspx
Und einer in mDNS, dem Mechanismus, mit dem eine Smart Config-Anwendung erkennt, dass ein CC3000-fähiges Gerät dem Netzwerk beigetreten ist:
http://e2e.ti.com/support/low_power_rf/f/851/p/290584/1020839.aspx
In beiden Threads scheinen einige anfängliche Nachrichten nicht so relevant zu sein, aber es gibt auch einige interessante Informationen. Es gibt aber auch eine Menge ungenauer Informationen. Gehen Sie also nicht davon aus, dass alle Informationen korrekt sind, auch nicht von TI-Mitarbeitern oder von mir.
Patente wurden einige Male erwähnt, ich kann jedoch keine Beweise dafür finden, dass für diese Technologie Patente angemeldet oder erteilt wurden.