2016/05/08

[nrf]nRF5 SDK for Eddystoneは動くのか? (7)

最近っぽいC言語もやりたいが、それだけやってるわけにも行かない。
Eddystoneの続きもやろう。


前回は、Eddystoneのソースを新しくして、自分が作ったところをマージするとAdvertisingで何か出ているのがわかったところまでだった。

ただ、Advertisingで何のデータが出ているのか、いや、そもそも何をしようとしているサンプルなのかがわかっていない。

そういうわけで、Eddystoneの仕様を読んでいたのだが、新しく追加されているところを読んでいる途中で力尽きた。


先に、前回の最後に送信したAdvertisingがどういうデータなのか確認しておこう。

image

最初の3バイトが<<Flags>>、次の4バイトが<<Complete List>>、次の18バイトは<<Service Data>>なのだが、FrameTypeが0x00なのでEddystone-UIDと思われる。

まあ、<<Service Data>>の中身を設定しないままになったEddystone-URL、という可能性もなくはないが、それならデータ長はもっと短くてよいはず。

なので、たぶんUIDの初期値がどうなっているかを見ていけば、とりあえずはまともなデータになるだろう。
でも、これだけだったらiBeaconサンプルと同じで、固定データを流すのとあまり変わらないので、面白味がない。


続いて、Eddystoneの新しい仕様。

 

新しく追加されたのは、Ephemeral-IDのところ。
略すとEIDなのだが、これだとEddystone-IDの略と思われても仕方が無いと思う。
EIDの仕様が関係するのは、以下の2箇所。

  • フレームタイプが「TLM」で、それがEncrypted TLMの場合
  • フレームタイプが「EID」の場合

 

Encrypted TLM(以下、ETLM)は、今までのTLM(Unencrypted TLM)のデータをAES-EAXで符号化したデータ+αをAdvertisingする。
AESは128とか256みたいなデータ長がついたものしか知らなかったのだが、EAXというモードがあるらしい。
詳しくないのでEAXのことは調べないが、Eddystone-EIDで使うのと同じようなパラメータを使ってnonce値を生成し、TLMデータをAES-EAXで符号化する、ということになっている。

 

ではEddystone-EIDを読むか、と読み始めたのだが、だんだんと面倒になってきた。
作り方自体はそれほど面倒ではなく、

  1. あるルールで作った値をIDキーでAES128符号化してテンポラリキーを生成
  2. あるルールで作った値をテンポラリキーでAES128符号化して上位8バイトだけ使う

となっている。

そこまではまだよかったのだが、次に「EID configuration」という章が出てきて、リゾルバだの登録だのと言う言葉が現れ、だんだんと「BLE Peripheralがビーコンを勝手に出しておけばいいや」という話ではないということに気付いた。
Physical Webとかが関係しそうだ。

先はまだ長いな。

0 件のコメント:

コメントを投稿

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