Proximity Coupling Device。略してPCD。
なんのことやらって感じだが、NFCのR/Wはこう呼ばれている。
NFC Laboの用語集にも書いてあるのよ。
Android4.4のHCEは、Type4のカードエミュレーションらしい(まだ動かせてないので)。
私がよく使っている、RC-S620/SやRC-S370、あるいはNXPのPN533、PN532などでもカードエミュレーションできる。
そこで行っているのは、Type2やType3のカードエミュレーションだ。
先に言っておくと、これは私から見た範囲の話だ。
手近にあるカードが、Type2とType3しかないので、それ以外を調べていないのだ。
さて、RC-S620/S・・・というか、RC-S956チップやPN532チップでは、Type2のカードエミュレーションができる。
また、Type3のカードエミュレーションもできる。
「Type2」とおおざっぱに書いたが、実はいくつか細かな製品分岐がある。
それは、NFCID1のサイズだ。
Type2のNFCIDサイズは、Single、Double、Tripleの3種類がある。
それぞれ、4byte、7byte、10byteだ。
NXPのコマンド仕様書は無料でダウンロードできるので見てみると、Cascade、という言葉で説明してある。
まず、基本は4byte。
続きがあるなら、さらに続けて3byte。
まだあるなら、もう3byte。
4+3+3で10byte、というわけだ。
RC-S956, PN532系の場合、カードエミュレーションで実現できるNFCIDは、4byteまでだ。
しかも、先頭1byteが固定なので、実質は3byteが可変。SEL_RESも0x40固定。
ここが、NFCID2が8byteまるまる変更できるのと異なる点だ。
なんでもエミュレーションできるNFCID2に比べ、制約があるのだ。
まあ、そもそもNFCID1が4byteのやつは、すたれている[pdf]。
PCDでNFCID1が7byteとか10byteのって知らないので(私が知らんだけか)、もともと影響が少ない。
少ないというか、Type2の完全なエミュレーションをする機能がRC-S956やPN533にはない、というべきか。
これは私の知っている情報だけなので、企業でNDA契約とかすると、「実はこのオプションがありまして」なんてことはあるのかもしれない(ないと思うけど)。
が、これはあくまで、SONYやNXPのチップを使った場合だ。
自分で13.56MHzの送受信ができる装置を作れば、このあたりは暗号化がかかっているわけでもないので、ソフトだけで簡単に実現できそうだ。
製品のPCDチップがよい点は、NFCの取り決めをだいたいチップが吸収してくれているという点だ。
そんなに通信速度が速いわけでもないので、NFC周波数での送受信と少々の演算パワーさえあれば、このあたりは簡単に偽造できるのだ。
「そんなチップがあるのか？」といわれると知らないのだけど、無線のチップなんてたくさんあるんだから、探せばあるんじゃなかろうかね。
だから、だ。
NFCのセキュリティについてはやーやーいわれているのだ。
FeliCaが世界標準にならなかったのも関係ありそうだし、HCEでソフトからカードエミュレーションができるようになったといっても安心できないのも、そういう理由からだ。
しょせん、誰かが読めるように作ったデータは、どうにかすれば他人も読めるはずなのだ。
銀行のパスワードが、定期的に変更する＋ワンタイムパスワード、のような形式になってきているのも、パスワードは破られるのが当然という考え方が根底にあるんだと思う。
パスワードの組み合わせが1億通りあります！とかいっても、1発目で当たったら意味ないし。
脱線してしまったが、Type2のNFCIDは、Type3よりもまねしにくい、ということは説明できたんじゃなかろうか。
とりあえず、手を動かしてBLEを試してみたい。
なるべく手元にある環境でやれないものか。
調べたところでは、iOSとAndroidで可能らしい。
Androidは4.3からの対応で、「どの機種でも対応」というわけではないらしい。
幸い、Nexus7(2013)は対応しているようだ。
Nexus7(2012)のAndroid 4.4 Factory Imageがあったので「もしかしたら」と試してみたが、やはりだめなようだ。
ハードなのかドライバなのか知らんけど、まあ深追いすまい。
もちろん、iPad mini(iOS7)も、使える。あ、旧型の方ね(呼び方がわからん)。
Nexus7(2013)でやるか、旧iPad miniでやるか。
まあ、両方やるか。
Android4.3のサンプルに「BluetoothLeGatt」というサンプルがあるようなので、動かしてみる。
起動させると、PaSoRi RC-S390が出てきた。
まだペアリングさせていないので、これはペアリングさせるときも出てくる端末情報を出しているだけか。
このとき、ペアリングしているのはiPad miniとだったのだが、デバイスの有無の検索はいつでもできるのかな？
こういう基礎的なところがわかっていない・・・。
PaSoRiをタップすると、こんな画面が出てくる。
あれ、コネクトしてる？？
スクリーンショットを撮る前は切断状態だったのだが・・・。
あ、今見たら接続していた。
とはいえ、これ以上は何もできないようだ。
ここから先はペアリングがいるということか。
今度は、SettingsアプリのBluetooth設定からデバイスの検索を行った。
・・・出てこない。
そう、説明書によると、ペアリングを行うときにはPaSoRiのボタンを5秒以上押す、となっているのだ。
まず、iPad miniの設定画面からPaSoRiを切断。
念のためこの状態でNexus7から検索をかけ、やはり表示されないことを確認した。
では、PaSoRiのボタンを長押しして、ペアリング状態にしよう・・・と長押ししたのだが、どうもこの場合には「電源断」になるようだ。
気を取り直してもう一度長押しし、青LEDが点滅する状態にする。
そしてNexus7から検索すると、今度は出てきた。
PaSoRiをタップすると、「ペアとして設定中・・・」が表示されて・・・進まない。
あれ、さっきはペアリングできたのに。。。
気を取り直して、Bluetoothを無効にして、もう一度有効にしてからPaSoRiをタップすると、ペアリングのPIN入力画面が表示された。
やれやれ。
ここでPaSoRiに貼ってある番号を入力すると、ペアリングができた。
再度サンプルに戻って、CONNECTをタップすると、情報が表示された。
うーん、iPad miniのLightBlueで見たときより、初めの2サービスが増えている。
あまりにもデフォルト過ぎるサービスか何かで表示させなかったのだろうか？
ともかく、Nexus7(2013)+Android4.4ではBLEが使えることがわかった(4.3からだろうけど)。
Android 4.4のHCE(Host Card Emulation)がどうしても気になる。
SDK for NFC Starter Kitのサンプルでは、そもそもどうやって動くのかがわからない。
もっと何か、解析的なツールはないものか・・・。
どうやら、NDEF WriterがType4Aに対応しているらしい。
よし、とやってみたが・・・まあ、動かんわな。
最初は「タグが正しくない」みたいなエラーだったのだけど、何度かやるとPaSoRiが応答しないというようなメッセージになってしまった。
うーむ。
よくわからないので、自己診断をしてみよう。
PaSoRiのドライバには、診断ツールも入っているのだ。
やってみると、特に問題は無いらしい。
よかった。
せっかくなので、診断ログを見てみると・・・ATRという文字があった。
確かこれは、ATtRibuteとかそんなのの略だったよな？
これが返ってくるのはカードをPaSoRiにかざしたまま診断したときだ。
つまり、これはカードを読んだ結果らしい。
Nexus7をかざすと、ちゃんと成功で返ってきている。
ということは、やはりNexus7を何らかのタグとしてはわかってくれているみたいだ。
ATRは、こんな数字だった。
3B8F8001804F0CA00000030611FFDF0000000059
なんか、わからんね。
解析しよう。
http://en.wikipedia.org/wiki/Answer_to_reset
ここと、Interface誌2012年4月号のPC/SC資料を読みながら解析した。
途中から、PC/SCの資料がないとわからなかったので、そこはpcsc3_v2.01.09_sup.pdfを読んだ。
3B:TS
Direct Convention
8F:T0
8:TD1, TC1, TB1, TA1の順。TD1のみ有り。
F:historical bytes。15バイト。
80:TD1
8:TD2, TC2, TB2, TA2の順。TD2のみ有り。
0:T=0(character-oriented)
T=0...character-oriented protocol
T=1...block-oriented protocol
01:TD2
0:TD3, TC3, TB3, TA3の順。どれも無し。
1:T=1(block-oriented)
804F0CA00000030611FFDF00000000:historical bytes
80:カテゴリ・インジケータ
4F:アプリケーション識別子の存在インジケータ
0C:長さ
A000000306:RID(この値は、PC/SC WorkgroupのAIDらしい)
11:SS(pcsc3_v2_01_08_sup.pdfに表がある)
FeliCa
FFDF:NN
RFU
00000000:RFU
59:TCK
チェックサムみたいなやつ。
メモ書きをそのまま貼り付けた。
よくわからないけど、FeliCaと見ているのか？
でも、その次のNNは変な値が入っている。PC/SCにはちゃんとFeliCaの定義値があるというのに。
ちなみに、MIFARE Ultralight-Cをかざした場合はこうなった。
03:SS
ISO 14443A part3
003A:NN
MIFARE Ultralight C
うん、SSもNNもあってる。
ちゃんとFeliCaをかざすと、診断結果はこうなる。
カードとの通信(PC/SC): OK
ATR : 3B8F8001804F0CA00000030611003B0000000042
Target Name : FeliCa
Target Type : FeliCa
Baud Rate : PCD->PICC : 424, PICC->PCD : 424
これがNexus7をかざすと、こうなる。
カードとの通信(PC/SC->FeliCa): OK
うーむ。
これはAndroid BeamをOFFにしたときの値。
Android BeamをONにすると、こうなる。
カードとの通信(PC/SC): OK
ATR : 3B8F8001804F0CA00000030611FFDF0000000059
Target Name : FeliCa NFC-DEP Target
Target Type : FeliCa(NFC-DEP Target)
Baud Rate : PCD->PICC : 424, PICC->PCD : 424
そう、さっきはこの値を解析したのだな。
ログにも出ているが、DEPでターゲット側になったときの情報なのだろう。
NNもRFUな値になっているが、実はNFC-DEPの値かもしれんな。
じゃあ・・・そうじゃないときのATRは取れてないということになる。
と何度か繰り返すと、Android BeamをOFFにしていてもNFC-DEP Targetになってることがあった。
よくわからんので、Nexus7(2012)をかざすと、NFC-DEP Targetになった。
もう、さっぱりわからん・・・。
わからんシリーズだ。
Nexus7(2013)のAndroid 4.4 Factory ImageがGoogleから出ていたので、インストールした。
そうすると、設定メニューに「タップ＆ペイ」という項目が増えていた。
なんとなく、HCEできそうだ！
SDK for NFC Starter Kitのサンプルに、Type4Tag.exeというものがあり、なんとなくType4を読んでくれそうだ。
試してみたが・・・よくわからん。
Type4Tag.exeは、PaSoRiになにも置いていないと「タグを置け」と出るし、Type2とかのタグを置くと「それは違う」と出してくれる。
Nexus7(2012)をかざしてみたのだが、「タグを置け」の方だった。
Nexus7(2013)をかざすと「それは違う」と出てくる。
「それは違う」というのは私の言葉で、正確には「Failed to access to the tag.」と出る。
アクセスに失敗した、というわけだ。
そういうことからすると、なんらかのカードエミュレーションをしているように見えるのだが・・・。
何を気にしているかというと、HCEのサンプルアプリなどを動かさなくても動作が変わらないからだ。
HCEって、アプリがなくても何かしら動いているのかいな？
それにしては、logcatに何も出てこないのだが・・・。
もう少し、「何か来たけどAIDが違うのではじきました」とか出てくれれば安心なのだが。
Android Beamでターゲットになったときが反応しているのかと思って、Beamだけ止めてみたのだが、やはり変わらない。
スクリーンがロック状態になると、「タグを置け」になる。
裏で動くんなら、ロック状態でも動いてほしい気はするのだが・・・。
Type4 Tagが手元にないので、Type4Tag.exeがどう動くのかわかっていないというのもよろしくない。
かといって、手軽に買えるところもないしなあ、うーむ。
よくわからん、という状況で、代案が出てこない私であった。
RC-S390が、iOSで使えるPaSoRiとして出ている。
が、開発キットは一般向けではないとのこと(電脳羊さんより)。
むー、それは仕方ない。
「あるものは使いなさい、ないものは作りなさい」の世代としては、作らざるを得ない。
手持ちでできるとするなら、こんな感じか？
いや・・・これはちょっとないな。
せっかくBLEで消費電力を抑えようとしているのに、RC-S370だとUSBなので、5Vもいるじゃないか。
RC-S620/SならUARTだし、sleepするようなコマンドもあるのでよいかもしれんが、それでもきついか。
(私のイメージだと、UARTもまだ電気を食う気がしている。)
そういえば、I2C版のが展示会で出てたという記事を見たことがあったけど、どうなったんだろう？
個人的にはSPIの方がデバッグしやすくて好きなんだけど、トラブったりしなければ配線が楽だ。
そういうことを考え出すと、やはり作るのは難しいなあ。
| Characteristicについて、もう少し調べておこう。 LightBlueで見ると、Characteristicのアクセス方法がいくつかあるのがわかった。
|
ざっと説明を読んだところだと、ClientがServerに対して要求をかけるシーケンスになっていた。
ClientがRead要求をかけると、Serverから読んだ値が返ってくる、というような。
ReadとWriteはわかるとして、NotifyとIndicateはなんだ？
Notifyは、ServerからClientへCharacteristic ValueをNotifyする手段のようだ。
Indicateも、ServerからClientへCharacteristic ValueをIndicateする手段のようだ。
Notifyは通知、Indicateは指示。
つまり、Notifyは「こんな値です」と教える手段で、Indicateは「値を教えろ」と要求する手段ということなのだろう。
RC-S390はPeripheralで、iPad miniがCentralという立ち位置なのだが、CharacteristicのアクセスとしてはRC-S390が「Server」で、iPad miniが「Client」ということになりそうだ。
忘れず、続けよう。
BLEの構成は、こんな感じみたいだ。
仕様として、物理層との接続にHCIを使うようになっているとかなんとか。
ワンチップでBLEを実現したマイコンがあれば、あんまり関係ないかも。
うちには、Nexus7(2013)とiPad miniでBLEが使える。
なんでも、Androidは親だけで、iOSは親にも子にもなれるとか。
ならば、iOSで子を作って、Androidでそれを見てみるのがいいのかもしれん。
が、まだ知識が浅いので、BLEの子製品と、アプリでBLEのアクセスができるものがあるので、それでやってみよう。
うちにあるBLEの子製品は、RC-S390だけなので、これを見る。
iOSにLightBlueというアプリがあり、これがいいそうだ。
使い方はよくわからないけど、デバイスを見つけて、サービスを見て、そのキャラクタリスティックを見る、という扱いのようだ。
デバイスとしては、PaSoRiが1つ見える。
サービスは2つあり、1つは「Device Information」、もう一つは数字だけしか出てこない。
このDevice Informationサービスは、標準サービス？みたいなもののようで、略称は「DIS」らしい。
ちなみに、上の図は雑誌Interfaceを読みながら描いたのだが、さっきのリンク先にも図があるな。
少し違うけど、まあ深くは考えまい。
さて、DISの技術書があるので見てみよう。
これを読むと、DISには8つのCharacteristicがあることになっている。
RC-S390には4つだけCharacteristicsがあった。ということは、全部載せないといけないというものでもないのか？
でもPDFには「C.1 (Mandatory to support at least one)」となっているから、載ってないといかんのではないだろうか。
あるいは「この中の最低1つは」というat least oneなのかしら。
英語が弱いのが哀しい・・・。
でも、後者の意味なら、表としては書き方がよくない。
8つのCharacteristicの１つ１つに「C.1」と書くのではなく、セルを1つに結合してから書かないとわからん。
表の上にある英文に「one or more of the characteristics」とあるから、やっぱり後者なのか。
気を取り直して。
LightBlueには、Device Informationサービスと一緒に0x180AというUUIDが書かれていた。
この数字は「Bluetooth Core Specification v4.0」で規定しているそうだ。
ページがあった。割り当てられた数字のページがあるのはありがたい。
クリックすると、その詳細が見られた。
Readが"Mandatory"になっとるやん・・・。
いや、これは「Characteristicとして存在するなら、ReadはMandatoryだよ」という意味なんだろう。
きっとそうなんだ。
このあたりは、秘匿する情報ではないようなので、RC-S390の値を載せておこう。
まあ、特にどうということのない文字列だ。
そういえばiPad miniとペアリングしたとき、名前が「PaSoRi」と出てきた。
これは、Device Informationサービスから取得した名前ではないということだ。
ペアリングしないと使えないから、ペアリング作業の前に検索したら見える名前なんだろう。
深入りすまい。
先ほどサービスが2つ、と書いたが、そのもう1つの方がRC-S390を扱うためのサービスなのだろう。
この中には、7つのCharacteristicがある。
サービスが標準じゃないので、このCharacteristicも標準じゃない。
つまり、なんだかわからない、ということだ。
ははは。
これで終わっては寂しいので、もう少しCharacteristicについて調べましょうかね。
frameworks/base/core/res/res/drawable-nodpi/platlogo.pngAndroid4.4 のHCEは、まだうちでは動かせていない。
情報だけで妄想しよう。
ISO/IEC 7816-4、というのが、一番上のプロトコルスタックになっている。
通信関係は詳しくないのだが、「プロトコルスタック」というのは、一番上の層が素のデータに近く、下の層に行くにしたがって層のしきたりでデータを包んでいく、というイメージだ。
だからプロトコルスタックが薄い方がデータサイズなどは小さくなるけど、別に好きでそうしているわけではなく、汎用性とか安全性とかを考えた末にスタックが積まれていくものだと思っている。
なので、HCEがユーザに取りあえず見えるのはISO/IEC 7816-4だろう。
ICカードというかメモリカードというか、その辺って昔からアクセスのルールがあったように思う。
10年くらい前にSIMのメモリアクセスを調べたときに、EFなんとかってのがあるのを見てそう思ったのだ。
まあ、それはともかくとして、ISO/IEC 7816-4というのは「一般的な」アクセス方式というかプロトコルらしい。
NFCだと、Type4が相当するようだ。
HCEが標準でサポートしているのはNFC-Aなので、TechnologyがNFC-A、PlatformがType4となると、該当するのはType4Aとなる(Type4Bというのもあるが、これはNFC-B)。
持ってないけど、Type4Aは、タグで言えばMIFARE DESFireだろう。
私にとって、DESFireはFeliCa Standardと同じくらいの位置づけだと思っている(勝手な思いだが)。
MIFARE Ultralight C ----- FeliCa Lite(/S)
MIFARE DESFire ----- FeliCa Standard
こんなイメージがある。
Ultralight CもLiteも、決済系に使うにはセキュリティが弱いと思っている。
Ultralight Cはセキュアなアクセスができるけど(ドキュメントは申請が必要なので、見たことない)、無線区間は平文なんじゃないか・・・となんとなく思っている。
これはまったく根拠がないので、間違っていたら教えてほしいところだ。
私がそう思う根拠は、「それにしてはタグの値段が安い」というだけのことだ。
Liteは、少なくとも無線区間は平文だ。
領域をRead Onlyにすることはできるけど、セキュアなアクセスはできない。
Lite/Sになると双方向認証っぽいものがあるのだけど、どちらにしても無線区間は平文だ。
傍受すれば解読はたやすい。
DESFireになると、全然わからない。
使ったことないし、見たこともない。
しかし、NFC-Aで決済と言えばDESFire、というイメージがある。
同じく、FeliCaも決済系ならばStandardだ。
これは、FeliCa Standardのファイルシステムが、フォルダを降りるごとに鍵が必要だったりするためだと思う(そういうアクセスは自分でできないので、読んだ情報だけ)。
交通関係はスピードが要求されるので(特に東京か)、そのフォルダを一気に駆け下りる縮退鍵なんてものもあり、いろいろ考慮されている。
まあ、そのせいか、「悪い人じゃないんだけど、お付き合いするにはちょっと・・・」という感じで、あまり世界的には広がっていない。
さて、HCEだが、読んでる感じからすると、Type4Aっぽいと思う。
Type4Aは、カードの検出まで終わったら、あとはISO-DEPを使ってデータ交換するらしい。
そう、AndroidではAPIが提供されていたものの、なんだかよくわからないあいつだ。
このISO-DEPについては、PN532のドキュメントにある情報がわかりやすいのではないか。
もちろん、PN544やPN65、MFCが持つような機能は、NFC R/Wチップが持つ機能とは異なる。
が、規格として決まっているところについては読みやすいんじゃなかろうかね。
私もそのうち読みたいものだ。