Matthew Bon作成、最終校正2016年10月25日
はじめに
Bluetooth Low Energy（BLE）は、現在最も一般的な無線規格の1つとして急速に普及が進んでいます。同様に、機密情報をやり取りするアプリケーションで使用されることも多くなってきています。したがって、BLEを製品に組み込もうとする設計者は、この技術のセキュリティ機能と限界に注意する必要があります。この記事では、これらの機能の基本的な概要を説明するとともに、その背後にある理論的な考察をご紹介します。
この記事では、BLEのGAP（Generic Access Profile）CentralとGAP Peripheralの役割に焦点を当てます。GAP ObserverとGAP Broadcasterの役割は、通常、セキュリティ要件がほとんどないアプリケーションで使用されるため、本記事では考慮しません。
BLE規格に詳しくない読者のために説明すると、GAPはBLEスタックのレイヤで、BLEシステムのネットワークトポロジを決定するものです。GAP Centralは、通常、GAP Peripheralとの接続を開始するデバイスです。2つのデバイスが接続されると、暗号化された接続を確立するために必要な情報を交換する「ペアリング」プロセスが実行されます。また、デバイス同士が再接続するたびにペアリングプロセスを繰り返す必要がないように、ペアリングプロセスからの鍵情報をデバイスに保存するボンディング処理を実行することもできます。
最後に、本記事では、BLEデバイスがどのバージョンのBluetooth仕様に準拠しているかを明示するために、4.0、4.1または4.2デバイスと呼びます。この用語は、Bluetooth Classic仕様に準拠したBluetooth ClassicデバイスをBluetooth 4.x準拠デバイスと呼ぶこともできるため、やや不正確な表現となります。ただし、本記事ではBLEデバイスのみを対象としているため、各仕様のBLE部分に準拠したデバイスのみを指す用語と解釈できます。
BLEが直面するセキュリティ問題
ペアリング処理とBLE全般の主なセキュリティ上の問題は、受動的盗聴、中間者（MITM）攻撃、およびID追跡です。
受動的盗聴とは、ペアリングされた2つのデバイス間でやり取りされるデータを、第3のデバイスが盗み聞きすることです。BLEはこれを防止するために、転送するデータをAES-CCM暗号で暗号化します。AES暗号は非常に安全と考えられていますが、BLEが使用する鍵交換プロトコルは、攻撃者がデータを解読することを可能にする深刻なセキュリティの脆弱性をもたらす可能性があります。このように、「ペアリング方式」または「アソシエーションモデル」と呼ばれる鍵の交換方式は、接続のセキュリティに大きな影響を与えます。
MITM（中間者）攻撃とは悪意のある第3のデバイスが、他の正規の2つのデバイスになりすまし、だましてこれらのデバイスに接続することです。このシナリオでは、GAP CentralとGAP Peripheralの両方が悪意のあるデバイスに接続し、その結果、他の2つのデバイス間の通信をルーティングすることになります。これにより、正規のデバイス同士は直接接続されているように錯覚しますが、実際には接続が侵害されているのです。この設定により、悪意のあるデバイスは送信されるすべてのデータを傍受できるだけでなく、受信すべき人に到達する前に偽のデータを挿入したり、データを削除したりすることが可能になります。MITM攻撃についてのより詳しい説明はWikipedia： Man-in-the-middle attack - Wikipedia （中間者攻撃 - ウィキペディア）にあります。受動的盗聴と同様に、ペアリングの方法によって、MITM攻撃に対するBLE接続の耐性が決まります。
ID追跡とは、悪意のある実体がBLEデバイスのアドレスを特定のユーザーに関連付け、BLEデバイスの存在に基づいてそのユーザーを物理的に追跡できることです。BLEがこれに打ち勝つ方法は、デバイスのアドレスを定期的に変更することです。このプロセスの詳細な説明は、この記事のアドレッシングのセクションにあります。
ペアリングの概要
ペアリングとは、2つのBLEデバイスがデバイス情報を交換し、安全なリンクを確立するためのプロセスです。BLE 4.2デバイスと旧来の4.1および4.0デバイスでは、プロセスが多少異なります。プロセスの詳細は、以下のセクションで説明します。
4.0および4.1デバイス
4.0および4.1デバイスのペアリング処理は、LE Legacy Pairingとも呼ばれ、BLE規格に固有のカスタムキー交換プロトコルを使用します。この設定では、デバイスは一時キー（TK）を交換し、それを使用して接続を暗号化するための短期キー（STK）を作成します。このプロセスの安全性は、TKの交換に使用するペアリング方式に大きく依存するため、各ペアリング方式については後ほど詳しく説明します。ペアリング処理は、以下のような一連のフェーズで実行されます。
フェーズ1： このフェーズは、開始デバイスが相手デバイスに「Pairing_Request」を送信したときに開始されます。その後、2つのデバイスは、I/O機能、認証要件、最大リンクキーサイズ、ボンディング要件を交換します。基本的にこのフェーズでは、2つのデバイスがそれぞれの機能を交換し、安全な接続を確立するための方法を決定します。また、この段階でやり取りされるデータはすべて暗号化されていないことが重要なポイントです。
フェーズ2： フェーズ1が完了すると、デバイスはペアリング方法の1つを使用してTKを生成・交換します。そこで、2つのデバイスはConfirmとRandの値を交換し、両者が同じTKを使用していることを確認します。これが決まると、TKとRand値を使用してSTKを作成します。次に、STKは接続を暗号化するために使用されます。
フェーズ3： このフェーズは、フェーズ1でボンディング要件が交換された場合にのみ使用されるオプションのフェーズです。このフェーズでは、いくつかのトランスポート固有の鍵が交換されます。これらの鍵の完全なリストとその機能は、この記事の付録で見ることができます。
4.2デバイス
BLE 4.2デバイスは、BLE 4.0および4.1デバイスと完全な後方互換性があります。つまり、4.2デバイスは、4.0および4.1デバイスとまったく同じペアリングプロセスを実行できます。ただし、BLE 4.2 は、LEセキュア接続として知られているものを作成することができます。LEセキュア接続では、TKとSTKを使用する代わりに、1つの長期鍵（LTK）を使用して接続を暗号化します。このLTKはECDH（楕円曲線Diffie-Hellman）公開鍵暗号方式で交換・生成され、オリジナルのBLE鍵交換プロトコルに比べて格段に高い安全性を実現しています。
LEセキュア接続では、ペアリング処理のフェーズ1 とフェーズ3 の両方が、LE レガシー接続の場合と全く同じです。したがって、唯一の相違点は、ペアリング処理のフェーズ2 で発生します。
LEセキュア接続におけるフェーズ2の動作は、次のとおりです。両デバイスは、ECDH公開鍵-秘密鍵のペアを生成します。その後、2つのデバイスは公開鍵を交換し、Diffie-Hellman鍵の計算を開始します。それから、ペアリング方法の1つが接続の認証に使用されます。接続が認証されると、LTKが生成され、接続が暗号化されます。
LEレガシー接続のペアリング方法（4.0、4.1、4.2デバイス）
Just WorksTM
この方法では、TKは0に設定されます。したがって、攻撃者がSTKを総当たり攻撃し、接続を傍受することは非常に簡単です。同様に、この方法では接続に参加しているデバイスを確認する方法がないため、MITM保護は提供されません。
アウトオブバンド（OOB）ペアリング
この方式では、NFCなどの別の無線技術を使用してTKを交換します。この方法の主な利点は、最大128ビットという非常に大きなTKを使用できることで、接続の安全性を大幅に高めることができます。OOBチャネルがMITM攻撃から保護されている場合、BLE接続も MITM攻撃から保護されていると想定できます。同様に、ペアリング プロセス中に OOBチャネルが盗聴の影響を受けない限り、BLE接続も受動的な盗聴の影響を受けません。従来の3つのペアリング方式（Just WorksTM、パスキー、OOB）のうち、OOBチャンネルが十分なセキュリティ方式を採用していれば、OOBペアリングは圧倒的に安全です。
パスキー（Passkey）
この方法では、TKはユーザーによってデバイス間で渡される6桁の数字です。この番号の転送方法はさまざまです。例えば、片方のデバイスがランダムに6桁の数字を生成し、LCDディスプレイに表示させることができます。ユーザーはその数字を読み取り、キーパッドを使ってもう一方の機器に入力します。
攻撃者がペアリング処理中に盗聴していない場合、パスキー方式は受動的な盗聴からかなりのレベルで保護されます。しかし、攻撃者がペアリング中に存在し、交換される値を盗聴できる場合、TKを力ずくでSTKを導き出し、接続を復号化するのはかなり簡単です。パスキー方式は一般に、攻撃者がBLE接続以外の何らかの手段でパスキーを入手できない場合、MITM攻撃から安全であると考えられています。しかし、ホワイトペーパーに詳述されているように、パスキーの高度な知識がなくても成功できる理論的なMITM攻撃が少なくとも1つ存在します。Tomas RosaによるBypassing Passkey Authentication in Bluetooth Low Energyに詳述されています。このため、最高レベルのセキュリティを必要とするBLEアプリケーションでは、OOBまたは数値比較（Numeric Comparison）のいずれかのペアリング方式を使用する必要があります。
LEセキュア接続のペアリング方法（4.2デバイスのみ）
Just WorksTM
両デバイスが公開鍵を交換すると、非開始デバイスはノンス（nonce、基本的にランダムなシード値）を生成し、それを使って確認値Cbを生成します。次に、非開始デバイスはCbをノンスとともに開始デバイスに送信します。同時に、開始デバイスは自身のノンスを生成し、非開始デバイスに送信します。次に、開始デバイスは非開始デバイスのノンスを使用して、Cbと一致する独自の確認値Caを生成します。確認値が一致すると、接続が続行されます。
ECDH鍵交換により、LEセキュア接続のJust WorksTMペアリング方式は、LEレガシー接続の同方式と比較して、受動的盗聴への耐性が大幅に向上しています。ただし、この方法では、ユーザーが接続の真偽を確認する方法がないため、MITM攻撃に対してやはり脆弱であることに変わりはありません。
アウトオブバンド（OOB）ペアリング
OOBペアリングでは、公開鍵、ノンス、確認値はすべてNFCのような別の無線技術で交換されます。LEレガシー接続と同様に、OOBペアリングは、OOBチャネルが安全である場合にのみ、受動的盗聴とMITM攻撃からの保護を提供します。
パスキー（Passkey）
この方式では、同じ6桁の数字をそれぞれのデバイスに入力します。2つのデバイスは、このパスキーと、先に交換した公開鍵、および128ビットのノンスを使用して接続を認証します。このプロセスは、パスキーの各ビットごとに行われます。次に、もう一方のデバイスは、パスキーの最初のビットの確認値を計算し、それを最初のデバイスに公開します。このプロセスは、パスキーのすべてのビットが交換され、一致することが確認されるまで続けられます。
上記で詳述したプロセスにより、LEセキュアコネクションのパスキー方式は、LEレガシーコネクションの場合よりもMITM攻撃への耐性がはるかに高いものとなっています。
数値比較（Numeric Comparison）
このペアリング方法は、Just WorksTMのペアリング方法と全く同じ手順ですが、最後にもう1ステップ追加します。デバイスが確認値の一致を確認すると、両デバイスはそれぞれ独立に、両方のノンスを使用して最終的な6桁の確認値を生成します。その後、両デバイスは計算した値をユーザーに表示します。 その後、ユーザーは両方の値が一致することを手動で確認し、接続を承認します。この追加ステップにより、このペアリング方式はMITM攻撃からの保護を提供することができます。
BLEペアリング方式に関する実用的な考察
BLEを安全なアプリケーションで使用するための大きなハードルは、最も安全なペアリング方式が他の領域で大きなデメリットを持つことでした。OOBペアリングでは、デバイスに回路を追加する必要があり、デバイスのコストが上昇します。また、設計者はOOBチャネルの安全性を保証する必要があり、それ自体が設計上の大きな課題となり得ます。数値比較の場合、各機器にディスプレイが必要なため、機器のコストが上がるだけでなく、ユーザーが手動でコードの一致を確認する必要があり、ユーザーの使い勝手が損なわれてしまいます。したがって、ほとんどの機器がパスキー方式またはJust WorksTMを採用していると考えるのが妥当であり、ほとんどの機器がある程度の脆弱性を持っていることになります。医療機器など高いセキュリティが要求される製品の設計者は、OOBペアリングや数値比較の実装ができない場合、他の無線プロトコルを検討する必要があります。
アドレッシング（Addressing）
各BLEデバイスは、デバイスアドレスを使用して識別されます。これらのアドレスは、他の通信プロトコルで使用されるMACアドレスに似ていますが、通常、BLEデバイスのアドレスは自由に変更できます。この類似性により、BLE MACアドレスと呼ばれるBLEデバイスアドレスがよく見られます。
BLEは現在、4種類のアドレスに対応しており、いずれも48ビット長です。
- 公開IEEE形式：IEEE登録機関を通じて購入した、これらのアドレスはメーカー固有です。このアドレスの最上位 24ビットは、企業IDとも呼ばれる組織固有識別子（OUI）であり、IEEEによって割り当てられます。最下位24ビットは、会社が自由に変更できます。これらのアドレスは変更されることがないため、ID追跡から保護されません。
- ランダムスタティック（Random Static）：これらのアドレスは、製造時にデバイスのシリコンに書き込まれるか、デバイスがパワーサイクルするときに生成されます。デバイスがパワーサイクルごとに新しいアドレスを生成し、ユーザーが定期的にデバイスをパワーサイクルする場合、このアドレスタイプはID追跡からある程度保護されます。それ以外の場合、このアドレスタイプが提供する保護は限定的です。
- ランダムプライベートリゾルバブル（Random Private Resolvable）：このアドレッシング方法は、ボンディングプロセス中に2つのデバイス間でIRK（Identity Resolving Key）が交換される場合にのみ使用できます。この方法では、デバイスはIRKを使用して、そのデバイスアドレスを、アドバタイズパケットに表示されるランダムアドレスに変換します。 IRKを保有する第2のデバイスは、ランダムアドレスを実アドレスに変換して、第1のデバイスを識別することができます。この方法では、デバイスは定期的にIRKに基づいて新しいランダムアドレスを生成するため、ID追跡に対する大きな保護となります。
- ランダムプライベートノンリゾルバブル（Random Private Non-Resolvable）：このアドレッシング方法では、デバイスアドレスは単なる乱数であり、新しいデバイスアドレスはいつでも生成できます。新しいアドレスがかなり頻繁に生成されるのであれば、この方法はID追跡に対して大きな保護を提供します。
結論
BLEは、デバイス間の通信を保護するための機能をいくつか備えており、それぞれに利点と制約があります。設計者は、BLEを設計に導入する際に、BLEが直面する特定のセキュリティ脅威と、BLEのセキュリティ機能がどのようにその緩和に役立っているかを理解することが重要です。
参考文献
Bluetooth Core Specification , ver. 4.1, Bluetooth SIG, December 2013
Bluetooth Core Specification , ver. 4.2, Bluetooth SIG, December 2014
Gibbs, J. (2014, August 13). Increasing Wireless Security in Bluetooth Low Energy . Retrieved August 01, 2016, from http://eecatalog.com/IoT/2014/08/13/increasing-wireless-security-with-bluetooth-low-energy/
Rosa, T. (2013, May 23). Bypassing Passkey Authentication in Bluetooth Low Energy . Retrieved August 01, 2016, from https://eprint.iacr.org/2013/309.pdf
Ryan, M. (2013). Bluetooth: With Low Energy Comes Low Security . Retrieved August 01, 2016, from Bluetooth: With Low Energy Comes Low Security | USENIX
付録1 フェーズ3キーとバリュー
長期キー（LTK）：2つのデバイスがボンディングされている場合、ペアリングプロセスを繰り返す必要がないように、このキーを使用して将来のリンクを暗号化します。
EDIVおよびRAND：LTKの作成および識別に使用される値。
Connection Signature Resolving Key（CSRK）：送信データへの署名と受信データへの署名の検証を行う。
公開IEEEアドレス：上記の「アドレッシング」の項を参照。
ランダムスタティックアドレス：上記の「アドレッシング」の項を参照。
Identity Resolving Key（IRK）：Private Resolvable Addressを解決するために使用される。
付録 2 BLEセキュリティに関する関連リンク
BLE Core Specification Download Page
Bluetooth Sig’s LE Security Page
付録3 ペアリング方式とI/O機能の関係
本記事のペアリング方法の項で述べたように、通常ペアリング方式では、デバイスに何らかのI/O機能を持たせる必要があります。Bluetoothの仕様では、これらの要件を以下の表にまとめています。BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part H] 2.3.5 Pairing Algorithms
