TI CC3000 wifiスマート構成はどのように機能しますか？

ti cc3000 wifiチップには特別なスマート設定モードがあります。これは、wifiアクセスの詳細の初期設定を可能にするためです。

cc3000のwikiページには、プロセスの仕組みに関する詳細が記載されています。

1. チップはスマート構成の「リッスン」モードに入ります
2. スマートフォンのアプリケーションは、アクセスポイント設定を含む「UDP」パケットを送信します
3. チップはこのデータをキャプチャし、それ自体を構成します

パケットキャプチャとWi-Fiスニッフィングは知っていますが、チップはどのようにして生のパケットを「解読」して情報を取得しますか。ルータでAESでwpa2-personalを使用しています。

@Colinが言及しているように、TIが現在ネットワークSSIDとキーフレーズをセットアップアプリケーションからCC3000対応デバイスに通信するために使用するスキームは、Smart Configと呼ばれます。

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

それから私は、それほど技術的ではなく、Smart Configで常にAESキーを使用する必要がある理由についての意見の記事を投稿します。

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

中央には、CC3000が期待するように動作するために必要なAES変換を使用してJavaで暗号を構成する方法を簡潔に説明する技術的な部分があります。

最後に、プリンの証明-CC3000のSmart Config関連の動作をエミュレートするアプリケーションを作成しました。つまり、関連するネットワークトラフィックを復号化する必要なく、Smart Configアプリケーションによって送信されたSSIDとキーフレーズを回復できます。ソースのダウンロード先とすべての詳細については、こちらをご覧ください。

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

いくつかの背景情報については、CC3000に関連するTIフォーラムでこれらのスレッドを読むことも興味深い場合があります。

Smart Config自体をカバーする最初のもの：

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

また、mDNSの1つは、CC3000対応デバイスがネットワークに参加したことをSmart Configアプリケーションが検出するメカニズムです。

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

両方のスレッドで、いくつかの初期メッセージはそれほど関連していないように見えるかもしれませんが、いくつかの興味深い情報が混在しています。しかし、不正確な情報もたくさんあるので、TIの従業員や私からの情報でさえ、すべてが正しいと仮定しないでください（私は最終的に多くを学びましたが、いくつかの誤った仮定/信念から始めました）。

特許は数回言及されていますが、この技術に関して特許が申請中または許可されているという証拠は見つかりません。

NBこの回答へのコメントおよび他の回答で述べたように、以下の回答は現在の手順を反映していません。歴史的な記録のためにこれを残します。

CC3000が実際にAPプローブ要求のすべてのwifiチャネルで（「プロミスキャスモード」で）リッスンしているようです。プローブされた（および偽の）APのSSIDには、インターネットへの接続に使用するAP。

少し検索した後、私はそれを明確にする必要があるデバイスの最初の設定のこの説明を見つけました：

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

最も興味深いビット：

初回設定の実行に使用される携帯電話やタブレットなどのデバイスは、特別に細工されたSSIDでAPに接続するように設定する必要があります。このSSIDには、CC3000が接続するSSIDの名前と、セキュリティタイプやキーなどのセキュリティオプションに関する情報が含まれています。

詳細については、このページをご覧ください。

APはこのプロセスに関与していません。CC3000は、携帯電話または他のデバイスからのUDPパケットをリッスンしています。この通信はAESで暗号化されており、両方のデバイスがそれを持っています。携帯電話は、これらのパケットでルーターWPA2キーに関する情報を送信します。CC3000は、携帯電話で使用されるAESキーを認識し、データをデコードしてthrルーターに接続します。

@Greg Sadetskyの答え（「初回構成」と記述）は、基本的なプロセスをうまく要約しています。しかし、TIフォーラムでの議論で、CC3000がこの自動構成を実行するプロセスを変更したことが明らかになりました。新しいプロセスはFirst Time Configurationではなく「smartconfig」と呼ばれ、TIは明らかにこの技術の特許申請を準備しています。CC3000のネットワーク資格情報を巧妙にエンコードする、特別なWi-Fi「プローブ」リクエストが送信される同様のスキームを使用しているようです。

自動設定にAES暗号化キーを使用しないことを選択した場合、smartconfigアルゴリズムは文書化されていない方法を使用して、アクセスポイントのSSIDとセキュリティキーを難読化します。誰かが難読化アルゴリズムをリバースエンジニアリングまたはその他の手段で学習すると、ワイヤレスネットワークのセキュリティが危険にさらされるため、これは本質的に安全ではありません。特許出願が提出されると、それはパブリックドメインの知識であり、安全にするためにCC3000自動構成モードでAES暗号化キーを使用する必要があります。

2013年9月の時点で、Texas Instrumentsによる2012年から2013年の特許出願のレビューに基づいて、特許出願は行われていません（Google Patent Search Link：Texas Instruments、最新の出願日でソート）。

TIは、非AES構成モードの不安定さを認識しており、AESの使用を推奨し、将来的にはデフォルトにすることを表明しています。