[nrf51]BLEスタックのイベントハンドラを見る (3)

nRF51 SDKを読んでも理解できなかったので、ネット上にあるNordic社の説明を読むことにした。
ゆっくりだ、ゆっくりとやろう。

---

BLE_GAP_EVT_SEC_PARAMS_REQUEST

https://devzone.nordicsemi.com/documentation/nrf51/4.3.0/html/group__nrf51__evt__sec__param__request__encoding.html

いきなりフレームフォーマットがどうのこうのと書かれているが・・・何もわからん。
BLEの通信プロトコルのどこかだろうと検索するが、それっぽいものが見つからない。

セキュリティから始めるのは、敷居が高かったか。

---

ソースでやっていることは、これ。

err_code = sd_ble_gap_sec_params_reply(m_conn_handle,
                                       BLE_GAP_SEC_STATUS_SUCCESS,
                                       &m_sec_params);

m_sec_paramsの内容を渡しているだけのようだ。
このパラメータは、あらかじめ設定している。

    m_sec_params.timeout      = SEC_PARAM_TIMEOUT;
    m_sec_params.bond         = SEC_PARAM_BOND;
    m_sec_params.mitm         = SEC_PARAM_MITM;
    m_sec_params.io_caps      = SEC_PARAM_IO_CAPABILITIES;
    m_sec_params.oob          = SEC_PARAM_OOB;
    m_sec_params.min_key_size = SEC_PARAM_MIN_KEY_SIZE;
    m_sec_params.max_key_size = SEC_PARAM_MAX_KEY_SIZE;

sd_ble_gap_sec_params_reply()を追っていったが、m_sec_paramsは別にstaticで持つほどでもないように見える。
中で値を詰め替えているみたいだ。

#define SEC_PARAM_TIMEOUT               (30)
#define SEC_PARAM_BOND                  (1)
#define SEC_PARAM_MITM                  (0)
#define SEC_PARAM_IO_CAPABILITIES       BLE_GAP_IO_CAPS_NONE
#define SEC_PARAM_OOB                   (0)
#define SEC_PARAM_MIN_KEY_SIZE          (7)
#define SEC_PARAM_MAX_KEY_SIZE          (16)

• timeout : SMPトランザクションかセキュリティ要求のタイムアウト時間(秒)
• bond : bondingの有無
• mitm : Man In The Middle保護要求
• io_caps : IO能力
• oob : Out Ob Bandデータの許容
• min_key_size : 符号化鍵の最小サイズ(byte)。7～16。
• max key_size : 符号化鍵の最大サイズ(byte)。min_key_size～16。

わからない用語が出てきたので、それぞれ調べる。

• bonding
• ペアリングのことらしい。Bluetoothのチップでは、よくbondingという表現を見かける。微妙に違いがあるのかもしれない。
• Man In The Middle(MITM)
• ネットで調べると、MITM attackという言葉が出てくる。
  Core_v4.1.pdf p.216「5.2.3 Man-In-The-Middle Protection」を読むと・・・2台のデバイスを接続させようとしているときに、不正な第三者(attacker)と接続してしまうことを指しているようだ。each otherとあるから、それぞれのデバイスは相手とつながっていると思ってるけど、実は間にattackerが入っている(Man-In-The-Middle)、ということか。
  これをさせないために、Secure Simple Pairingという方法を採るらしい。お互いしか知らない数字を入力させるような形だ。
• こういうモデルがあるようだ
• Numeric Comparison
• Just Works
• Out of Band
• Passkey Entry
• IO能力(GAP IO capabilities)
• define値としては5つ用意されている
• DISPLAY_ONLY : Display Only
• DISPLAY_YESNO : Display and Yes/No entry
• KEYBOARD_ONLY : Keyboard Only
• NONE : No I/O capabilities
• KEYBOARD_DISPLAY : Keyboard and Display
• Core_v4.1.pdf p.2251がそれか(Vol.3 Part.H Security Manager)。
• 接続成立後、Secure Simple Pairingのサポート状況と、IO capabilityを交換する。
• IO capabilityを交換する理由は、Simple ParingのAuthentication State 1で認証アルゴリズムを決定するため。
• inputは「入力できない」「Yes/Noくらいならできる」「数字キーボードあり」
• outputは「表示できない」「数字出力できる」
• これを組み合わせると6パターンになるが、「input：Yes/No」「output：No output」の組み合わせについてはアルゴリズムがない。
• OOB認証が使える場合は、そちらを優先するのかな？
• Out of Band
• これはNFCでSimple Secure Paringをしたときにも出てきたが、対象とする機器以外を指す。狭義では、別の周波数帯、ということになるのか。
• 認証アルゴリズムについて細かいことはCore_v4.1.pdf p.1958に書いてあるので、省略。
• 符号化鍵のサイズ
• p.2252そのままだ。
• あまり考えず、このままの値でよいのかな。

---

そういうわけで、BLE_GAP_EVT_SEC_PARAMS_REQUESTについては以下のように扱うことになるだろう。

• サンプルと同じく、sd_ble_gap_sec_params_reply()でセキュリティ設定を返す。
• おそらく接続直後か、接続する手前か、その辺りで呼ばれるのではなかろうか。
• セキュリティ無し無しならばサンプルのままでよい。
• セキュリティ有りにしたときの動作は、未調査。