[nrf52][nfc]NFC Pairingサンプルを動かす (2)

さて、前回はnRF52のサンプルを使ってNexus5とペアリングしようとして、失敗した。
Nexus7でもやってみたけど、タブレットってNFCのポイントを明示してくれないと、どこにかざしていいかわからんですな。
背中が広いので、アンテナも強そうな感じはするんだけど、かざし方が悪いのか、動作としてペアリングできないのかの区別が付かなかった。
もうちょっと、かざして！ってサインを出してくれないとなぁ。

その辺は、ペアリングのしくみがわかれば何とかなるかもしれないので、今回は仕様の方を見ていこう。

---

http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk52.v0.9.1%2Fble_sdk_app_hrs_pairing_nfc.html&cp=4_0_0_4_6_0

これが試したサンプルのページなのだが、これを読んでも方法がわからない。
手持ちの資料が古いかもしれないが、NFCでのハンドオーバーは、

• Netotiated Handover
• Static Handover
• Mediated Handover

の3種類がある。
調べていた当時の私は、Bluetoothに興味がなかったので、手抜きな調べ方しかしていない。
(というより、なぜHandoverを調べていたのか記憶がない。。)

hiro99ma blog: [nfc]BluetoothのStatic Handover

とはいっても、nRF52のサンプルがどういうペアリングをしてくるかわからないと、調べようがないな。

---

http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk52.v0.9.1%2Fgroup__nfc__modules.html

こちらが、現在(nRF52 SDK v0.9.1)でのNFC関連のモジュールらしい。
NDEFとかOOBとかの見知ったキーワードは出てくるのだが、HandoverとかSSPとか、そういう関連用語が出てきてないように見える(探せないだけかもしれんが)。

サンプルソースから見ると、先にAdvertisingするメッセージを作り、それをnfc_ble_pair_msg_create()に食わせることでNDEFのペイロードデータを作ろうとしているようだ(nfcSetPayload()で渡してるので)。

application/vnd.bluetooth.le.oob で、NFC_BLE_PAIR_MSG_BLUETOOTH_LE_SHORTとNFC_BLE_PAIR_MSG_BLUETOOTH_LE_FULLがあるようだ。
それらの値の説明を見ると、AD-BTSSP_1_1とNFC Forumドキュメント名が書いてあるので、SSP(Simple Secure Pairing)であることは間違いなさそうだ。

ただ、SSPのドキュメントを読んでもわかるもんじゃないので(SSPは「このHandover方式で」などは決めていない)、やはりソースを読まないとどうやっているかわからないようだ。
まあ、読んだからといっても、ライブラリで隠蔽しているところがあるとわからないだろうがね。

---

サンプルソースでは、Just Worksでペアリングしようとしている。
これが、NFC ForumのConnectionHandoverドキュメントも、BTSSPドキュメントも、「Just」ですら検索が引っかからない。
なので、NFCとしてはBluetoothの認証方式自体にはそれほど興味がないように見える。
まあ、そもそも「Bluetoothの認証」なので、NFCとしては言われた通りにデータを通信するだけだろう。

Just Works時に設定しているのは、MITM(Man In The Middle)の設定と(何も無し)、OOBの設定(何も無し)だ。
何にも無しの、なしなしだ。

ただ、基本的な設定となるNFC_BLE_PAIR_MSG_CONFIG_MSG_TYPEだが、サンプルソース中には定義がない。
これはシステムで持っているようだ。
パスでいえば、components\libraries\experimental_nfc\connection_handover\nfc_ble_pair_msg_config.hにある。
将来的なことはわからないが、今のところはライブラリに依存しているということらしい。
ただ、サンプルソースの中でifdefを見ているところからすると、将来的にはユーザ定義で選べるようになるのではないだろうか。

んで、これをキーワードにソースを検索すると、components\libraries\experimental_nfc\connection_handover\nfc_ble_pair_msg.cが出てきた。
これのndef_msgは、最初が0x91から始まっている。
そう、この数字は見慣れたNDEFなのだ。
0xD2とか0x91とか見ると落ち着くよね、ふふふ(変な人)。

---

LE_SHORTの場合、ndef_msg[]はこうなっている。

static uint8_t ndef_msg[NFC_BLE_PAIR_MSG_LEN] =
{
    0xD2,       //NDEF record header - TNF + Flags: MB=1b ME=1b CF=0b SR=1b IL=0b TNF=010b (MIME media-type)
    0x20,       //NDEF record header - Record Type Length = 32 octets
    0x00,       //MUST BE CHANGED! - NDEF record header - Payload Length = x octets (1 byte in size because SR=1b)
                //NDEF record header - ID Length missing since it is optional (IL=0b)
                //NDEF record header - Record(Payload) Type = 疎pplication/vnd.bluetooth.le.oob・
    0x61, 0x70, 0x70, 0x6C, 0x69, 0x63, 0x61, 0x74,
    0x69, 0x6F, 0x6E, 0x2F, 0x76, 0x6E, 0x64, 0x2E,
    0x62, 0x6C, 0x75, 0x65, 0x74, 0x6F, 0x6F, 0x74,
    0x68, 0x2E, 0x6C, 0x65, 0x2E, 0x6F, 0x6F, 0x62
                //NDEF record header - Payload ID missing since it is optional (IL=0b)
                //NDEF record payload - add here Bluetooth AD types
};

コメントに「section 4.3.2 of [NFC BTSSP]」とあるので参照すると、ようやくNDEFのメッセージがわかった。

また、nfc_ble_pair_msg_create()も同じソースに全部あるので、おおよその内容がわかる。
BTSSP v1.1のp.32からLEの場合のタグデータが載っているが、オフセットの35byte目以降をAdvertisingデータで埋めているのだろう。

そして、BTSSPの4.1章がNegotiated Handover、4.2がStatic Handoverだ。
じゃあ、4.3章はなんなのか？
NegotiatedがRequest RecordとConfiguration Recordを、Static HandoverがSelect MessageとConfiguration Recordを持っているのだが、4.3章ではConfiguration Recordしか持たない例になっている。
「Handover Selectorデバイスが1つの(例えばBLEのみ)にしか対応しないなら、Select Record無しもいけるよ」とあるので、まさにそれだろう。

---

じゃあ、標準じゃないやり方でペアリングしているわけではないということになるが、それならなぜNexus5ではダメだったのだろう？
タグの読込はできていたように見えるので、シーケンスのところがうまくいっていないのかもしれない。
うーん、そうなるとスニファでちゃんと見ないといかんのかなぁ。