Wireless・のおと

サイレックスの無線LAN 開発者が語る、無線技術についてや製品開発の秘話、技術者向け情報、新しく興味深い話題、サイレックスが提供するサービスや現状などの話題などを配信していきます。

前の記事:「Linuxドライバのはなし」へ

Bluetoothのセキュリティのはなし

2015年9月30日 10:00
YS
ネットを検索すると「Bluetooth LE はペアリングの必要がないので...」という記述にちょくちょく出くわします。これは間違いではないのですが、必ずしも正しい既述でもありません。今回は Bluetooth のセキュリティの話です。

Bluetooth のセキュリティ
Bluetooth のセキュリティ機構は WiFi と似ているところもあり、違うところもあります。WiFi のセキュリティは原則としてアクセスポイントと子機の間で設定されますが(※註)、Bluetooth ではマスター(親機)とスレーブ(子機)の間で設定されます。セキュリティを成立させるため、Bluetooth の親機と子機は相互に登録して秘密鍵を交換・保存する必要があり、この手順を「ペアリング」と呼んでいます。ペアリングは Bluetooth におけるセキュリティの中核をなす概念となります。

※註:ただし WiFi エンタープライズセキュリティを使用する場合は、セキュリティの管理はアクセスポイント外の RADIUS サーバに集約されることが普通です。Bluetooth にはエンタープライズに相当するセキュリティの概念はありません。


WiFi の場合、古い WEP では「アクセスポイント毎」に暗号鍵を設定していました。しかし全ての子機が同じ暗号鍵で通信することは暗号の解読を容易にする欠陥があり、後の WPA/WPA2 ではアクセスポイント毎に設定された秘密鍵(PSK, あるいはパスフレーズ)を元情報として、子機ごとに異なる暗号鍵(PTK)を動的生成し使用するよう改められています。
Bluetooth の暗号化でも WiFi WPA 同様、マスター・デバイス間ごとに異なる暗号鍵が使われます。Bluetooth Classic の場合これを「リンクキー」と呼び、Bluetooth LE では「LTK(Long Term Key)」と呼びます。Bluetooth には WiFi WPA の PSK に相当する「ユーザーが設定するパスワード」はなく、ペアリング設定時にマスターとデバイス間で鍵の動的生成を行います(※註)。場合によってはこのとき「交換された鍵の正しさ(通信経路上で第三者によって鍵が差し換えられていないこと)」の検証(認証)も行います。
この「ペアリング操作によって暗号鍵の交換を行う」「ペアリング時にオプションで認証を行う」という基本概念は Classic でも LE でも共通です。

※註:実は古い PIN モードのペアリングでは「Unit Key」と「Combination Key」の2方式が定義されており、このうち Unit Key ではペアリング時に疑似乱数交換を行わないため、暗号鍵は静的に近いものになります(Core Spec 4.2 Vol.2 Part.H 3.2.3)。もっとも PIN モードは既に Obsoleted とされており、Unit Key は更に遡って Deprecated 宣言されているため、「過去にはそういう物もあった」という程度の話です。


ペアリングが成立すると、通常はマスター=スレーブ間の秘密鍵(リンクキー)は外部から読み出しにくい(と考えられる)領域に保存されます。次回電源投入時には保存されたリンクキーを読み出して通信するので、一度ペアリング成立したデバイスは(設定消去しない限り)次回は電源投入するだけで接続・使用できる理屈になっています。
実は Bluetooth の仕様書において、ペアリングという用語は「鍵交換プロトコルの実行」を指し、「交換した鍵の保存」は「ボンディング(Bonding)」という用語で区別されることになっています(Core Spec 4.2 Vol.3 Part.C 16.5)。しかしこの区別はあくまで仕様書の中でプロトコルや手順の解説に使い分けられているだけであり、製品を操作して Bonding を実施する行為は一般的に「ペアリング」と呼ばれます。Bluetooth の仕様書中でもコンテキストによって「ペアリング」という言葉が「ボンディング」の意味を兼ねていることがあり、仕様書を読むうえで混乱しやすいところです。本コラムにおいては原則として、ボンディングの意味も含めて(より馴染みの深い)「ペアリング」という用語を使っています。


Bluetooth Classic の場合
Bluetooth Classic のセキュリティ仕様は、Core Spec 4.2 Vol.3 Part.C 5.2.1)でモード 1 からモード 4 までの「セキュリティモード」として定義されています

Mode 1:Non-Secure
セキュリティ無しのモード。認証・暗号ともに無し。

Mode 2:Service level enforced security
接続にはセキュリティを要求しないが、データ通信時に必要に応じて認証・暗号化を行う。

Mode 3:Link level enforced security
接続時に認証・暗号化を行う。要するに何をするにもペアリング必須のモード。

Mode 4:Service level enforced security
使用状況に応じて認証・暗号化を行う。例えばサービス検索(SDP)応答はセキュリティを要求しないが、データ通信にはセキュリティを要求する。

このように、Bluetooth Classic も通信仕様上では「ペアリングを必要としない」使い方(モード1)が定義されていますし、BlueZ などのスタックを使えば実際にペアリング無しの L2CAP や RFCOMM のセッションで通信させることも可能です。
しかし現実には、ほぼ全ての Bluetooth 製品はモード 4 として実装されています。モード 1 とモード 2 は Bluetooth 2.0 以前の過去互換性のためだけに残されているもので、2.1 以降の Bluetooth 製品ではモード 4 の実装が義務付けられているからです。

モード 4 の下では更に、5 段階の「セキュリティレベル」が定義されています(Core Spec 4.2 Vol.3 Part.C 5.2.2.8)。

Level 0:セキュリティ無し、ユーザー操作なし
Level 1:セキュリティ無し、ユーザー操作あり
Level 2:暗号あり、認証なし
Level 3:暗号あり、認証あり
Level 4:高強度暗号あり、認証あり

このなかでレベル 0 の使用は、SDP サービス検索などセキュリティがあると逆に不便な用途に限定されています。レベル 1 とレベル 0 の違いがわかりにくいのですが、Table 5.8 を見るとレベル 1 は非認証であってもリンクキーの成立が要求されており、これはペアリング成立済みの相手に暗号化なしで通信する用途(接続前手順など)と理解すべきでしょう。

要するに Bluetooth Classic においては、仕様上は暗号(ペアリング)無しの通信手順も定義されているものの、現実の製品としてはペアリングが必須ということになります。技術的には暗号無しの通信を実装することは可能ですが、それでは Bluetooth の仕様規定を満たさないためロゴ認証プログラムを通過できず、製品としては販売できません。


Bluetooth Classic のペアリング詳細
Bluetooth Classic のペアリングは LMP (Link Management Protocol) という階層で実装されます。LMP は ACL の上にあり、ACL パケットの LLID 値が 3 であることをもって認識されます(LLID=1 または 2 は L2CAP)。
Bluetooth Classic のペアリングには Bluetooth 2.0 以前の「PIN モード」と、2.1 以降の「SSP (Simple Secure Pairing)モード」があります。上記の「セキュリティモード」ではモード 2 と 3 が PIN に、モード 4 が SSP に対応します。

PIN モードは数字で最大 16 桁の暗証コードを打ち込むことで認証するモードですが、暗号化は簡易なハッシュ交換によっており、また多くの Bluetooth 製品では「0000」「1234」「9999」など固定の 4 桁コードとして実装されているため、決め打ち攻撃で容易に破れてしまうので現在では安全だとは考えられていません。既に述べたように PIN モードは Obsolete とされており、過去に販売された製品との接続性確保のためだけに仕様書に残されています。

SSP モードは ECDH(楕円曲線ディフィ・ヘルマン)アルゴリズムの公開鍵交換方式を使い、盗聴に対する安全性が向上しています。また通信中継者が公開鍵を差し換える「MoM 攻撃」に対処すべく、複数の認証方式がサポートされています(Core Spec 4.2 Vol.2 Part.F 4.2.9~)。

- Just works:認証なし。マウス、ヘッドフォンなど入力も表示もできないデバイスに使用。

- Passkey entry:マスター側で表示された「パスキー」をデバイスに入力して認証する。キーボードなど入力機能のみを持つデバイスに使用。

- Numeric comparison:デバイス側で表示された「認証コード」をマスター側の表示と比較して一致確認する。カメラ・プリンターなど表示機能のみを持つデバイスに使用。

- Out Of Band(OOB):USB, NFC など Bluetooth 以外の通信手段をもって認証する。現実に実装した製品はごく少ない。

これらの認証モードはホストとデバイスの表示・入力能力(IO Capability)の組み合わせによって適切な方式が選択されます。操作上「Passkey entry」は PIN 方式と似ていますが中身は全く別のプロトコルとなっており、しかもパスキーは 6 桁以上の数字が毎回乱数生成されるので、PIN 方式のような既知文攻撃や総当たり攻撃で破るのも難しくなっています。

実際のパケットの暗号化は、Bluetooth 4.1 以前の仕様では E0 と呼ばれる暗号アルゴリズムが使用されています。後から制定された Bluetooth LE ではより強力な AES-CCM 暗号が採用されており、Bluetooth 4.2 以降ではこの AES-CCM を Bluetooth Classic でも使用できるオプションが拡張されました(Core Spec 4.2 Vol.2 Part.H 9)。いずれの場合もリンクキーをそのまま暗号鍵に使うことはなく、交換した疑似乱数とリンクキーから生成した動的な疑似乱数が暗号鍵として使われます。



Bluetooth LE の場合

Bluetooth LE のペアリングや暗号鍵の保持方式のコンセプトは Classic と共通するところが多いのですが、用語定義が違っていたり似たような単語が違った意味で使われるので混乱しやすいです。

Bluetooth LE には「セキュリティモード」と「セキュリティレベル」の概念があり、モードには 1 と 2 があって、それぞれ数段階の「レベル」が定義されています(Core Spec 4.2 Vol.3 Part.C 10)。ここで使われる「セキュリティレベル」は、Bluetooth Classic の GAP セキュリティモード 4 における「セキュリティレベル」とは異なる意味なので注意してください。ややこしいですね。

LE Security Mode 1:
Level 1:セキュリティ無し
Level 2:暗号あり・認証なしのペアリング
Level 3:暗号あり・認証ありのペアリング
Level 4:LE Secure Connections を使ったペアリング

LE Security Mode 2:
Level 1:認証なしのペアリング+データ署名
Level 2:認証ありのペアリング+データ署名

モード 2 にある「データ署名(Data Signing)」は Bluetooth LE の機能というより、Bluetooth LE の標準フォーマットであるアトリビュート・プロトコル(ATT)の機能です(Core Spec 4.2 Vol.3 Part.F 3.3.1)。これは特に高速の接続・切断・転送を必要とするサービスに使用されるもので(Core Spec 4.2 Vol.3 Part.C 10.4)、原則として暗号化無しの状態で使うと定義されています(Core Spec 4.2 Vol.3 Part.C 10.2.2)。データ署名を行うために、暗号化・認証とは別に CSRK (Connection Signature Resolving Key) と呼ばれる鍵が用意されており、ペアリング時の "Sign" フラグによって CSRK が追加で交換される仕組みになっています(Core Spec 4.2 Vol.3 Part.H 3.5.1~)。

Bluetooth LE において、暗号化(≒ペアリング)の必然性はサービスの性質によって決まると定義されています(Core Spec 4.2 Vol.3 Part.C 10.3.1)。GATT プロトコルの要求を受けるところまでは無条件で、それを処理し返答を返すか否かにおいて、要求されたアトリビュートのセキュリティ要件(ATT レベルの Permission 属性、Vol.3 Part.F 3.2.5)によって処理を変えます(Table 10.2 / Figure 10.1)。これが前述の「必要に応じて」の判断条件となります(※註)。

※註:この辺はやっぱり SNMP に似ていますが、後からセキュリティ構造を被せた SNMPv3 のセキュリティ MIB(USM/VACM)が死ぬほど複雑なものになったのに対し、最初からアトリビュート構造にセキュリティ属性を統合してある ATT はもっと簡易で理解しやすいものになっています。

Permission 属性には Encryption(暗号化), Authentication(認証), Authorization(認可)の3つがあり、それぞれに Not Required / Required の組み合わせがあります。Permission 属性と Security Mode/Level の対応関係は Bluetooth 仕様書原文ではまとめられていません。あえてまとめると下の表のようになります。

Encryption
Not Required
Encryption
Required
Authenticaiton Not RequiredMode1 Level1Mode1 Level2
Authenticaiton RequiredMode2 Level1/2Mode1 Level3/4

Figure 10.1/10.2 では「セキュリティ無し(security not required)」の場合「Level 1」、「暗号化無し(Encryption Needed=No)」の場合「Mode 2」を使うとのみ既述されており、Mode2 における Level1/2 の使い分けについては明記されていません。「Encryption Not Required」+「Authenticaiton Required」の場合、認証ありのペアリングすなわち Mode2 Level2 を指すような気もするのですが、Core Spec 4.2 Vol.3 Part.C 10.4 には「データ署名は認証されたデータの交換に用いる(※註)」という記述があり、データ署名をもって認証とみなすと解釈できるようでもあります。そうすると Mode2 における Level 1/2 の違いは何なのだろうと思いますが、仕様書ではどうもはっきりしません。

※註:The data signing is used for transferring authenticated data between two devices in an unencrypted connection.

なお Authorization は「ユーザーの介入による続行確認」となっており、プロトコル上の暗号化/認証とは無関係なようです(Core Spec 4.2 Vol.3 Part.C 10.5)。


Bluetooth LE のペアリング
Bluetooth LE は Classic と異なり LMP 層を持たず、セキュリティは Security Manager と呼ばれる階層で定義されます(Core Spec 4.2 Vol.3 Part.H)。Classic で「リンクキー」と呼ばれていた暗号鍵は LTK (Long Term Key)と呼ばれるようになりました。LTK があれば STK (Short Term Key)もあり、STK は LTK の交換時に使われる一時的な暗号鍵を指します。
Bluetooth LE 4.1 以前のペアリング方式は Classic の SSP と似ていますが、プロトコルはハッシュを用いた簡易なものとされており、Numeric comparison 認証オプションがありません。この簡易鍵交換は LE 仕様の公表直後からセキュリティホールになると批判されており、4.2 以降では SSP と同じ ECDH を使う「LE Secure Connections」が追加されました。これによって、4.1 以前のペアリング方式は「LE Legacy Pairing」と呼称されることになっています(Core Spec 4.2 Vol.3 Part.H 2.3.5)。


Bluetooth LE Random Address


Bluetooth LE 仕様ではホスト/デバイスの役割を「Broadcaster」「Observer」「Peripheral」「Central」として定義しており、それぞれに要求されるセキュリテイ要件(Privacy Feature)を定めています(Core Spec 4.2 Vol.3 Part.C 10.7)。ここで多用されている「ボンディング(Bonding)」とか「ボンダブル(Bondable)」という言葉は冒頭に書いたように、「ペアリング手順を実行し交換された鍵を格納すること」を意味しています(Core Spec 4.2 Vol.1 Part.A 5.1)。
10.7 では Private Address という言葉が矢鱈に沢山出てきます。Private Address というのは Bluetooth LE で拡張されたセキュリティ機能で、通信時にデバイス固有の物理アドレス(Public Address)を使用せず、動的に生成された乱数アドレスを使用するというモードです。固定物理アドレスによるデバイスの追跡や秘密鍵情報の推定、DoS 攻撃を避ける目的などがあると思われます。
Bluetooth LE では「Public Address」と「Random Address」の2種類のアドレスが使用可能で、Random Address には更に「Static Device Address」「Non-Resolvable Private Address」「Resolvable Private Address」の3種類が定義されています(Core Spec 4.2 Vol.6 Part.B 1.3.2)。一体どうして似て非なるものが3種類も定義されているのか、どれをどういう場合に使い分けるのか、仕様書にはまとまった既述がないので凄くわかりにくいのですが、簡単にまとめると次のようになります。

Random Static Address(再上位2ビット=11)
電源投入のたびに生成される乱数アドレス。電源再投入されないかぎり変更されない。デバイス固有の物理アドレス(Public Address) の代わりに使うことができ、この場合「Public または Random Static Address」をまとめて「Identity Address」と呼ぶ

Non-Resolvable Private Address(再上位2ビット=00)

動的に生成される乱数アドレス(※註)。

Resolvable Private Address(再上位2ビット=10)
動的に生成される乱数アドレス(※註)。ペアリング時に交換された鍵(IRK)に基づいて生成され、これを受信した側は IRK を用いることでアドレスの正当性を検証(Resolve)できる。

※註:Private Address 再生成間隔は 15 分推奨(Core Spec 4.2 Vol.6 Part.B 6.1)


Private Address における Non-Resolvable と Resolvable の使い分けがどうも曖昧なのですが、Core Spec 4.2 Vol.3 Part.C 10.7 を見ると、「Privacy Features」対応を名乗るためには

- Central/Peripheral の場合:Resolvable Private Address の実装必須。Non-Resolvable はオプション。
- Broadcaster/Observer の場合:Resolvable あるいは Non-Resolvable どちらかの実装必須。

という定義になるようです。何だかねぇ...考え過ぎじゃないか、という気がします。使用条件に合わせていろいろ選択できるようにしたつもりでしょうが、似て非なるものを2つも3つも用意するのは大抵、余計な実装の混乱につながるんですよねぇ。



まとめ

以上のことを箇条書きにまとめると、次のようになります。

Bluetooth Classic の場合
ペアリング=暗号化の実装は製品として必須。仕様上は非暗号化通信も可能だが、それを用いた実装では製品ロゴ認可を通らない。
・ペアリング方式には PIN (2.0 以前)と SSP (2.1 以降)があるが、PIN は既に廃止され互換性のためだけに残っている。
・SSP モードでは JustWorks(認証なし), または Passkey Entry, Numeric Comparison, OOB のペアリング認証を伴う。
・暗号アルゴリズムは E0 を使用、4.2 以降ではオプションとして AES-CCM が追加。

Bluetooth LE の場合
・ペアリング=暗号化の必要性は、デバイスのロール(Broadcaster/Observer/Peripheral/Central)とアトリビュートの属性(Privacy Feature)に従う。
・ペアリング方式には LE Legacy (4.1 以前)と LE Secure Connections (4.2 以降)がある。
・ペアリング認証は Bluetooth Classic とほぼ共通。ただし LE Legacy Pairing では Numeric Comparison をサポートしない。
・暗号アルゴリズムは AES-CCM を使用。
・「Privacy Feature」対応実装の場合、乱数アドレスを用いることで物理アドレスの暴露を最少化できる。

こうやって並べてしまえば簡単なことですが、これを仕様書原文(Bluetooth Core Spec 4.2、本文 2772 行、PDF にして 23.8MByte)から読み解くのはそう簡単ではありません。今回はクドイくらいに仕様書原文の出典を記してありますが、これには「WEB 上の二次解説ばかりに頼らず、頑張って仕様書原文を読もうぜ!」という意図を込めております。



次の記事:「GATTのはなし」へ

最新の記事

カテゴリ

バックナンバー