Bluetooth Low Energyのペアリングとボンディングについて(★★)
[BLE(Bluetooth Low Energy)の開発依頼は、フィールドデザインまでお気軽にお問い合わせください。]
ペアリングとは、セントラルとペリフェラル間のデータ暗号化のための鍵の交換をすることです。その時に、正しい相手かを認証をするために、双方で番号を入れるなどチェックをします。
ボンディングとは、ペアリングで交換した鍵を保存することです。ボンディングをしておけば、次回に同じ相手と接続するときに、ペアリングの処理は行わないで、前回に使った鍵をそのまま使い、データを暗号化できます。
ペアリングはするが、ボンディグはしないということもできます。その場合は、セントラルとペリフェラルが接続のたびに6桁の数字を入れたりして、相互認証を行う必要があります。
ペアリングは、Bluetoothのバージョンが上がるたびに変更されるため、経緯も含めて説明します。ここでは、Bluetooth Low Energyの扱っているペアリングしか説明しません(Classic Bluetoothを含めて説明すると、同じような言葉で意味が違うものがいくつも出てきて、非常にややこしくなるためです)。
Bluetooth Low Energyのペアリング方法には、2つのペアリング方法(Pairing Method)があります。2つあるのは、Bluetooth 4.0の時に最初に定義したペアリング方法に脆弱性があるため、Bluetooth 4.2でより強度の強い方法が追加されたことによります。なお、どちらの方法もデータ暗号化は、AES-CCMPアルゴリズムを使って行います。
- LE Legacy Pairing: Bluetooth 4.0の時に導入された方法。Legacyペアリングと呼ばれている。
- LE Secure Connections:Bluetooth 4.2から導入されたセキュリティの強い方法で、鍵交換に公開鍵暗号方式が使われます。LESCペアリングと呼ばれている。
それぞれに対して、アソシエーションモデル(Association Model)という認証接続方法が決められています。アソシエーションモデルとは、双方でボタンを押すとか、6桁の数字を入れるとか、などの認証のための手段のことです。
また、LegacyとLESCの使い分けですが、接続相手の両者でLESCをサポートしていれば、LESCを使うことが必須(shall)です(仕様的にLegacyを使うことはできません)。片方がLegacyしかサポートしてなければ、Legacyを使うことになります。
LE Legacy Pairing:Bluetooth4.0のペアリング方式(★★)
Bluetooth Low Energyをはじめて規格化された時に定義されたペアリング方法です。
LE Legacy Pairingには、3つのAssociation Modelがあります。
- Just Works:双方で認証をしない方法です。無線区間のデータを盗聴していれば、簡単に暗号化鍵がわかってしまいます。そのため、セキュリティの強度は、ペアリングのない、暗号化なしと変わりません。なお、下記のPasskey Entryの000000とケースと同じ処理です。
- Passkey Entry:片方が6桁の数字を入力するか、表示するかで、認証をする方法です。もし、Passkeyを固定にしていると、Brute Force Attackで簡単に解読されてしまいます。それ以外にも解読する方法が見つかっており、安全なModelではありません。
- Out of Band(OOB):NFC等の他の手段でPasskeyに相当するデータを交換するものです。現在のところ、脆弱性は見つかっておりません。
LE Legacy Pairingのシーケンスは下記のようになります。
- まず、お互いに持っているInput/Outputの方法(KeyboardやDisplay)を交換し、適したAssociation Modelを選択します。
- その後、決定されたAssociation Modelによってお互いを認証します。
その時に入力された番号を使って、STK(Short Term Key)と呼ばれる一時鍵を生成します。 - そのSTKを使って、データ暗号化に使う鍵であるLTK(Long Term Key)を交換し、ペアリングが完了します。その後の通信はこのLTKを使ってデータを暗号化します。
次回に接続するときは、このLTKが双方で保存されているので、ペアリングの処理をせずに、データを暗号化することができます。
以下では、Passkey Entryの場合のペアリングのシーケンスを示します。なお、Just Worksの場合は、下記のPasskeyが000000とした処理になります。
基本的に、暗号化はペリフェラルのLTKで行うため、最低限、それだけ共有すればペアリングは完了します。
ここで問題なのは、データの暗号化鍵となるLTKを無線区間で送るため、セキュリティの強度が弱いことです。LE Legacy PairingのPasskey Entryには脆弱性が存在するため、LTKを盗むことができます。そのため、次にあるLE Secure Connectionsが追加されました。
LE Secure Connections:Bluetooth4.2で追加されたペアリング方式(★★)
Bluetooth 4.2から追加されたペアリング方式で、楕円曲線暗号デフィーヘルマン鍵交換(ECDH)を使った方式です。この方式では、LTKは無線区間で送ることはしないため、安全です。脆弱性も現在のところ見つかっておりません。
LE Secure Connectionsには、4つのAssociation Modelがあります。
- Just Works:双方で認証をしない方法です。LE Secure ConnectionsのJust Worksは、公開鍵暗号方式で鍵交換されているため、盗聴されて、暗号鍵が解読されることはありません。しかし、Passkeyが000000とわかっているため、誰でも接続して相手のデータを盗むことは可能です。
- Passkey Entry:片方が6桁の数字を入力するか、表示するかで、認証をする方法です。
- Out of Band(OOB):NFC等の他の手段でPasskeyに相当するデータを交換するものです。
- Numeric Comparison:毎回ランダムな数字を双方で表示し、それらが同じであればそれぞれでボタンをおすことで、認証をします。
LE Secure ConnectionsでのAssociation Modelは、相手の装備(ディスプレイ、キーボードなど)との組み合わせにより下記のようなパターンがあります。Initiatorはペアリングを開始する側で、一般的にはセントラルになります。Responderはペアリングを受ける側で、一般的にはペリフェラルになります。
LE Secure Connectionsのシーケンスは下記のようになります。
- まず、お互いに持っているInput/Outputの方法(KeyboardやDisplay)を交換し、適したAssociation Modelを選択します。
- お互いで楕円曲線暗号の公開鍵と秘密鍵を生成し、公開鍵を交換します。
- その後、決定されたAssociation Modelによってお互いを認証します。お互いの公開鍵を使って、LTKを生成する情報を交換し、ペアリングが完了します。その後の通信はこのLTKを使ってデータを暗号化します。
この方法は後から追加されたためオプションで、相手がこの方法をサポートしてないときは、セキュリティ強度の弱いLE Legacy Pairingを使用することになってしまいます。
以下では、Passkey Entryの場合のペアリングのシーケンスを示します。なお、Just Worksの場合は、Passkeyを000000とした処理になります。
上記で20回繰り返しているのは、Passkeyを1bitずつ送り、チェックするためです。
Passkeyは6桁なので、1000000通りあり、これは0xF4240なので、20bitになり、20回になります。
また、上記をみてもわかるようにLTKは無線区間で送信されることはありません。
Bluetoothで利用される鍵(★★)
LE Legacy PairingでもLE Secure Connectionsでも、ペアリング時に交換される鍵情報は同じです(LE Legacy PairingではSTKを一時的に使いますが)。それぞれの役割について記載します。
鍵名 | 役割 |
LTK | 通信路を暗号化する時に利用する。第3者がデータを盗み見ることができないようにできる。 |
IRK | Bluetoothアドレスをランダム化する時に利用する。第3者にBluetooth機器を特定されないようにできる。 |
CSRK | データに署名する時に利用する。第3者にデータを改竄されないようにできる。 |
暗号化開始のトリガー(★★)
Bluetooth Low Energyでは、characteristicごとにアクセス権限を設定できるため、接続時に必ずしも、暗号鍵にて通信路を暗号化する必要はありません。これは、Wi-FiやHTTPSなど通常の通信と大きく異なるところです。そのため、暗号化を開始するにはいくつかケースがあります。
- セントラルからペアリングを行うことにより(スマートフォンなどの”設定”でペアリング開始)、ペアリングが実施され、そのまま暗号化通信が引き継がれるケース。
- セントラルが、ペリフェラルのセキュリティ有効にしてあるcharacteristicにアクセスし、Insufficient Authenticationが返ってくることで、セントラルが暗号化を開始するケース。
- ペリフェラルが接続後に、暗号化要求をセントラルに送ることで、セントラルが暗号化を開始するケース。ただし、この方法は、Bluetooth規格ではオプションのため、サポートしてないセントラルがあるかもしれません。
なお、Bluetooth v5.4からは、GAPサービスにLE GATT Security Levels(UUID:0x2BF5)が追加になり、このcharacteristicを読むことで、暗号化が必要かわかります。暗号化が必要とわかれば、先に、セントラル(クライアント)から暗号化開始をすれば、スムースに処理ができます。
ペアリング・ボンディングでよくある不具合(★★)
ペアリング関連でよくある不具合として、下記のものがあります。
- ペリフェラル側をペアリングなしで動作させたため、他のデバイスが勝手に接続してきて、本来接続すべきデバイスが接続できない。
- ペリフェラル、セントラルの片方のボンディング情報を消してしまい、その後、接続できなくなる。
1つ目の問題は、キーボード、マウスなどで、ペアリングなしの仕様にしてしまうと、誰でも接続できてしまうため、通信が瞬断した場合に、その期間に他の機器が接続してしまうという脆弱性です。
この解決策は、ペアリング・ボンディングありの仕様に変更するしかありません。
2つ目の問題は、Bluetooth Low Energyの鍵は、ランダムな数字を使って生成するため、同じ機器どうしでも毎回違う鍵になります。そのため、片方のボンディング情報を消してしまうと、残った方のボンディング情報は世の中のどれとも接続できない鍵情報になってしまいます。この場合は、残った方のボンディング情報を消して、再度、ペアリングからやり直すしかありません。やっかいなのは、ペリフェラル側のボンディング情報が消えていても、接続までは通るため、あたかも接続できているようにセントラル側にみえることです。セントラルがスマートフォンなどの場合では「接続」という表示にかわります。そのため、何がおかしいのか判断ができなくなり、対策もできなくなる点が厄介です。