2012/08/25

今月のNFC Forum(8月)

というタイトルにすると毎月書いているように見えるが、そんなことはない。


ドキュメント追加

NFCForum-TS-Analog-1.0というドキュメントが非メンバーでも見えるようになりました。
7月だったらしいけど、気付かんかった。。。

アンテナについてなどが書いてあるみたいです。
私にはあまり縁がなさそうなので、ダウンロードしてそのままになりそう。。。


ドキュメント削除

削除というか、なんというか。
RTDのGeneric Controlがなくなりました。


認証製品

全部で7製品が認証されてます。
8月は1台追加になったのかな。


こんなところですかね。

最近作ったもの

ここ最近の成果物を紹介しよう。
といっても、記事に書いていたので目新しくはないがね。

SNEP initiator

Inteface誌2012年6月号付録のFM3基板に、紹介されていたTOPPERS/ASP上で動くSNEP(initiator)のソフト。
github : toppers_rcs620s_sample

RC-S620/Sと、I2CのLCD画面をつないでいる。
回路図も置いているので、部品があればすぐできると思う。
最近、ようやく入れ物に入れた。
ダイソーで買ってきた弁当箱だ。
液晶が見えるように透明な方がいいかと思ったが、RC-S620/Sが思ったよりも目立つので、不透明なやつにすればよかった。
紙を置いてごまかしたが、チープ感がかえって高まってしまった。
image

アプリは、後で紹介するNFCライブラリを呼んでいるだけ。
I2Cライブラリはもらい物を変更しただけなので、そんなに大変じゃなかったと思う。

動作は単純で、定期的にNFC-A, B, Fの順でポーリングし、カードの種類をLCDに表示するだけ。
カードの種類がTPE(NFC Transport Protocol Equipment。DEP実装端末)でNFC-AかFだったらSNEP(initiator)し、NDEF Textで"hiro99ma"と送信する。
nfcpyでしか動作確認してない。

NFCライブラリ(RC-S956)

RC-S956用になると思うが、NFCライブラリを作った。
ときどき作ってるが、今回はCで書いた。
github : libhknfcrw_c
最初はC++で作っていたけど、TOPPERS/ASPがC++でいけるのか不安だったし、CにしておけばC++でもなんとかなるってことで、置き換えた。
まだ作りは甘いので、改善していこう。
バイナリ提供して、RC-S956へのアクセスと汎用関数を実装すればよいような形にしたつもりなので、UARTでもUSBでもいけるんじゃないかなあ、と思う。
もちろん、RC-S956のドキュメントなんて持っていないので、動作は無保証。
個人でお楽しみください、というレベルだ。

NFCライブラリ(Arduino ?)

文字が小さくなったのは、まったく動かしていないからだ(そして多分動かない)。
ビルドしかしてないArduino版NFCライブラリ
ネットを見ながら作ってみたけど、Arduinoのライブラリってclassなんだねぇ。
なので、C++版をベースに作った。
作ったけど、static classなのだ。
初期のC++版は普通にインスタンスを作ってやるタイプだったけど、シングルトンになって、最後はstaticになった。
namespaceに置き換えようとしたけど、もうCでいいやん、というのがC版ライブラリなのだな。
なんで動かしていないかというと、Arduinoを持ってないから。
買えばいいやん、と思われそうだが、物を増やしたくないのだ。

こんなところか。
近々、福岡NFC勉強会が行われる予定なのでSNEPの動作確認をしたい。
したいのだが、比が近づくにつれて暗雲が立ちこめている。。。
この状況だと前日になるまで確定しませんな。
前回は危険そうだったので早めにキャンセルしたが、10月は開催されても参加できないと思うので、今回は粘ってみよう。
まあ、粘ってなんとかなるかというと、そういうものでもないんだけどね。

2012/08/06

次回のFukuoka NFC Hack 4は9月8日とのこと

タイトルだけでもう書くことがなくなってしまった。。
とにかく、9月8日ということでした。
10時半開始予定ですよ。

まどろみさんがSNEPの話をされるそうなので、ネタがないなぁ。
まあ、同じSNEPネタでも内容が重なることはなかろう、と気楽にしている。
とりあえずスライドだけは作ったので、あとは本当に参加するかどうかだな。
スケジュールとしては楽になっていないといかんのだが、状況があまり思わしくない。
うぅ、明日仕事行きたくないなぁ。。。
と、ぼやいているうちは、まだいいのだろう。
スライドがひょこっとslideshareに上がったら「ああ、行けなさそうなんだな」と思ってくだされ(ちゃんとキャンセルもするけど)。

NFCって、何か作らないと飽きるのよねぇ。
私は調査を中心にやってるけど、たぶんそれは変な人で、普通は何か作るんだと思う。
でも、NFCの遊び物を持ってないので、あまり作る気にならない。
ソフト屋さんとしては、ハードを勉強して、何か作るってのがいいんだろうなぁ。
プルアップ抵抗で困り果てるくらいだから、ちょっと敷居が高い・・・。

2012/08/05

[os]割込が発生すれど、呼ばれず

笛吹けど踊らず、みたいな。

サンプルソースでI2Cが動くことがわかったので、TOPPERS/ASPで動かそうとしている。
よく考えると、TOPPERSで割り込み処理を書くのは初めてだ。

2011年4月号を見つつ、cfgファイルにATT_ISRとCFG_INTを書く。
コンパイルすると、kernel_cfg.cにハンドラが展開されている。
使いたかったのは、SOT1_2の割込になるようなので、No.26になっていた。

MFSだけかもしれんが、割込は「送信割込」と「ステータス割込」が確認できる。
No.26なら、IRQ10MONレジスタになる。

 

で、やってみると・・・ハンドラが呼ばれない・・・。


IBCR.INTは1になっているので、割り込み要因は発生している。
ロジアナ波形を見ても、ACKのとこまで出力されている。
IRQ10MONは、0x02。つまりステータス割込要求あり。
ここまで揃ってるのに、ハンドラが呼ばれないということは、NVICか。

あら、割込イネーブルレジスタが0のままだわ。
ena_int()しているのに・・・。

とデバッガで追うと、理由がわかった。
ATT_INI()で指定した初期化関数の中でena_int()していたのだけど、コンテキストがタスクじゃないからはじかれていたのだ。
エラーチェックしていればわかったんだけど、省略していたのよ。。。

 

タスクが始まってからena_int()することで、無事に動くようになりました。
めでたしめでたし。

さて、ようやくここからμITRONっぽいことをやり始めるとしよう。
whileでぐるぐる待つところなんかをそれっぽく仕立てたいものだ。

[fm3]I2Cが動かんのはプルアップ抵抗の値か

FM3基板のI2C。
サンプルドライバはFRAMアクセスするようになっているので、動かしてみた。

・・・動く。
割込がちゃんと入ってくるし、ACKも確認できている。

FRAMは、SOT1_0 / SCK1_0を使っている。
じゃあ、SOT1_2 / SCK1_2に差し替えればとりあえず動くのかな?

・・・動かない。
割込が入ってこない。
ソフトは同じで、変更したのはポートだけだ。

では、未接続のSOT6_1 / SCK6_1にしてみたら?
・・・割込が入ってきた。
未接続だからエラーなんだけど、割込は来る。

ではでは、SOT6_1/SCK6_1にLCDを接続すると?
・・・割込が入ってこない。

 

つまり、接続する相手のせいで割込が入ってこないようになっているのだ。
うーん、その可能性は考えてなかったなぁ。


LCDの型番で検索
うーん、みんな22kΩくらいのプルアップ抵抗だなぁ。
ストロベリーリナックスさんのページには、20kΩ以上で100kΩでもいい、くらいなことを書いていたように思う。
なので47kΩのを使っていたのだが・・・。

 

私も20kΩくらいの抵抗を探し出し、つないだ。

image

出るやん・・・。
プルアップ抵抗って、そんな微妙なものなのか・・・。

では、設定をやり直して。。。

image

わーい。
素直に嬉しい。

プルアップ抵抗なんてエッジがなまらない程度にしておけばいいんだろうと思ってたけど、神秘の深淵を除いた気持ちである(おおげさ)。

[fm3]まだI2Cがうまくいかん

私はI2Cですら動かせないのか・・・と思ったが、まあいつものことだ。
とにかく、まだ動いていない。

 

今はSOT1_2 / SCK1_2を使っているが、ポートを変えたら動いたりせんだろうか、とSOT6_1 / SCK6_1にしてみたが、状況は変わらず。

image

EPFR07でリロケートもしてる。
ロジアナ自体が悪さを?と思って外してみたが、そんなわけでもなさそうだ。
皆目見当が付かん。


思いつくことを、つらつら書いていたら、何か浮かぶかもしれない。

 

EIBCRレジスタがあれば、手動でSDA/SCLをぱたぱたさせられそうなのだが、FM3基板のFM3はTYPE2なのでレジスタがない。

 

富士通のサンプルでは、「ch0はマイクロコントローラの仕様で使用できない」と書かれている。
I2Cだけみたいだけど、そんなのどこにも書いてないなぁ。

 

MFSのブロック図がないので、何が関わっているのかがよくわからない。
仕方ないので、FR60のドキュメントを見てみた。
同じ富士通のだから、似てるんじゃなかろうか。

IDARというレジスタが、TDRレジスタに相当するみたいだ。
FR60はダブルバッファになってるらしく、BusBusyのときはシリアル転送用のレジスタに、そうでないときは内部転送レジスタにロードされる、とある(ブロック図では読み取れん)。
シフトレジスタがあるだろうから、そこの図が見たかったのだが・・・ないのか。

なんとなくだけど、クロックさえ生成すればデータが出ていきそうな感じだ。
ってことは、クロック生成できていないか、供給されていないということ?

マルチファンクションシリアルは、APB2バスに載っている。
APB2バスクロックは、PCLK2らしい。

そういえば、TOPPERS/ASPの環境はどういうクロックになってるんだろうか?


target_initialize()を見ると、

  • ベースクロック : 1分周
  • APB0 : 1分周
  • APB1 : 2分周
  • APB2 : 2分周

のようだ。
PCLK2の出力許可もしているので、クロック供給されていないということはない。
まあ、されてなければRC-S620/Sの制御すらできなかったはずだよな。


ペリフェラルマニュアルの「I/Oポート」も大切そうだ。
表2-2に、GPIOとして使うか周辺機器として使うかと、影響するレジスタが記載されている。
I2Cだから、オープンドレインで入出力。
影響するのは、PFRとPZRらしいから、やはりPZRは設定しておこう。

ADEとかは何もしてないから0だろうと思っているが・・・どうだろう。
心配だから見ておこう。

  • ADE : AN31~AN00だから関係なさそう。でも、0にしておくか。
  • SPSR : デフォルトでUSBは0だし、外部クロックのピンはそのままがいいだろう。
  • DAE : デフォルトで0だから、いいだろう。
  • VEx : LCDCC3レジスタでいいのかな? PICTLを1にして、残りを0にすればいいのか。
  • COMx : LCDC_COMENレジスタでいいのかな? デフォルトでGPIOだからいいだろう。
  • SEGx : LCDC_SEGENxレジスタでいいのかな? デフォルトでGPIOだからいいだろう。

あー、めんどくさい。。
そして変化無し。。。。。
そうだよなぁ、そんなので動かないなら、スタートコンディションすら生成されないよなぁ。


仕方ないから、オリジナルでFRAMアクセスして波形を取ってみるか。
でも、ポートをつかむような道具を持ってないので、ちょっと一苦労だ。
まあ、波形は取らなくても、動くことが確認できればいいか。

2012/08/04

[fm3]I2Cがうまくいかん

Interface誌のFM3基板を使っているが、I2Cがうまくいかん。

一から書く気力がないので、Interface誌2012年7月号のドライバiic.c/hをそのままTOPPERS/ASPに載せ替え(というほどでもないか)をした。

割込が入らないとか何とかいう以前に、TDRレジスタに値を書き込んでMSS=1にしても、スタートコンディションになるだけでSDA/SCLが動かないのだ。

通信マクロの説明に従ってるのだが・・・

  • TDR書き込み
  • MSS=1
  • BB=1になった
  • ACT=1になった
  • TRX=1になった
  • FBT=1になった
  • TDRE=0になった(すぐ1になるけど)
  • SDA=Lになった
  • ちょっとしてSCL=Lになった

ここまでいくのに、SDA/SCLともにLになりっぱなしなのだ・・・。


今回使っているのは、SOT1_2とSCL1_2。
FM3基板でいえば、CN2の31ピンと32ピン。
ch1は、FIFOなし。
プルアップ抵抗は、47kΩ。
動作クロックは変更していないので、144MHzでAPB1, APB2は72MHz。
APB1が40MHzを超えるならばノイズフィルタを設定した方がいいらしいが、出力だけなら気にしなくてもいいかと思い、設定してない。
DMAも使っていない。

情報はこれくらいか。

TDRに書き込む前は、TDRE=1なので、送信データレジスタへ書き込める条件は整っている。
MSS=1にする際は、同時にINTEとINTも1にしている。読み取ると、INTは0だけど、これは割込条件が整っていないから0なだけだろう(INTへの1書き込みは、意味がないのだな)。
割込が入らないのは、データを送信できていないから。


TDR書き込み直後のMFS関連のレジスタ値

  • SMR : 0x8C
  • IBCR : 0x00
  • IBSR : 0x00
  • SSR : 0x01
  • BGR0 : 0xB3
  • BGR1 : 0x00
  • ISBA : 0x00
  • ISMK : 0xFF

MSS=1書き込み直後

  • SMR : 0x8C(MD=100/RIE=1/TIE=1)
  • IBCR : 0xC4(MSS=1/ACT=1/INTE=1)
  • IBSR : 0x91(FBT=1/TRX=1/BB=1)
  • SSR : 0x03(TDRE=1/TBI=1)
  • BGR0 : 0xB3
  • BGR1 : 0x00
  • ISBA : 0x00
  • ISMK : 0xFF

このまま放置しても、レジスタ値に変化なしだ。
うーむ。
FBT=1のままってことは、まだ送信できていないと思っているのだろう。
TRX=1だから、送信ってことはわかってるし。
BB=1なので、送受信しようとはしているようだ。
TDREも0から1になっているので、シフトレジスタへ載ってるんだと思う。

 

ちなみにオリジナルは、RIEとTIEは0だ。
まあ、まだ割込が発生する以前の問題だから、あとで考えよう。

PZRレジスタでHiZにしてやらんといかんのか?とやってみたが、変わりなし。
なんか全然わからんぞ-。

 

メモ代わりに、MSS=1後のレジスタを載せておこう。。。

image

2012/08/03

[nfc]P2Pの利点は?

私の知る範囲で、になるが、NFCのP2P、LLCPとかSNEPが使えるのはAndroidしか知らない。
BlackBerryやNokia端末も使えそうだけど、情報が不足している。


AndroidのNFC-P2Pは、Android Beamになる。
最近になってAndroid Beamも拡張され、Wi-FiとかBluetoothとかを併用するタイプになりつつあるように見える。

Bluetoothなんて、日本では「何に使うの?」くらいだったけど、今ではけっこうな市民権を得たのだろうか。
こういうのは、携帯電話をめったに使わない私にはわからないことなんだよなぁ。


まあ、それは置くとしよう。
私が気にしているのは、NFCのP2Pってどういう用途が残っているんだろうか、ということだ。
なんとなく「カードエミュレーションはちょっとイヤだから、P2Pでちょろっと会話して、あとは高速回線ね」という用途にしようとしてるんじゃないかな、という気がする。
というのも、SNEPとかLLCPって、NFCでありがちな通信の途切れを考慮してないように思うからだ。
数秒間向かい合わせるならば、なんらかの通信障害が発生する可能性は高い。
高いので、P2Pでは再送なんかを考慮するんだろうと思ったけれど、LLCPやSNEPを見る限りではそういうのがない。
ということは、通信が途切れたら終わり…というよりも、通信が途切れるほど長い時間は通信しないよ、という意図があるように見える。

カードエミュレーションだと、R/W v.s. カード、という構図が静的に決まるけれども、LLCPであればそうならないので、端末間は基本的にSNEPを使おうか、ということを考えていそうだ。


どういう形でもいいんだけど、NFCは携帯電話と相性はいいのだが、携帯電話だけのものではないと思っている。
なので、どういうサービスがあってもいいんだけど、NFC=携帯電話になるのだったら、関与したくないところだなぁ。

[nfc]ログ解析はなかなか楽しい

「今日のパントは『ログ解析』! 面白そう!」
というわけで、NFCでなんか実装したときの動作確認は、ログ解析になる。
実装するときは、まずPC上でプロトコルの流れがちゃんとできているかどうかを確認し、最後に実機へ移植するような手順にしている。
いきなり実機で試すのは、準備運動無しで海に飛び込むようなものだ。

問題1:
次のログ解析をしなさい(RC-S620/S)。
[W]はRC-S620/Sが送信するログ、[R]は受信したログ。
また、受信ログはACKを省略し、実データのみを表示させている。
------------
[W]00
[W]00
[W]ff
[W]03
[W]fd
[W]d4
[W]18
[W]01
[W]13
[W]00
------------
------------
[R]d5
[R]19
------------


回答:
初級問題です。
送信データから解析してもいいですが、受信データを先に見た方が早いでしょう。
「d5 19」ということは、送信データは「d4 18」になります。
それをキーワードにして送信データを見ると、「d4 18」が出てくるのがわかります。
送信データサイズは、通常d4の2つ前に載っているので、ここでは3byte。
つまり「d4 18 01」を送信していることになります。
0x18はResetコマンド。0x01はよくわからんけど、コマンドリファレンスマニュアルで指定された値、ということがわかります。

問題2:
------------
[W]00
[W]00
[W]ff
[W]35
[W]cb
[W]d4
[W]8c
[W]02
[W]00
[W]04
[W]2d
[W]cf
[W]46
[W]40
[W]01
[W]fe
[W]29
[W]04
[W]b4
[W]78
[W]d8
[W]68
[W]ff
[W]ff
[W]ff
[W]ff
[W]ff
[W]ff
[W]ff
[W]ff
[W]ff
[W]ff
[W]01
[W]fe
[W]29
[W]04
[W]b4
[W]78
[W]d8
[W]68
[W]00
[W]00
[W]46
[W]66
[W]6d
[W]01
[W]01
[W]10
[W]03
[W]02
[W]00
[W]11
[W]04
[W]01
[W]c8
[W]07
[W]01
[W]02
[W]da
[W]00
------------
------------
[R]d5
[R]8d
[R]21
[R]25
[R]d4
[R]00
[R]01
[R]fe
[R]33
[R]6a
[R]3e
[R]f0
[R]f5
[R]50
[R]ac
[R]10
[R]00
[R]00
[R]00
[R]32
[R]46
[R]66
[R]6d
[R]01
[R]01
[R]11
[R]02
[R]02
[R]03
[R]80
[R]03
[R]02
[R]00
[R]13
[R]04
[R]01
[R]64
[R]07
[R]01
[R]03
------------


回答:
長いですね。
長いのは、CommunicateThruEXか、TgInitTargetかのどっちかであることが多いです。
送信データの最初から「d4」を探していくと「d4 8c」が見つかります。
0x8Cといえば、TgInitTargetですね。
よく使うコマンドは、いちいち調べるのがめんどくさくなるので、覚えておくとよいでしょう(18, 32, 4a, 8c, a0くらい?)。

さて、これはLLCPの開始ログです。
ここにある受信データから読み取ることができるのは、こんな情報です。
  • 424kbps Active communication mode
  • LLCP VERSION : 1.1
  • LLCP MIUX指定あり
  • LLCP WKS : SNEPあり
  • LLCP LTO : 1000msec
  • LLCP OPT(LSC) : Class 3(Contactless / Connection-oriented)
これを読み取るには、RC-S620/Sのコマンドリファレンスマニュアルだけでなく、NFC ForumのLLCPドキュメントに目を通す必要があります。
また、NFC-DEPでもあるので、DigitalProtocolも読んだ方がいいでしょう。

おまけ:
SNEPでNDEFをPUTするのは、こんなデータ。
RTD-Textで「ueno」って送ってます。
------------
[W]00
[W]00
[W]ff
[W]16
[W]ea
[W]d4
[W]8e    //TgSetDEPData
[W]13    //DSAP=4, SSAP=4, I
[W]04
[W]00    //N(S)=0, N(R)=0
[W]10        //SNEP 1.0
[W]02        //PUT
[W]00        //0x0000000b=11byte
[W]00
[W]00
[W]0b
[W]d1        //[0]MB=1, ME=1, SR=1, TNF=Well-Known
[W]01        //[1]
[W]04        //[2]len=4
[W]54        //[3]'T'
[W]02        //[4]UTF-8
[W]65        //[5]'en'
[W]6e        //[6]
[W]75        //[7]    u
[W]65        //[8]    e
[W]6e        //[9]    n
[W]6f        //[10]   o
[W]b4
[W]00
------------


こういうのをやってるから、胃潰瘍の疑いをかけられて胃カメラを飲まされたのでは?という気がしてくるが、そういうのは忘れておこう。


GenericControl RTDは何だったのだろうか

RTDというのは、こちらへ。

その中で、もうすぐなくなるのがGeneric Control RTD。
来週にはなくなる予定なのだけど、なんでそうなったのだろう?


全くの推測なんだけど、名前が悪かったんじゃないだろうか。
「Generic」なんていわれても、どうしていいかわからんじゃないか。

一般的な制御用ルートを用意した方がいいかな、と思って作ったけど、NFC Forumの方針が決まって、そういう曖昧な用途のものはexternalにして各自でやらせて、NFC Forumでは決まった用途のものだけにしよう、という議論があったとか。

 

まあ、Generic Controlは読まないままだったからいいんだけどね。

2012/08/01

[nfc]どこら辺がセキュアにできるのか

私のイメージとしては、「NFC=セキュア」だったのだが、NFC Forumの仕様としてはセキュリティ関係のものは無い。
これは、手を抜いたとかではなく、そうすることができなかったのだろうと思っている。

NFC ForumのドキュメントDigitalProtocolは、NFC Forumの中枢だと私は考えている。
このドキュメントは、
  • ISO/IEC 14443 Type A , ISO/IEC 18092 106kbps ==> NFC-A
  • ISO/IEC 14443 Type B ==> NFC-B
  • ISO/IEC 18092 212/424kbps ==> NFC-F
と、現存する仕様を1つにまとめあげたところが大きな成果だ。
この3つは、基本技術を
  • NFC-A ==> NXP
  • NFC-B ==> Motorola
  • NFC-F ==> Sony
とそれぞれがやってたように思う。
これだけ大きい3社の仕様だから、売り物になるセキュア部分は手を付けることすらできなかったんじゃないだろうか、と勝手に思っている。

まあそれはともかく、NFCのセキュアってのはどこら辺でできることだろうか?
  • クライアント側が持っているデータ
  • サーバ側が持っているデータ
  • サーバとクライアントの通信
めんどくさいので、このくらいにした。

クライアントが持っているデータは、セキュアエレメントで保証していると思う。
サーバ側は、なんか事件が起こらない限りは、どうデータを持ってるかわからなさそうだ。
一番見えやすいのは(見えないけど)サーバとクライアントが通信するところだろう。
このクライアントは、
  • NFCカード
  • NFCモバイルチップ
のどっちかだろう。
NFCのP2Pってのもあり得るが、今のところP2Pのセキュアな通信はない(はず)。
やろうと思えばできるのだろうけど、私が知っている仕様書にはそういうのがないな。

P2Pのセキュアな通信、というのは、無線部分の通信になる。
この無線部分が、最初に書いた無線部分がああだこうだ、になる。
無線に至るまでの経緯は、携帯電話内であればUSIMとかSEとの間くらいしかない。
PN544のブロック図を見ると、USIMとの間は1本線でつながっているだけなので、そこをハード的に切り離しているのであれば、ソフトからの傍受は免れる(普通は離すだろう)。
Secure Elementを搭載していたとしても、そこはNFCチップと専用線でつなぐので、大丈夫っぽい。
つまり、NFCチップがこの辺の情報の拠点になるのだ。
GSMAは早くからそのことを心配していたということか。



私の適当な予想では、SP2P(Secure P2P)ってのが出てくるんじゃなかろうか。
セキュアエレメントを使うってのは、その管理会社に依存してしまうことになる。
FeliCaだと、FeliCa Networks社になるのかしら。共通領域を使いたかったら申請して許可を得て(金も払って)ようやく使えるようになる。
そういう過程を経ることでセキュアさが増しているのだが、ユーザとしては行った通信がセキュアだったのかどうかを知る術がない。



httpに対するhttpsのようなわかりやすさが、NFCにも必要かもしれない。
NFCカードにはそれが無理だから、https専用、みたいな位置づけになってしまうのかもしれない(iD専用、とか)。
カードが増えてしまうけれども、結局はセキュリティを保っていることを目に見せるためには、物理的に別カードにするしかなかった、というところだろうか。

問題は、モバイルNFCチップだろう。
あまり詳しくはないけれども、USIMに載っているセキュアエレメントってのもあるということではないか。
セキュアエレメントの選択って、どうやってるんだろうね?
日本の支払だと、かざす前に「エディで」みたいなことをいってると思う。
ああなるんだろうか。



使い勝手とセキュリティは、お互いがぎりぎり我慢できるところまで詰めていくものだと思う。
NFCでの支払については、FeliCaのように「カードは複数枚になるけどわかりやすい」という形になるか、「セキュリティとしてはよくわからなくなるけど、1枚のカードでらくちん」のどっちかしかないんではないかしら。
どっちを使うにしても、1社だったら1枚のカードであることに変わりはないし。

私の経験では、セキュリティが増すと使い勝手は悪くなりがちだが、うまくやると悪くしなくてもよいだろうし、少なくとも同じレベルで済ませることもできるかもしれん。
詳しくはないけど、考えどころなのだろうな。

[無駄話]NDEF分割

NDEFにCFってビットがあるので、もしかして複数枚のカードにNDEFを分割して、順番にカードをかざしていくと、最後に1つのNDEFデータになる、という用途で使えるのではと思った。

NDEF 1.0のPDFのp.9に、こうあった。

... Chunked payloads are not intended to support multiplexing or streaming of content and such use is deprecated.
ふーん。
わかったようなわからんような。
multiplexingは複数NDEFメッセージを送るようなことをいっているのかな?

でもまあ、こうわざわざ書いているところを見ると、そういう意見が委員会の中であったのだろうかね。
それにこれはNFC Forumの意見であって、個人でやってみる分には(そうじゃなくても)問題はないだろう。

何に使うかといったら・・・遺産のありかを複数のカードに分割して記録して孫に分配する・・とか?
いや、それだとNDEFである必要がないな。
いっそのこと、百人一首の上の句・下の句みたいなのでもいいのかも。
いやいや、そもそもNDEFとして非推奨のことをわざわざNDEFとしてやる意味がないのか・・・。
「こ、これは禁じられたNDEFフォーマット!」と言い張るとかくらいしか用途はないのかもしれんな。