Bluetooth LowEnergyの暗号化とデータの安全性
スマートフォン（iOSおよびAndroid）と組み込みデバイス（CC2540チップ）間のBluetooth Low Energy（BLE）データ接続を介して機密データを送信する必要があります。
電話のアプリコードがハッキングから安全であるとは考えていないため、暗号化されたパッケージをサーバーからデバイスに1回だけ配信するには、BLEの安全性に依存する必要があります（2回目の試行は想定する必要があります）パッケージを配信するには、攻撃者からのものである必要があります）。
私は数日ネットを閲覧して、自分のデータが安全かどうか、そしてどのような条件下であるかを調べています。残念ながら、私は自分の質問に対する簡単な答えを思い付くことができませんでした。
電話をデバイスにペアリングした場合、データは安全ですか？ -ペアリングプロセス自体に欠陥があることは理解していますが、理論的には、一部の中間者（MITM）がペアリングプロセス中に暗号化キーを盗聴し、接続を危険にさらす可能性があると思います。
各デバイスを複数の電話とペアリングする必要があります（ただし、一度に1つだけと通信します）。ペアリングの最大数はいくつですか。端末？ -残念ながら、かなりの数の電話をデバイスにペアリングする必要があります。
この制限を増やすために、デバイスからペアリングデータ（長期キーなど）を取得して外部メモリに保存することはできますか？.
ペアリングせずに、または必要に応じて再ペアリングすることで、デバイスに安全なデータ接続を確立できますか？ -MITM攻撃に関して、この手順はどの程度安全ですか？
これらの質問に明確に答える文書を見つけることができないようです。どんなアイデアやポインタでも大歓迎です。
これが私の2セントです：
AFAIK、BLEのペアリング/暗号化プロセスに欠陥はありません。ただし、暗号化で利用できるMITM保護には次の3つのレベルがあります。
- なし、これは既知のキー== 0を使用するため、盗聴者がペアリングプロセスですべてのパケットをキャッチした場合、盗聴者は暗号化された接続を追跡できます。
- 低MITM保護。これは、ペアリングにユーザー入力パスキーを使用する場合で、キーは1.000.000未満です。ここでは、盗聴者は100万個のキーを試すだけで済みます。
- 帯域外キーを使用した高度なMITM保護。これにより、暗号化に128ビットの完全な強度が与えられ、盗聴者は、ペアリングプロセス全体をキャッチした場合でも、会話を追跡するためのキーを知る必要があります。 BLEには（少なくとも）鍵交換方法がないため、ここでの最も弱い点は鍵の配布ですが、これは、アプリケーションレベルで暗号化の追加レイヤーを使用する場合と同じ問題になります。
これは実装に依存します。デバイスを結合する必要はありません。つまり、ホストとの永続的な関係を確立する必要はありません。デバイスが結合しない場合、以前の接続について通知する状態はありません（交換されたデータを除きますが、それはアプリケーションドメインであり、BLEスタックではありません）。デバイスが結合されていない場合、保護されたデータを交換するために次に接続するときに、デバイスを再度ペアリングする必要があります。デバイスが結合されている場合、暗号化された接続は、以前と同じセキュリティレベルで、アプリ/ユーザーの操作なしで続行できます。ワンタイム接続デバイスの場合、ボンディングは意味がないため、接続するデバイスの数に制限がなく、ステートレスな実装を行うことができます。複数回接続の場合、BLEに依存しないキーを配布/保存する方法に応じて、ステートレス実装を使用することもできます。ここでのさまざまなオプションの可用性は、使用しているデバイス/ BLEスタックの実装によって異なりますが、仕様ではこれをすべて許可しています。
結合して長期キーなどを交換する場合、構築しているBLE実装に応じて、これらを好きなように保存できます。
2.で述べたように、ボンディングせずに安全な（暗号化された）接続を確立できます。次に、デバイスは、次に安全な接続を確立するときに、再度ペアリングする必要があります。何らかの理由でペアリングしたくない/ペアリングできない場合は、プレーンテキスト通信しかできません。
これを刺します。
1）ペアリングプロセスについての私の理解は同じです。データの機密性が十分に高い場合は、アプリケーションに独自の暗号化の独立したレイヤーを追加します...
2）接続の場合、接続が結合/ペアリングされていない場合でも、BLEプロトコルはデバイスごとに同時に1つのホストに制限されます。単一のデバイスが同時に複数のホストへの接続を確立する唯一の方法は、デバイスが何らかの形で複数のデバイスのふりをする場合です。これを実行できるかどうかはハードウェアに依存し、デバイスを使用する標準的な方法の1つではありません。ハードウェアをだましてそれを実行できたとしても、接続間隔が（ほぼ）重複するなどの避けられない問題が発生し、データが失われ、最終的には接続が確立される可能性があります。
デバイスが複数のホストと通信する別の方法は、定期的に切断し、別のホストに接続を確立させることです。 AFAIK、この手法には特別なプロトコルサポートがないため、ダイレクトアドバタイズを使用する以外に、次に接続するホストと接続するタイミングをあまり制御できない場合があります。
「Core_V4.0」Bluetooth仕様のボリューム1、パートAのセクション4.1.2も参照してください（例：ここから https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737 ）
3）おそらくそうです、詳細はベンダーによって異なりますが、上記の制限があります。
4）ボンディング/ペアリングなしで接続を確立できます。その接続は通信を許可しますが、セキュリティのないプレーンテキストになります。 AFAICS、これを正しく行う唯一の方法は、アプリケーションレベルで独自のデータ保護を使用することです。
CC2450デバイスはTIスタックを使用していると思います。 CC2540スタックの動作に関する優れたドキュメントは、 CC2540開発キットユーザーガイド にあります。 bluetooth.org の4.0仕様の後のおそらく最高のドキュメントです
ペアリングプロセスで使用される6桁のピンはMITMに対抗します-PINエントリには30秒のウィンドウがあります。
TIスタックは、ペアリングされたデバイスの数を8程度に制限します。これは、接続を再確立するために必要なCPUと暗号化のパフォーマンス/リソースが原因です。
暗号化キーをBTデバイスから移動することは、セキュリティに対するリスクです。全体として、キー管理はすべての暗号化のアキレス腱です。
ボンディングなしでは、暗号化された特性の読み取り/書き込みはできません。 TIユーザーガイドの4.6.1を参照してください。これは、Bluetooth4.0の仕様に準拠しています。