5.4 LE SECURITY

Bluetoothコア仕様v4.0（LEレガシーペアリング）で導入されたペアリングメカニズムは、セキュアシンプルペアリングなどのBR/EDRセキュリティ機能に関するセキュリティといくつかの違いがあります。 アソシエーションモデルは、ユーザーの観点からBR/EDRセキュアシンプルペアリングに似ていて、同じ名前を持っていますが、提供される保護の質に違いがあります。

5.4.1 Association Models

Bluetooth LEは、Just Works、Numeric Comparison、Out of Band、Passkey Entryという4つのアソシエーションモデルを使用しています。 LEのレガシーペアリングにはNumeric Comparisonがありません。

LEレガシーペアリングでは、これらの関連モデルのそれぞれは、以下の点を除いてBR/EDRセキュアシンプルペアリングに似ています。

• Just WorksとPasskey Entryは、パッシブな盗聴保護を提供しません。 これは、セキュアシンプルペアリングがElliptic Curve Diffie-Hellmanを使用し、LEのレガシーペアリングが使用しないためです。

LEセキュアコネクションのペアリングでは、4つのアソシエーションモデルは機能的にBR/EDRセキュアコネクションと同等です。

各アソシエーションモデルの使用は、デバイスのI/O機能に基づいています。

5.4.2 Key Generation

Bluetooth LEの鍵生成は、他のLEデバイスとは独立した各LEデバイスのホストによって実行されます。 ホストで鍵生成を実行することにより、鍵生成アルゴリズムをコントローラ変更することなくアップグレードすることができます。 注：BR/EDRのキー生成は、コントローラで実行されます。

Bluetooth LEは、それぞれ特定の目的のために、以下のように複数のキーを使用します。:

• データとデバイス認証の機密性
• 暗号化されていないデータの認証
• デバイスアイデンティティ

LEでは、秘密性と認証を提供するために使用される鍵は、ペアリング中に各デバイスからの貢献を組み合わせることによって生成されます。

5.4.3 Encryption

Bluetooth LEの暗号化は、AES-CCM暗号を使用します。 BR/EDRと同様に、LE暗号化はコントローラで実行されます。

5.4.4 Signed Data

Bluetooth LEは、信頼関係を持つ2つのデバイス間で暗号化されていないATTベアラを介して認証データを送信する機能をサポートしています。 これは、CSRK（Connection Signature Resolving Key）でデータに署名することによって達成されます。 送信側デバイスは、データPDUの後ろに署名を置きます。 受信デバイスは署名を検証し、署名が検証されている場合、データPDUは信頼できるソースから来たものとみなされます。 署名は、署名アルゴリズムによって生成されたメッセージ認証コードとカウンタで構成されます。 このカウンタは、リプレイ攻撃から保護するために使用され、送信された署名付データPDUごとに増分されます。

5.4.5 Privacy Feature

Bluetooth LEは、頻繁にBluetoothデバイスアドレスを変更することにより、LEデバイスを一定期間追跡する機能を削減する機能をサポートしています。

プライバシー機能を使用するデバイスが既知のデバイスに再接続するためには、プライベートアドレスと呼ばれるデバイスアドレスを他のデバイスで解決できる必要があります。 プライベートアドレスは、ボンディング手順中に交換されるデバイスの解決IDキー（IRK）を使用して生成されます。

プライバシー機能には2つのバリエーションがあります。 第1のバリエーションでは、プライベートアドレスが解決され、ホストによって生成される。 第2のバリエーションでは、ホストがコントローラデバイス識別情報を提供した後にホストを関与させることなく、プライベートアドレスが解決され、コントローラによって生成される。 さらに、コントローラの解決リストがボンディングされたデバイスに必要なすべてのデバイスID解決鍵を格納できない場合、第2のバリエーションはホストを含むことができます。

プライバシーのモードには、デバイスプライバシーモードとネットワークプライバシーモードの2つがあります。 デバイスプライバシーモードのデバイスは、デバイスのプライバシーのみに関心があり、ピアデバイスがそのIRKを過去に配信したとしても、自分の識別アドレスを含むピアデバイスからの広告パケット、およびプライベートアドレスを含む広告パケットを受け入れます 。 ネットワークプライバシーモードでは、デバイスはプライベートアドレスを含むピアデバイスからの広告パケットのみを受け入れます。 既定では、プライベートアドレスが解決されてコントローラによって生成されるとき、ネットワークプライバシモードが使用されます。

ホストは、デバイスアイデンティティを追加および削除することによって解決リストを維持します。 ホストは、完全な解決リストまたは解決リストのサブセットをコントローラに提供することができます。 デバイスIDは、ピアのIDアドレスとローカルおよびピアのIRKペアで構成されます。

コントローラがアドレス解決を実行し、ホストが解決リストに含まれるピアデバイスを参照する必要がある場合、ホストはピアのデバイスIDアドレスを使用します。 同様に、コントローラーからホストへのすべての着信イベントは、ピアの装置アドレスが解決されていれば、ピアの装置識別情報を使用します。 コントローラが広告内のピアのデバイス識別アドレスを解決できない場合、コントローラはホストで解決のためにイベントをホストに渡すことがあります。

コントローラーでアドレス解決が実行されると、ホワイトリストに含まれているかどうかをチェックする前にピアのデバイスIDアドレスを解決できるため、デバイスのフィルタリングが可能になります。

Figure 5.4に、コントローラ解決リストとコントローラホワイトリストの関係を論理的に示します。 解決リストとホワイトリストの実際の実装は、このモデルに従う必要はありません。 解決リストはホワイトリストから独立していてもよい。

Figure 5.4: Logical Representation of the Resolving List and Device White List

注：ホワイトリストのすべてのデバイスがデバイスIDアドレスであるとは限りません。

ホストでアドレス解決が排他的に実行されると、デバイスフィルタリングを無効にする必要があるため、デバイスの消費電力が増加する可能性があります。