web-dev-qa-db-ja.com

AndroidアプリとBLEデバイス間でBluetoothLow Energyセキュリティはどのように機能しますか?

私はBluetoothLow Energy(BLE)プロトコル(v4.2)、特にそのセキュリティ機能を研究しています。モバイルアプリとBLEデバイス間で送信されるデータの暗号化がどのように機能するかを理解しようとしています。

公式ドキュメント(v4.2)には、データの暗号化、デバイスの認証、暗号化およびペアリングフェーズで使用されるキーの生成などの方法が指定されています。

最初の疑問(いくつかの概念を確実に理解したい):これらの機能はすべてホストレベルで実装されているため、アプリ(Android)とBLEデバイス(フィットネストラッカーなど)の間で送信されるデータを暗号化する場合は、これらのメソッドをBLEデバイスに実装(または有効化)する必要がありますか?このように、開発者はBLEデバイスでのこれらの機能の実装のみを気にする必要があります。Android Bluetoothスタックはこれらの機能をサポートしているだけだからです。私は正しいですか?間違っている場合はどうしますか?これらの機能を(モバイルアプリとBLEデバイスの両方で)実装する正しい方法はありますか?

2番目の疑問:一部のBLEデバイスが、SIGが提供するセキュリティ機能を使用する代わりに、GATTプロトコルの上に独自の暗号化を実装するのはなぜですか?

3番目で最後の疑問:SIGによって指定されたセキュリティ機能は必須ですか、それともオプションですか?

ご覧のとおり、私にはいくつかの疑問があり、いくつかの質問はばかげている可能性があるので、誰かがアプリとBLEデバイスの間にセキュリティメカニズム(暗号化など)を実装する方法と、これらの機能が実装されているレベルを明確にできれば( OSまたはアプリケーションレベル)、私は大いに感謝します。

10
d3llafr33

標準のBLE暗号化を使用する場合、暗号化/復号化/認証タグの検証を行うのは、実際にはコントローラーのリンク層です。ただし、2つのデバイスのペアリング、結合、およびキー交換の方法を定義するのはホスト層(SMP)です。交換されたキーを使用して暗号化を開始するようにリンク層に指示するのもその層です。 AndroidおよびiOSでは、ペアリングとボンディングを管理し、SMPを実装するのはOSです。Bluetoothペアリング/ボンディング/暗号化を使用するかどうかは完全にデバイス次第であり、オプションです。サポートされていない場合でも、エラーコード「PairingNotSupported」の送信をサポートする必要があります

Bluetooth標準には「ユースケース」が1つだけあります。この使用例は、2つのデバイス間のリンクを保護する方法を提供することで、ボンディング後、誰もデバイスを偽装したり、トラフィックを操作または復号化したりできないようにします。ご存知かもしれませんが、Bluetooth v4.1までに指定された唯一のペアリング方法である「LEレガシーペアリング」には、攻撃者がペアリング中にトラフィックを盗聴した場合に安全でなくなるいくつかの欠陥があります(「正常に機能する」と「MITMの両方」/passkey entry」ですが、OOBではありません)。ただし、Bluetoothv4.2で定義された新しい「LESecureConnections」は、DiffieHellmanを使用してより安全にします。

Bluetoothペアリング自体がセキュリティを提供しますが、Android APIとiOSAPIの両方にいくつかの欠陥があり、優れたセキュリティが必要な場合はアプリ開発者にとってまだ十分ではない可能性があります。特に、iOSは特定のデバイスが実際に結合されているかどうか、またはリンクが暗号化されているかどうかを検出するためのAPIは一切提供されません。ただし、ペアリングの開始時にユーザーにポップアップが表示されますが、アプリはそのペアリングについて何も認識しません。したがって、iOSアプリの観点から、あなたは知らない知らない:

  1. デバイスとペアリングした場合。
  2. あなたが本物の装置または中国のコピーと話すならば。
  3. セキュリティレベル。つまり、ペアリングでJust Works、MITMレガシーペアリング、またはLE SecureConnectionsを使用した場合。
  4. 現在のリンクが暗号化されている場合。

Androidは少し優れています。そこでアプリは、少なくともデバイスが結合されているかどうかを知ることができます(他の3つは知ることができません)。ボンディングプロセスを開始するためのAPI「createBond」もあります。ここでは、GATT操作を実行するときに暗号化されたリンクを適用できるため、WindowsAPIの方がはるかに優れています。

開発者が代わりにGATTの上にセキュリティを最初から実装するには、これらの理由のいずれかで十分な場合があります。特に、よくあるユースケースの1つは、開発者がPINまたはパスワードを使用して「ペリフェラルにログイン」する」ユースケースを望んでいることです。Bluetooth標準はそのユースケースをサポートしていません(いいえ、「MITMで保護されたペアリングとstaticパスキー」の使用は機能しません。これは、そのプロトコルが設計上、1回または数回の試行後にパスキーを明らかにするためです)。

とにかく、独自のハードウェアを使用して独自の周辺機器を開発し、Bluetooth規格のペアリング/ボンディング/暗号化を使用したい場合、BLEチップのメーカーによるSDKは通常すでにこれを実装しています。ただし、それを機能させるには、正しく設定する必要があります。通常、いくつかのパラメーターを構成するだけでよく(ディスプレイがある場合やユーザーがパスキーを入力できる場合など)、残りはSDKによって内部的に自動的に処理されます。

更新:

Androidのソースコードは https://Android.googlesource.com/platform/system/bt/https:// Android .googlesource.com/platform/packages/apps/Bluetooth / および https://Android.googlesource.com/platform/frameworks/base/+/master/core/Java/Android/bluetooth =。

13
Emil