Как @Colin упоминает схему, которую TI теперь использует для передачи сетевого SSID и ключевой фразы из приложения установки на устройство с поддержкой CC3000, называется Smart Config.
Smart Config должен передавать информацию (сетевой SSID и ключевую фразу) из защищенной сети Wi-Fi на устройство с поддержкой CC3000, которое еще не может расшифровать трафик в этой сети.
Изначально CC3000 не подключен к сети (но может отслеживать трафик), поэтому приложение Smart Config не может отправлять свою информацию непосредственно на устройство. Вместо этого он отправляет пакеты UDP на другой существующий компьютер в сети - точку доступа Wi-Fi (AP). То, что AP не заинтересована в их получении, не имеет значения, просто важно, чтобы пакеты были видны в сети.
Хотя CC3000 может отслеживать трафик, он не может его расшифровать, но он даже не может точно сказать, что данный зашифрованный пакет содержит данные UDP. Так как же он может выбрать пакеты UDP или сделать что-нибудь полезное с ними?
В основном Smart Config кодирует свою информацию не в содержимом отправляемых пакетов, а в их длине. Шифрование Wi-Fi влияет на длину пакетов, но согласованным образом, то есть добавляет L дополнительных байтов к размеру каждого пакета, где L - это константа.
Приложение Smart Config кодирует SSID и ключевую фразу в длины пакетов последовательности пакетов UDP. CC3000 может видеть зашифрованные пакеты и их размеры.
Во многих средах CC3000 сможет видеть трафик из нескольких соседних сетей, так как же он может обнаружить соответствующий трафик? Даже после шифрования можно по-прежнему видеть MAC-адреса источника и назначения пакета, поэтому можно группировать трафик таким образом. В дополнение к основной информации, которую Smart Config пытается отправить, он также отправляет регулярно повторяющиеся шаблоны длин пакетов, поэтому CC3000 группирует трафик, как описано, и затем ищет такие шаблоны, когда находит их в трафике данного исходная и целевая пары затем фокусируются на восстановлении первичной информации.
Это, очевидно, и нечто большее, например, даже когда CC3000 обнаружил пару источника и назначения, которые соответствуют точке доступа и машине, на которой запущено приложение Smart Config, как он фильтрует пакеты Smart Config от другого несвязанного трафика, проходящего между AP и машина? Я написал все это в серии постов в блоге.
Наиболее технически подробный рассказывает о сути Smart Config - о том, как он кодирует SSID и ключевую фразу и передает их так, что CC3000 может их подобрать:
http://depletionregion.blogspot.ch/2013/10/cc3000-smart-config-transmitting-ssid.html
Тогда у меня есть пост, который менее технический, более подробный, чтобы узнать, почему вы всегда должны использовать ключ AES со Smart Config:
http://depletionregion.blogspot.ch/2013/10/cc3000-smart-config-and-aes.html
В середине есть технический раздел, в котором кратко описывается, как настроить шифр в Java с необходимым преобразованием AES, необходимым для работы, как ожидает CC3000.
И, наконец, доказательство пудинга - я написал приложение для эмуляции поведения CC3000, связанного со Smart Config, то есть он может восстановить SSID и ключевую фразу, переданные любым приложением Smart Config, без необходимости расшифровывать соответствующий сетевой трафик. Вы можете найти где скачать исходники и все подробности здесь:
http://depletionregion.blogspot.ch/2013/10/cc3000-smart-config-and-keyphrase.html
Это должно позволить протестировать поведение любого приложения Smart Config, которое он пишет, т.е. можно увидеть, что CC3000 сможет восстановить из данных, переданных приложением.
У меня также есть еще несколько сообщений, связанных с Smart Config / CC3000:
http://depletionregion.blogspot.ch/search/label/CC3000
Для некоторой справочной информации также может быть интересно прочитать эти темы на форуме TI, имеющем отношение к CC3000.
Первый, охватывающий сам Smart Config:
http://e2e.ti.com/support/low_power_rf/f/851/t/253463.aspx
И один на mDNS, механизм, с помощью которого приложение Smart Config обнаруживает, что устройство с поддержкой CC3000 присоединилось к сети:
http://e2e.ti.com/support/low_power_rf/f/851/p/290584/1020839.aspx
В обоих потоках некоторые первоначальные сообщения могут показаться не такими актуальными, но есть и некоторая интересная информация. Но есть также много неточной информации, поэтому не думайте, что все это правильно, даже информация от сотрудников TI или от меня (я многому научился, но начал с некоторых неправильных предположений / убеждений).
Патенты упоминались несколько раз, однако я не могу найти никаких доказательств того, что есть патенты, ожидающие или выданные на эту технологию.