正如@Colin 提到的，TI现在用于将网络 SSID 和关键字从设置应用程序传送到支持 CC3000 的设备的方案称为智能配置。

Smart Config 必须将信息（网络 SSID 和关键字）从安全的 wifi 网络传送到支持 CC3000 的设备，该设备还不能解密该网络上的流量。

最初 CC3000 未连接到网络（但可以监控流量），因此 Smart Config 应用程序无法将其信息直接发送到设备。相反，它将 UDP 数据包发送到网络上的另一台现有机器 - wifi 接入点 (AP)。AP 对接收它们不感兴趣是无关紧要的，重要的是数据包在网络上可见。

虽然 CC3000 可以监控它无法解密的流量，但它甚至无法确定给定的加密数据包是否包含 UDP 数据。那么它如何挑选出 UDP 数据包或对它们做任何有用的事情呢？

基本上，Smart Config 对其信息的编码不是在它发送的数据包的内容中，而是在它们的长度中。Wifi 加密会影响数据包的长度，但以一种一致的方式，即它会在每个数据包的大小上增加 L 个额外的字节，其中 L 是一个常数。

Smart Config 应用程序将 SSID 和关键字短语编码为一系列 UDP 数据包的数据包长度。CC3000 可以看到加密的数据包及其大小。

在许多环境中，CC3000 将能够查看来自多个附近网络的流量，那么它如何发现相关流量呢？即使在加密之后，仍然可以看到数据包的源和目标的 MAC 地址，因此可以通过这种方式对流量进行分组。除了 Smart Config 尝试发送的主要信息外，它还会定期发送重复的数据包长度模式，因此 CC3000 会按照描述对流量进行分组，然后在给定流量中找到此类模式时查找它们然后它专注于恢复主要信息的源和目标对。

显然不止于此，例如，即使 CC3000 找到了对应于 AP 和运行 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 中配置密码，并使用 CC3000 所期望的工作所需的必要 AES 转换。

最后是布丁的证明——我编写了一个应用程序来模拟 CC3000 的 Smart Config 相关行为，即它可以恢复任何 Smart Config 应用程序传输的 SSID 和 keyphrase，而无需能够解密相关的网络流量。您可以在此处找到下载源代码和所有详细信息的位置：

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 员工或我的信息（我最终学到了很多，但从一些不正确的假设/信念开始）。

专利已被多次提及，但我找不到任何证据表明该技术有专利正在申请或已授予。

注意如对此答案的评论和其他答案中所述，以下答案不反映当前程序。将此留作历史记录。

似乎 CC3000 实际上正在（以“混杂模式”）在所有 wifi 通道上侦听 AP 探测请求，被探测（和假）AP 的 SSID 包含 CC3000 配置自身以连接到“真实”所需的信息AP 通过它连接到 Internet。

经过一番搜索，我找到了设备首次配置的描述，应该清楚：

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

最有趣的一点：

需要将用于执行首次配置的手机或平板电脑等设备配置为连接到具有特制 SSID 的 AP。此 SSID 包括我们希望 CC3000 连接到的 SSID 的名称，以及有关安全选项的信息，例如安全类型和密钥。

查看此页面以获取信息。

AP 不参与此过程。CC3000 正在监听来自手机或其他设备的 UDP 数据包。此通信使用 AES 加密，两个设备都有它。手机在这些数据包中发送有关路由器 WPA2 密钥的信息。CC3000 知道手机使用的 AES 密钥，解码数据并连接到路由器。

@Greg Sadetsky 的回答（描述“首次配置”）很好地总结了基本过程。但在 TI 论坛的讨论中透露，CC3000 改变了执行这种自动配置的过程。新工艺被称为“smartconfig”而不是“首次配置”，TI 显然正在准备该技术的专利申请。它似乎使用了类似的方案，发送特殊的 Wi-Fi“探测”请求，巧妙地对 CC3000 的网络凭据进行编码。

如果您选择不使用 AES 加密密钥进行自动配置，smartconfig 算法将使用未记录的方法来混淆接入点 SSID 和安全密钥。这本质上并不安全，因为如果有人通过逆向工程或其他方式学习了混淆算法，无线网络的安全就会受到威胁。一旦提交专利申请，它就是公共领域知识，您必须使用具有 CC3000 自动配置模式的 AES 加密密钥以确保安全。

根据德州仪器对 2012-2013 年专利申请的审查（谷歌专利搜索链接：德州仪器，按最近申请日期排序） ，截至 2013 年 9 月，该专利申请尚未提交。

TI 已经承认非 AES 配置模式的不安全性，并表示他们将推荐使用 AES 并在未来将其设为默认设置。