BluetoothのHostとControllerの話｜セキュリティごった煮ブログ

はじめまして。ねこやなぎです。今回は身近な通信技術「Bluetooth」の話です。

Bluetoothには、使用目的に応じた多数のプロファイルが用意されています。主なプロファイルはIoT機器で使用されるGATT(Generic attribute profile) 、マウスやキーボードを接続するときに使用されるHID (Human Interface Device Profile)、ワイヤレスで音楽を聞くときに使用されるA2DP（Advanced Audio Distribution Profile）、ハンズフリー通話をするときに使用されるHFP（Hands-Free Profile）などです。特に、ワイヤレスイヤホンを使用している人にとってはA2DP/HFPはとても身近な存在だと思います。

2020年1月に行われた世界最大のエレクトロニクスショーCES 2020では、Bluetoothの新たな音声伝送規格「LE Audio」をまもなくリリースすると発表されました。LE Audioは、SBCに代わる高音質コーデックLC3への対応、音声のマルチストリーム伝送、ブロードキャストの対応など様々な改良が行われています。

ところで、この新規格の名称に含まれている「LE」はBluetooth 4.0から追加されたBluetooth Low Energy (BLE)から来たものですが、「お店にはBluetooth 5.0に対応したイヤホンがとっくに販売されているのに、どうして今更LEなんて名前をつけたのか」と違和感を感じた方もいるかもしれません。

実は、Bluetooth 4.0より前に標準化されたプロファイル（A2DP/HFPなど）は、製品が準拠するBluetoothのバージョンがいくつだとしても従来から存在するBluetooth BR/EDRの物理層上で動作しています。LE Audioは、このようなプロファイルを、BLEの物理層上で音声データのやり取りをできるようにする規格であるため、「LE」という名前が含まれているのだと考えられます。

上記の理由で、A2DP/HFPなどが利用できる製品にはBR/EDRが使用できるモジュールが搭載されています。逆にBLEのみの通信が可能なシングルモードのモジュールを搭載した製品ではA2DP/HFPなどのプロファイルは利用できません。Bluetooth BR/EDRはBluetooth Classicとも呼ばれていますが、（今のところ）決してBLEに取って代わられたレガシーなものではなく、むしろ日常生活には無くてはならない通信規格です。

では、実際にBluetoothイヤホンがBluetooth BR/EDRで通信をしているかどうかを確かめてみましょう。ここでは、Pixel4と3000円前後で購入したBluetooth 4.1準拠のワイヤレスイヤホンを接続し、音楽を再生するケースで試します。通信の確認方法として主なものは以下の2つです。

• 実際に機器から送信された電波をSnifferを使用して受信する
• HCI（Host Controller Interface）の通信ログを取得する

Androidの開発者オプションからHCIスヌープログの取得を有効にし、ワイヤレスイヤホンと接続します。その後、保存されたログをadb pullコマンドかbugreportコマンドで取得します。

HCIのパケットフォーマットは以下の4つが存在します。

Type	概要
HCI Command	HostからControllerへ指示するときに使用される
ACL Data	一般的なデータ転送に使用される
SCO Data	通話中の音声データの転送に使用される
HCI Event	ControllerがHostへ応答、通知をする時に使用される

基本的な流れとしては、HostがControllerへコマンドを発行し、それに対してControllerがHostへイベントを返す形で通信が行われます。A2DPなどでリモートホストと通信が開始されるとACL Dataで上位プロファイルのデータがやり取りされ始めます^[2]。

ログを先頭から読んでみると、HCI_ResetコマンドによるControllerの初期化後、バッファーサイズ、Controllerのバージョン、Bluetoothアドレスの読みとり、各種設定の書き込みなどが数十ミリ秒続いています。初期設定が完了したのち、BD/EDRおよびLEで付近のデバイスの検索処理が始まります。

スキャンを開始してまもなく、多数のBLEアドバタイジングパケットに紛れて目的のワイヤレスイヤホンからの応答がありました。Event Codeは Extended Inquiry Result でした。これはLEではなく、BR/EDRコントローラがリモートデバイスからの応答を受信した時に発生するイベントです。

HCI_Create_Connection コマンドが発行され、Pixel4とワイヤレスイヤホンが接続されます。HCI_Create_Connection はBR/EDRでデバイスと接続する際に使用されるコマンドであるため（LEで接続する場合は HCI_LE_Create_Connection が使われる）、ワイヤレスイヤホンとの接続はBR/EDRで行われていることが分かります。

さらに HCI_Read_Remote_Supported_Features のイベントからは、このワイヤレスイヤホンのControllerはそもそもBluetooth Low Energyに対応していないことが分かります。

HCI_Read_Remote_Supported_Features の部分に関しては、Bluetooth 5.0に準拠した別の完全ワイヤレスイヤホンとNexus5X（Android 8.1）の組み合わせでも確認しました。結果、こちらのイヤホンはBR/EDRとBLE両方に対応しているモジュールを使用していました。BLEのSnifferで確認するとGATTサーバが動作しており、Battery Service Profileのほか3つのサービスの存在が確認できました。イヤホンに接続した時に、Android端末側にワイヤレスイヤホンのバッテリーレベルが表示されますが、これはBattery Service Profileではなく、AppleがHFPに独自に拡張した機能を利用しているようです。少なくとも私が確認した環境では、BLEを使用してBattery Service Profileにアクセスしてはいないようでした。そのためBLEの機能は左右のイヤホン間での通信に使用していると思われます。もちろんA2DPの通信は、BR/EDRで行われています。

上記から、Bluetooth 4.0以降の仕様に対応した製品であっても、ワイヤレスイヤホンなどの従来のプロファイルの通信はBR/EDRで動作していることが分かりました。

唐突ですが、2019年8月頃に若干話題になったBluetoothの脆弱性(CVE-2019-9506)についてHostとControllerそれぞれでどのような対策をしたのかについて話します。

KNOB attackは、Bluetoothの暗号鍵の長さをネゴシエーションするプロトコルの脆弱性を突き、中間者攻撃を仕掛けることでBD/EDRの場合は鍵長を1バイト、LEの場合は7バイトまで短くすることができる攻撃です。
鍵長が1バイトということは容易にブルートフォースによる鍵探索が可能になります。さらに、BR/EDRは接続の度にネゴシエーションが発生するため、攻撃を行う機会を多く得ることができます。仮に、そのような攻撃を行うツールや環境を攻撃者が揃えることができたとすると、例えば喫茶店で重要な会議の録音データの音声をBluetoothイヤホンで聞いているサラリーマンなどは攻撃者の格好の獲物になりかねません。

脆弱性の原因は、ネゴシエーションが平文で行われていること、仕様上短すぎる（1バイト）鍵長を選択できたこと、鍵長が要求されるセキュリティレベルに対して適切かどうかを検証する仕組みについて規定されていなかったことなどが挙げられます。

脆弱性への対応として、Bluetoothの標準化団体からは仕様書のエラッタが発行されました。対策はBR/EDRの場合と、BLEの場合で異なります。

• BLEの場合
  ペアリング周りの処理がHost側で行われているため、オペレーティングシステムのセキュリティアップデートを適用することで修正が可能です。
• BR/EDRの場合
  ネゴシエーションに関する処理がController側で行われていたため、Hostが暗号化開始のイベント（ HCI_Encryption_Change ）を受け取った時にはすでに攻撃を受け、脆弱な暗号鍵が使用されている可能性があります。そのため、Hostは当該イベントを受け取った後、直ちに使用している暗号鍵（encryption key）が適切な長さ（7バイトまたは16バイト）以上かどうかを HCI_Read_Encryption_Key_Size コマンドを使用してControllerに問い合わせ、鍵長が不足している場合は切断するようHostがControllerに命令することで（なんとか）脆弱性に対処しました。

幸い、通信する機器の片方にパッチが充てられていればこの脆弱性の影響を受けないため、スマホのソフトウェアを最新版にアップデートをしておけば特別心配することはないでしょう。

ちなみに前項で使用したPixel4とイヤホンのHCIログを見ると、ネゴシエーションと暗号通信の開始後に HCI_Read_Encryption_Key_Size コマンドが発行されているため、Host側はしっかりと暗号鍵の長さを確認しているようです。

BluetoothのHostとControllerの関係を理解すると、Bluetooth機器のデバッグや、IoT機器のセキュリティ調査を効率的に進めることができます。是非、お手持ちの端末で試してみてください。

1. 仕様上、HCIはオプション扱いのため、実装によっては存在しないこともありえます。↩︎

2. 詳細はCore Specification 5.1 では Vol.2 Part Eに書かれています。↩︎