2015/12/27

[nrf51]PairingとBonding (2)

hiro99ma blog: [nrf51]PairingとBonding

そういえば、Bondingに対する私の理解が解決していなかったことを思い出した。
まあ、ありていにいえば「よくわかってない」なのだ。


Bonding without passkey is possible using nRF51822? - Nordic Developer Zone

パスキー無しでBondingできますか?という質問。
「Yes」、彼は軽やかに答える。

パスキー無しということは、お互いで同じパスキーを固定で持っているのと同じ、ということのようだ。
MITMビットを0に、IO capabilitiesをBLE_GAP_IO_CAPS_NONEにすると、Just Worksというペアリング動作になる。

In that senario、で、お互いパスキーが”000000”を使う、と書いてあるが、シーケンスにはパスキーの中身は出てこないので”000000”という値も固定なのかな?
質問者も同じことが気になったようだが、回答としては「S110は自動的に000000を使うが、電話メーカーによっては0のみのパスキーをエラー扱いにするところもあるので注意してね」ということらしい。

回答者は、BLEのセキュリティは”not very secure when using PIN authentication”という認識を持たれているようだ。
OOB > PIN > Just Worksの順にsecureで、Just Worksは全然secureじゃないよ、と。


という予備知識を身につけたところで、仕様書を確認しよう。
Vol.3 Part.H “Security Manager Specification”だ。

まず、このシーケンス図。

image

PDFのp.2285(Core_V4.2)に乗っているのだが、フェーズが3つある。
これが、NordicのBondingシーケンスに出てくるフェーズか。
なんの数字かわからないままだったのだ。

フェーズは、こういう名前が付いている。

  • Phase1 : Pairing Feature Exchange
  • Phase2 : (LE legacy pairing)  Short Term Key Generation
  • Phase2 : (LE Secure Connections)  Long Term Key Generation
  • Phase3 : Transport Specific Key Distribution

Phase2が2つある。
どちらもLEがついているのだけど、Part.H自体は表紙に”LE-only or BR/EDR/LE devices”とあるから、LE専用の章ではないのだと思う。
上の図だって「LE Paring Phases」なんだけど、それ以外のシーケンス図が見当たらない。
どこか読み飛ばしているのだろうか。。。

 

Connectionシーケンスの一部では無く、Connectionの後に行うシーケンスなのだ。
まあ、失敗したら切断するのだろうけども。

まず、フェーズ2で次のどれを使うか決めるために情報交換する。

  • Just Works
  • Numeric Comparison
  • Passkey Entry
  • Out Of Band

Numeric Comparison?初めて聞いた。
これはBLE専用らしい。
Core_V4.1のPDFには載っていないから、4.2から新しく追加されたのだ。

暗号化の細かいところは読み飛ばすが、AES-128bitのようだ。
128bitということは、16バイト。
データのどこから暗号化するのかはまだ読んでいないが、元が16バイト以内のデータなら16バイトに、32バイト以内のデータなら32バイトになるのだろう。
ブロック暗号だから、そうなるはず。。。自信はないけど。。。


パケットのフォーマットは、Vol.6 Part Bにあった。

image

一番短いパケットは80bit、一番長いパケットは2120bitとのこと。
そうだ、Core_V4.2からPDU長が拡大されたんだ。

BLEスニファでこういう風に見えているデータがあったとして、

image

これのうち、実際に無線として出回っているのはここまでということだ。

image

プリアンブルは、Advertisingのチャネル(37~39)で流す時とそれ以外でルールが違うようだ。
面白そうではあるが、そういうのは下回りを作る機会があったときために残しておこう。

 

このうちのどこが暗号化されるか。
アクセスアドレスの説明を読むと、ペアリングしたときの情報で生成する方法もあるようだから、AESで暗号化するのはせめてPDU以降ということか。
CRCはPDUの部分を計算するようだから、CRCも暗号化対象外だろう。
つまり、無線を受信したら、暗号化を解読せずにデータが正しいかどうか判断できるというわけだ。


長くなってきたので、今回はここまで。

2 件のコメント:

  1. 私が理解している事を書きます。間違いがあれば指摘してください。

    パスキーが000000だと分かっている場合、最初のBondingプロセスから盗聴すれば、Short Term Key, Long Term Key(LTK)とも解読できてしまう。LTKがあれば、その後の通信も解読可能。

    LTKを交換している時に盗聴されていなければ、その後の通信はAESで保護される。

    パスキーを000000以外にして初期Bondingをすれば、盗聴されてもLTKが解読される事はない。
    ただ、123456のような予想可能な値の時は、LTKが解読可能となる。

    返信削除
    返信
    1. 間違っているかどうかは知りませんが、スニファもそういう感じで動かすので、そういう気がしますね。

      削除

コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。

注: コメントを投稿できるのは、このブログのメンバーだけです。