Kuten @Colin mainitsee mallin, jota TI nyt käyttää verkon SSID: n ja avainsanan välittämiseen asennusohjelmasta CC3000-yhteensopivaan laitteeseen, kutsutaan Smart Configiksi.

Smart Config täytyy kommunikoida tiedot (verkon SSID ja avainlause) suojatusta wifi-verkosta CC3000-yhteensopivaan laitteeseen, joka ei vielä pysty purkamaan kyseisen verkon liikennettä.

Aluksi CC3000 ei ole kytketty verkkoon (mutta voi seurata liikennettä), joten Smart Config -sovellus ei voi lähettää tietojaan suoraan laitteeseen. Sen sijaan se lähettää UDP-paketteja toiselle verkossa olevalle koneelle - wifi-tukiasemalle (AP). Sillä, että tukiasema ei ole kiinnostunut niiden vastaanottamisesta, ei ole merkitystä, on vain tärkeää, että paketit näkyvät verkossa.

Vaikka CC3000 pystyy seuraamaan liikennettä, se ei voi purkaa sitä, mutta ei jopa sanoa varmasti, että tietty salattu paketti sisältää UDP-tietoja. Joten miten se voi poimia UDP-paketit tai tehdä mitään hyödyllistä niiden kanssa?

Pohjimmiltaan Smart Config koodaa tietojaan lähettämättömien pakettien sisältöön, mutta niiden pituuteen. Wifi-salaus vaikuttaa pakettien pituuteen, mutta johdonmukaisella tavalla, eli se lisää L lisää tavuja jokaisen paketin kokoon, jossa L on vakio.

Smart Config -sovellus koodaa SSID: n ja avainsanan UDP-pakettisekvenssin pakettipituudet. CC3000 voi nähdä salatut paketit ja niiden koot.

Monissa ympäristöissä CC3000 pystyy näkemään liikenteen useista läheisistä verkoista, joten miten se pystyy havaitsemaan asiaankuuluvan liikenteen? Jopa salauksen jälkeen voidaan silti nähdä paketin lähteen ja kohteen MAC-osoitteet, jotta liikenne voidaan ryhmittää tällä tavalla. Sen lisäksi, että Smart Config yrittää lähettää niitä ensisijaisia ​​tietoja, se lähettää säännöllisesti toistuvia pakettipituuksia, joten CC3000 ryhmittelee liikenteen kuvatulla tavalla ja etsii sitten tällaisia ​​malleja, kun se löytää ne tietyn liikenteestä. lähde- ja kohdepari se keskittyy sitten palauttamaan ensisijaiset tiedot.

Siinä on ilmeisesti enemmän kuin esim. vaikka CC3000 on löytänyt lähde- ja kohdeparin, jotka vastaavat tukiasemaa ja Smart Config -sovellusta käyttävää laitetta, miten se suodattaa Smart Config -paketit muusta etuyhteydettömästä liikenteestä AP: n ja koneen välillä? Olen kirjoittanut tämän kaiken sarjaan blogiviestejä.

Teknisimmin yksityiskohtaisin kattaa Smart Configin ytimen - miten se koodaa SSID: n ja avainsanan ja lähettää ne siten, että CC3000 voi valita ne ylöspäin:

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

Sitten minä sinulla on vähemmän tekninen viesti, enemmän mielipide siitä, miksi sinun tulisi aina käyttää AES-avainta Smart Config -ohjelmassa:

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

Keskellä on tekninen bitti, joka kuvaa lyhyesti, kuinka määrität Java-salauksen tarvittavalla AES-muunnoksella toimiakseen CC3000 odottaa.

Ja lopuksi todiste vanukasta - kirjoitin sovelluksen jäljittelemään CC3000: n Smart Config -käyttäytymistä, eli se voi palauttaa minkä tahansa Smart Config -sovelluksen lähettämän SSID: n ja avainsanan tarvitsematta purkaa asianmukaista verkkoa liikenne. Löydät lähteen ja kaikki yksityiskohdat täältä:

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

Tämän pitäisi antaa mahdollisuuden testata minkä tahansa kirjoittaman Smart Config -sovelluksen käyttäytymistä, eli voidaan nähdä, mitä CC3000 pystyy rekonstruoimaan sovelluksen lähettämistä tiedoista.

Minulla on myös muutama lisää Smart Config / CC3000: een liittyviä viestejä:

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

Joidenkin taustatietojen vuoksi voi olla myös mielenkiintoista lukea nämä ketjut CC3000: n kannalta merkityksellisestä TI-keskustelupalstasta.

Ensimmäinen, joka kattaa itsensä Smart Config:

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

Ja yksi mDNS: stä, mekanismi, jolla Smart Config -sovellus havaitsee, että CC3000 käytössä oleva laite on liittynyt verkkoon:

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

Molemmissa säikeissä alku m esseet eivät ehkä näytä niin merkityksellisiltä, ​​mutta myös mielenkiintoista tietoa on sekoitettu. Mutta siellä on myös paljon epätarkkoja tietoja, joten älä oleta, että kaikki se on oikein, jopa TI-työntekijöiden tai minun antamani tiedot (opin lopulta paljon, mutta aloitin väärillä oletuksilla / uskomuksilla).

Patentteja on mainittu muutaman kerran, mutta en löydä todisteita siitä, että tälle tekniikalle on vireillä tai myönnetty patentteja.

Huom. Kuten tämän vastauksen kommenteissa ja muissa vastauksissa todettiin, alla oleva vastaus ei vastaa nykyistä menettelyä. Jättämällä tämä historialliseen tietueeseen.

Vaikuttaa siltä, ​​että CC3000 kuuntelee ("epäselvässä tilassa") kaikilla wifi-kanavilla AP-koetuspyyntöä, testatun (ja väärennetyn) AP: n SSID: tä sisältää tiedot, jotka CC3000 tarvitsee konfiguroimaan itsensä muodostamaan yhteyden "oikeaan" AP: hen, jonka kautta se muodostaa yhteyden Internetiin.

Hieman etsinyt, löysin tämän kuvauksen laitteen ensimmäisestä kokoonpanosta, joka pitäisi tehdä selväksi:

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

Mielenkiintoisin bitti:

Laite, kuten matkapuhelin tai tabletti, jota käytetään ensimmäisessä kokoonpanossa, on määritettävä muodostamaan yhteys tukiasemaan erityisen SSID: n avulla. Tämä SSID sisältää sen SSID: n nimen, johon haluamme CC3000: n muodostavan yhteyden, sekä tietoja suojausvaihtoehdoista, kuten suojaustyypistä ja avaimesta.

Katso lisätietoja tältä sivulta.

AP ei ole mukana tässä prosessissa. CC3000 kuuntelee UDP-paketteja matkapuhelimesta tai muusta laitteesta. Tämä tiedonsiirto on salattu AES: llä, molemmilla laitteilla. Matkapuhelin lähettää tietoja reitittimen WPA2-avaimesta näissä paketeissa. CC3000 tuntee matkapuhelimen käyttämän AES-avaimen, purkaa tiedot ja muodostaa yhteyden reitittimeen.

@Greg Sadetskyn vastaus (joka kuvaa "Ensimmäisen kokoonpanon määritystä") tiivistää perusprosessin hyvin. Mutta TI-foorumin keskustelussa paljastui, että CC3000 on muuttanut prosessia, jolla tämä automaattinen kokoonpano suoritetaan. Uusi prosessi on nimeltään "smartconfig" First Time Configurationin sijaan, ja TI ilmeisesti valmistelee tekniikkaa koskevaa patenttihakemusta. Vaikuttaa siltä, ​​että se käyttää samanlaista järjestelmää, jossa lähetetään erityisiä Wi-Fi-"koettimen" pyyntöjä, jotka koodaavat älykkäästi CC3000: n verkon tunnistetiedot.

Jos et halua käyttää AES-salausavainta automaattiseen määritykseen , smartconfig-algoritmi käyttää dokumentoimattomaa menetelmää tukiaseman SSID: n ja suojausavaimen hämärtämiseksi. Tämä ei ole luonnostaan ​​turvallista, koska jos joku oppii hämärtämisalgoritmin käänteisen suunnittelun tai muilla keinoilla, langattoman verkon turvallisuus vaarantuu. Kun patenttihakemus on jätetty, se on julkista tietoa ja sinun on käytettävä AES-salausavainta automaattisen CC3000-määritystilan kanssa turvallisuuden varmistamiseksi.

Syyskuusta 2013 lähtien patenttihakemusta ei ole jätetty , perustuu Texas Instrumentsin vuosina 2012--2013 tekemiin patenttihakemuksiin ( Google Patent Search Link: Texas Instruments, lajiteltu viimeisimmän hakemuksen päivämäärän mukaan).

TI on tunnustanut ei-AES-määritystilan epävarmuus ja on sanonut suosittelevansa AES: n käyttöä ja asettavan sen oletukseksi tulevaisuudessa.