最近っぽいC言語もやりたいが、それだけやってるわけにも行かない。
Eddystoneの続きもやろう。
前回は、Eddystoneのソースを新しくして、自分が作ったところをマージするとAdvertisingで何か出ているのがわかったところまでだった。
ただ、Advertisingで何のデータが出ているのか、いや、そもそも何をしようとしているサンプルなのかがわかっていない。
そういうわけで、Eddystoneの仕様を読んでいたのだが、新しく追加されているところを読んでいる途中で力尽きた。
先に、前回の最後に送信したAdvertisingがどういうデータなのか確認しておこう。
最初の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を読むか、と読み始めたのだが、だんだんと面倒になってきた。
作り方自体はそれほど面倒ではなく、
- あるルールで作った値をIDキーでAES128符号化してテンポラリキーを生成
- あるルールで作った値をテンポラリキーでAES128符号化して上位8バイトだけ使う
となっている。
そこまではまだよかったのだが、次に「EID configuration」という章が出てきて、リゾルバだの登録だのと言う言葉が現れ、だんだんと「BLE Peripheralがビーコンを勝手に出しておけばいいや」という話ではないということに気付いた。
Physical Webとかが関係しそうだ。
先はまだ長いな。
0 件のコメント:
コメントを投稿
コメントありがとうございます。
スパムかもしれない、と私が思ったら、
申し訳ないですが勝手に削除することもあります。
注: コメントを投稿できるのは、このブログのメンバーだけです。