2014/11/01

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

1 件のコメント:

  1. この辺りについては、以下が詳しいです。
     CQ出版社「Interface」 2013年5月号:Bluetoothドングルを制御するマイコン・プログラムの全容

    返信削除

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

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