おじいちゃんは

どんなNDEFが好き？

やっぱり

Short Record

かな

Short Recordなら

メモリの少ないNFCタグでも

十分対応できます！

FeliCa Lite

MIFARE UL

第１章 Short Recordって？

そもそも、Short Recordってなんなの？

Appendix Shortじゃない方は、いるの？

第２章 絵でわかる！ Short Recordの読み方

実際に Short Record NDEFを読んでみよう

- 1 -

Short Recordの NDEFを見る

今回の特集で見ていく、 Short Recordの NDEFレコード構成を Fig.1-1に示す。

この場合、 SRは 1 となる。

b7 b6 b5 b4 b3 b2 b1 b0

MB ME CF SR IL TNF

TYPE LENGTH

PAYLOAD LENGTH

ID LENGTH

TYPE

ID

PAYLOAD

Fig. 1-1 Short Recordの NDEFレコード(SR=1)

これに対して、 Short Recordではない NDEFレコード構成を Fig.1-2に示す。

この場合、 SRは 0 となる。

b7 b6 b5 b4 b3 b2 b1 b0

MB ME CF SR IL TNF

TYPE LENGTH

PAYLOAD LENGTH 3

PAYLOAD LENGTH 2

PAYLOAD LENGTH 1

PAYLOAD LENGTH 0

ID LENGTH

TYPE

ID

PAYLOAD

Fig. 1-2 Short Recordではない NDEFレコード(SR=0)

大きな違いは PAYLOAD LENGTHで、 Short Recordでは 1 byte分なのに対し、そうではない場合

は byte分確保されている。

すなわち Short Record とは、ペイロード長が 255 byteまでの NDEF レコードなのである。

第１章 Short Recordって？

NDEFの Short Recordとはどういったものであろうか。基本を振り返ろう。

NDEF

PAYLOADLENGTHが多いんだね！

普通のNDEFと何が違うのかしら？

月刊 NDEF 2013年 1, 2, 3月号

- 2 -

最初の 1 byteですべてがわかる

NDEFレコードの 1行目には、そのレコードを読むための情報がすべて書かれている。

MB ME CF SR IL TNF

Fig. 2-1 まず 1行目を読み取れ

MB (Message Begin)

この NDEFレコードが、一連の NDEF メッセージの先頭かどうかを示すビット。

先頭であれば 1 、そうでなければ 0 となっている。

「一連の NDEF メッセージ」としたのは、 NDEF レコードのペイロードとして入れ子となった

NDEF メッセージを含む場合があるからである。例えば Smart Posterの場合、全体としては

「 Smart Poster 」の NDEFレコード 1つを含んだ NDEF メッセージが 1つしかない(NDEF メ

ッセージは 1 つしか含まない仕様)。しかし Smart Poster の NDEF レコードのペイロードに

は、 URIや TEXTなどの複数 NDEFレコードを含んだ NDEF メッセージを持つ。

NDEF メッセージNDEFレコード Smart Poster(MB=1, ME=1)

NDEF メッセージ

NDEFレコード URI (MB=1)

"http://～"

NDEFレコード TEXT (ME=1)

"○○ blog"

Fig. 2-2 入れ子となった NDEF メッセージ

ME (Message End)

MBの逆で、 NDEF メッセージの末尾であれば 1を、そうでなければ 0 となっている。

第２章 絵でわかる！Short Recordの読み方

NDEF

入れ子だニャ

月刊 NDEF 2013年 1, 2, 3月号

- 3 -

CF (Chunk Flag)

chunk of a payloadで「ペイロードの塊」となるが、ここでは分割されたペイロード、という意味。大きな

ペイロードを持つ NDEF メッセージを複数に分割した場合に使う。

分割していないときは、 0 。

ストリーミングのような目的で分割しないこと(NFC タグではできないが、携帯電話同士が NDEF デー

タを交換する場合には、やろうと思えばやれるため)。 HTTP/1.1(RFC2616)のような意味で使うため

に設けているとのこと。

通常の使用であれば、 0 と考えていいだろう。

SR (Short Record)

ここが 1の場合、この NDEFレコードは Short Record ということになる。

NDEF として使えるメモリは、 FeliCa Liteで 208 byte(14のユーザブロックのうち、先頭の 1ブロック

は Type 3 Tagの属性情報として使う)、 MIFARE Ultralightで 48 byte となっていて、 256 byte以

上のユーザメモリを持たない NFC タグも多い。

IL (ID LENGTH有無)

ここが 1の場合、 ID LENGTH フィールドが存在する。 0の場合は存在しない。

よく使われる NDEFでは、 IDを使わないことが多い。 IL=0 とすることで 1 byteの ID LENGTH フィ

ールドを削除でき、 PAYLOAD として使うことができるようになる。

TNF (Type Name Format)

NDEFレコードのタイプが記載されている。

よく使われるのは、 well-known 、media-type 、 URIであろう。 Androidアプリでは external type も

使用されるようである。

ここまで解析できると、それ以降のデータが解析できるようになる。

もう少しだよ

月刊 NDEF 2013年 1, 2, 3月号

- 4 -

LENGTHを把握する

ここまでで、この NDEFレコードについて以下の情報がわかっている。

NDEF メッセージの先頭かどうか・

NDEF メッセージの末尾かどうか・

複数に分割されているかどうか(今回は分割無ししか考えない)・

Short Recordかどうか(今回は Short Recordの場合)・

ID LENGTHがあるかどうか・

NDEF レコードタイプは何か・

TYPE LENGTH

PAYLOAD LENGTH

ID LENGTH (IL=1 の場合)

Fig. 2-3 LENGTHが 3つ

LENGTH フィールドが続くが、注意するのは以下の２点である。

LENGTHは 0の場合もある・

ID LENGTHは IL=1の場合しか存在しない・

IL=0の場合は、 ID LENGTH フィールドも ID フィールドも存在しない。

それだけでなく、例えば TYPE LENGTHが 0の場合には、 TYPE フィールドも

存在しないようになる。

極端な場合、 TNF=Emptyでは、 TYPE LENGTH=0 、 PAYLOAD LENGTH=0 、 IL=0のため、全

部で byte しかないことになる。

各フィールドを読む

ここまでで、残りを読むための情報がわかっている。

TYPE LENGTHはいくつか(フィールドが存在するか)・

PAYLOAD LENGTHはいくつか(フィールドが存在するか)・

ID LENGTHはいくつか(フィールドが存在するか)・

TYPE, PAYLOAD, IDは、 LENGTHが 0かどうかで読むかどうかを決めるようにしておくとよいだろ

う(IL=1 としておきながら、 ID LENGTHが 0 という可能性もあるので)。

これで読み込み完了である。

あとは TNFや TYPEによってペイロードを解析することになる。

LENGTHが0だとフィールドが隠れるぞ

読めなかった子はいねぇがぁぁ！

月刊 NDEF 2013年 1, 2, 3月号

- 5 -

今回の特集では、 NDEFの Short Recordについて見ていった。

実際に市販されている NFC カードを見た際、メモリ容量が 256 byte以上あるものはほとんどない。

少なくともそれらのカードについては、 Short Recordではない NDEF メッセージというのはメモリの無

駄でしかない。少しでも多くの情報を載せたいのであれば、 SR=1 、 IL=0 としてペイロードの容量を

稼ぐべきであろう。これだけで byte多くなるのだ。

では、 Short ではない NDEF レコードが必要となるのはどういう場合だろう

か？ もちろん 256 byte 未満の NFC カードであっても Short ではない

NDEF レコードを使うことは可能であるが、ここでは必要性だけを考えること

にする。

まず、ペイロードが 256 byte以上存在する、ということになる。

もちろんそれは、 NFC カードが 256 byte以上の容量を持つということでもある。

よく使う NDEF のレコードタイプでは、それほど大きなデータを必要とすることが少ないのではないだ

ろうか。

URI は長くなりがちではあるが、そもそもそういう長い URI を NDEF にするような運用はそれほどな

いのではなかろうか。

私は、今のところ NFC カードは「高価な」扱いだと思っているので、ちょっと検索した URIを入れるより

も、「うちのブログです」のような URIを入れることの方が多いのではなかろうか。

市販で入手しやすい大きな容量の NFCカードが、 FeliCa Liteや MIFARE Ultralight C くらいで、そ

れらの容量が 256 byteを超えていないことを考えると、今のところではあるが Short Recordよりも

大きなデータがまだ必要になっていない、ということではないかと考えている。

とはいえ、フロッピーディスクだってハードディスクだって、小さな容量からどん

どんと大容量化が進んでいった。 NFC もその道をたどらないとは限らない。

まだ NFC も一般用途として広まりだしてから歴史が浅いので、どういう方向に

進んでいくかわからない。

現在の状況だけですべてを判断するのは危険だ。

NFCを愛する我々としては、どのような進化になったとしても見守っていきたいところである。

Appendix Shortじゃない方は、いるの？

少しでも稼ごう

月刊 NDEF 2013年 1, 2, 3月号

- 6 -

第１章 Type 2 Tagの基本

何がどうなったら Type 2 Tagなんだろう？

Appendix MIFARE? Mifare? どっち？？

第２章 Type 2 Tagを読もう

実際に Type 2 Tagの NDEFデータを読んでみよう

月刊 NDEF 2013年 1, 2, 3月号

今月のメニューはこちらです！

どっちも好き！

おにぎりとType2、

どっちが好き？

- 7 -

NFC Forumの定義

「 Type 2 Tag 」という呼び名は、 NFC Forumが付けた名前で、 ISO/IECなどの機関が決めた名前

ではない。

Platform

NFC Forum仕様書「 Digital Protocol 1.0 」(NFCForum-TS-DigitalProtocol-1.0)では「 Type 2 Tag

Platform 」として定義されている。

無線の方式(Technology)として、 NFC-A を使用している。 106kbps で無線通信を行うのだが、「 A

と B と Fがあって、その中の A 」くらいで十分だろう。

Operation

NFC Forum仕様書「 Type 2 Tag Operation Specification 」(NFCForum-TS-Type-2-Tag_1.1)に

扱うときの詳細が書かれている。

メモリ構造・

ユーザメモリ部の使い方・

無線で読み書きするときのコマンド・

使用例・

メモリ構造■

Static Memory Structure と Dynamic Memory Structureがあるが、これは NXPの製品である

「MIFARE Ultralight 」(64 byte)と「 MIFARE Ultralight C 」(192 byte)の違いだと思ってよいだろう。

64 byteのメモリ構造が Static Memory Structureで、それより大きいものが Dynamic Memory

Structure となっている。

違いは、 Dynamic Memory Structureの場合はユーザメモリ領域の次に拡張領域があるということ

だ(Fig.1-1)。

とりあえず使ってみるのであれば、あまり細かいことは

気にしなくてよいだろう。

第１章 Type 2 Tagの基本

Type 2 Tagは、そもそもどういうものだっただろうか。基本をおさらいしよう。

Tag

月刊 NDEF 2013年 1, 2, 3月号

細かいことは

忘れてしまえ

- 8 -

Block 0 1 2 3

0

1 UID / Internal

2 Lock bytes

3 Capability Container

4 ～ 15 Data Area

16 ～ n Data Area

n+1 ～ Lock / Reserved

Fig. 1-1 メモリ構造

ユーザメモリ部の使い方■

ユーザメモリ(Fig. 1-1の「 Data Area 」)は、単なるメモリなので、ユーザが好きなように使ってよい。

ただ、そうすると互換性がないので、アプリごとに違ったフォーマットを生みだしてしまう。 NFC Forum

は標準化を行おうとしているので、メモリの使い方に決めごとを作っている。

Type 2 Tagの場合、メモリを TLV形式(Type 、 Length 、 Value)で使う。

Type (1 byte) Length (1 byte) Value (Length)

Fig. 1-2 TLV形式

無線で読み書きするときのコマンド■

ここまでの話は、すべて NFC タグに読み書きできる前提で進められた。

では、どうやって NFC タグに読み書きするかというと、 Technology 「 NFC-A 」方式で NFC リーダラ

イタという機械と NFC タグが無線通信を行うことによって実現する。

そう書くと非常に難しそうだが、無線通信の仕方は NFC リーダライタがうまくやってくれるので、使う人

は NFC リーダライタに送信してほしいコマンドデータを作ったり、 NFC リーダライタが受信したデータ

を解析したりするだけだ。 Android OSのように、基本機能として NFCが組み込まれている場合はさ

らに手軽に使えるようになっている。

さらにさらに、 Android OSでは Type 2 Tag製品の１つである MIFARE Ultralightをアクセスするた

めの手段が既に用意されているため、 Type 2 Tag であれば敷居が低くなっている(おそらく、

Android が NFC をアクセスするために採用した部品が NXP 社だったため、優遇されているのだろう

と思われる)。よって、 Androidから Type 2 Tagにアクセスするのであれば、コマンドまで知らなくても

NFC タグにアクセスすることができる。

まずはそんなに悩まず、やってみるとよいだろう。

メモリが64 byteなら

15ブロックまでよ

月刊 NDEF 2013年 1, 2, 3月号

まあ、そう悩むな

- 9 -

お前は NDEFなのか？

NFC タグは単なるメモリであり、第１章で書いた内容は NFC Forumが定義した仕様に従った場合、

という前提である。

他の仕様に従ったデータが書かれているかもしれないので、アプリケーションはデータを読んだときに

「自分の意図するフォーマットで書かれているのか？」ということをチェックしなくてはならない。

この章であれば「お前は NDEFなのか？」というチェックをすることになる。

NDEFのデータであることがわかれば、

それ以降は NDEFの読み方をすれば

よいだけである。

NDEF Detection Procedure

Type 2 Tagの仕様書に「 NDEF Detection Procedure 」という、 NDEFを検出する手順が書かれて

いるので、それを追ってみよう。

なお、 NXP 社のドキュメントには他のフォーマットを読むときの方法も書かれているので、興味がある

方はダウンロードするとよいであろう。

まず CCを読め

Fig. 1-1に「 Capability Container 」(以下、 CC))という情報が Block 3にある。

NDEFの場合、 CCに特定のデータを書き込むことになっている。

まず、 CC[0]に 0xE1が書き込んであること。

これが大前提である。この数値はマジックナンバーで、 0xE0 だったら、とか、 0xE2 だったら、という

わけではない。

そうなっていない場合は、もう NDEF として

読み込むのをやめてよい。

第２章 Type 2 Tagを読もう

Type 2 Tagを読むのだ。Tag

はい、ここでは

NDEFを読むまでの

説明をしますよ

月刊 NDEF 2013年 1, 2, 3月号

読むのをやめて

違うことでもしようか

- 10 -

CC[1]には Type 2 Tagのバージョンが入っている(上位 4 bitがメジャーバージョン、下位 4 bitがマ

イナーバージョン)。今までリリースされた Type 2 Tagのドキュメントは「 1.0 」と「 1.1 」なので、それぞ

れ「 0x10 」と「 0x11 」になる。

このバージョンは、 Type 2 Tag Operation Specificationのドキュメントバージョンとなる。現在は 1.1

だが、少し前までは 1.0だった。今後もバージョンが上がっていくことが予想される。

メジャーバージョンアップ、マイナーバージョンアップについてどうあるべきか仕様書に書かれている

が、まあ今の段階では気にしなくてよいだろう。

CC[2]はユーザデータのサイズを 8 分の 1 した値が入っている。例えば「 0x06 」ならば 48 byte 、

「 0x12 」なら 144 byte 、という具合だ。これは NDEF として使っているサイズではなく、ユーザデータ

領域のサイズを指すようである。

CC[3]は、上位 4 bitに読み込む方の、下位 4 bitに書き込む方の制限というか、能力というか、そう

いった値が入っている。

上位 4 bit・

0x0 ・・・セキュリティ設定なし・

0x01～ 0x07 、 0x0F ・・・ RFU(将来のために空けている)・

0x08～ 0x0E ・・・プロプライエタリ(メーカー用)・

下位 4 bit・

0x0 ・・・セキュリティ設定なし・

0x01～ 0x07 ・・・ RFU(将来のために空けている)・

0x08～ 0x0E ・・・プロプライエタリ(メーカー用)・

0x0F ・・・書き込み禁止・

NDEFであれば、だいたいこういう値になるのではなかろうか。

MIFARE Ultralight : 0xE1 0x10 0x06 0x00・

MIFARE Ultralight C : 0xE1 0x10 0x12 0x00・

もうちょっと

月刊 NDEF 2013年 1, 2, 3月号

仕事でやるときは

気をつけるのだ

- 11 -

NDEF TLVを読む

CCが期待通りの値だった場合、ユーザデータ(Block 4以降)は NFC Forumが定義する TLV形式

であると想定してデータを読み込む(違う可能性もあるので、サイズの異常対策だけはしておこう)。

先頭から TLV を順に読んでいき、 T=0x03(NDEF メッセージ)が見つかるまで読み進める。もしユー

ザデータの最後まで 0x03 が見つからない場合や、先に T=0xFE(TLV 終わり)が見つかった場合は、

そこまでで終わる。

次に NDEF メッセージの L(Length)を確認する。もし 0 であれば、そこまでで終わり、これ以降の TLV

検索は進めない(最初の NDEF メッセージ TLVだけが有効)。

後は読むだけ！

あとは、この TLVの Value部分を NDEF メッセージとして読むだけである。

NDEF メッセージの読み方は、タグの種類によらず同じである。

読めなかった子はいねぇがぁぁ！

月刊 NDEF 2013年 1, 2, 3月号

- 12 -

Type 2 Tag といえば、 NXP社。

さて、「MIFARE 」か「Mifare 」か？ いつも迷う。

ここまでの文章を振り返るとわかるように、正解は「 MIFARE 」である。

ホームページより(http://www.mifare.net/overview/)

「 TM 」とついているので、登録商標ということであろう。

同じようなことがフェリカでも気になる。

これは「 FeliCa 」と、 F と Cが大文字である。

FeliCaに関する製品の商標が以下のページに書かれていた。

http://www.sony.co.jp/Products/felica/attention.html

交通カードには「○○カ」のような名前が多いのだが、「 Suica 」のように先頭だけが大文字だったり、

「 TOICA 」のように全部大文字だったり、「 nimoca 」のように全部小文字

だったり、みんなばらばらである。

文章で書くときには、やはり正しい名前を使うように心がけたいが、特にルールがあるわけではないの

で間違えないように気をつけたいものだ。

Appendix MIFARE? Mifare? どっち？？

月刊 NDEF 2013年 1, 2, 3月号

正しさを

人に求めすぎると

嫌われるぞ

- 13 -

第１章 Type 3 Tagの基本

第２章 Type 3 TagとFeliCa

今月の内容はこちらです！

今日のお洋服は

PASMOっぽいわね

そういうあなたも

Suicaカラーだわ

第3章 FeliCaとNFC

月刊 NDEF 2013年 1, 2, 3月号

付 録 Type 3 Tagヘッダ

- 14 -

NFC Forumの定義

Technology として「 NFC-F 」を使う唯一の Platformである。

Technology

NFC Forumの用語で、無線の通信方式を表している。

「通信」という動作を行う場合、だいたい次のようなことを考えることになる。

1. 物理的な接続方法(○○ケーブルで接続する、無線を使う、など)

2. 物理的な接続を行った後の、物理的な通信方式(通信速度や、 1 と 0をどう表すかなど)

3. 物理的に通信できるようになった後の、論理的な通信方式(パケットの構造など)

4. 通信を使ったアプリケーション

項目の 1 と 2 を表しているのが Technologyで、 3は Platform 、 4が NDEF 、のようなイメージでい

たら、だいたいよいのではなかろうか。

NFC-Fは、「 F 」とついているので気付いたかもしれないが、 FeliCaの通信方式である。国際規格の

ISO/IEC 18092にある「 212kbps / 424kbps 」の通信方式でもある。

あまり難しく考えず、「 FeliCa と同じなんだ」くらいわかっておけば十分だろう。

Platform

これも NFC Forumの用語である。

Technologyでは「無線通信」のところしか決めていないので、 Platformでソフトウェア的なアクセス方

法(パケットの構造)や、 Tag としてのメモリ構造などを決めている。

第１章 Type 3 Tagの基本

Type 3 Tagをおさらいしよう。Tag

月刊 NDEF 2013年 1, 2, 3月号

難しいところは

洗い流しておくわ

- 15 -

NFC-Fが FeliCaの通信方式だったように、 Type 3 Tag も FeliCaのアクセス方式になっている。

現在(2013年 2月)のところ、 FeliCaのタグとしては「 FeliCa Standard 」と「 FeliCa Lite / Lite-S 」が

ある。

Type 3 Tagは、 FeliCa Lite / Lite-Sを基本としている。

経緯は詳しくないのだが、 FeliCa Lite / Lite-S (以下、 Lite)は FeliCa Standardをベースに作られて

いると考えている(私は)。 FeliCa Standardは、 Suicaのような決済にも使えるほどのセキュリティと、

複数の FeliCa アプリ(Suica 、 nanaco など)の同居ができるような汎用性を考えているため、メモリア

クセスにいろいろな種類がある。

Lite はそのあたりを削除した簡易版と考えてよいが、通信方式が同じなので、ある程度の部分は概念

が残っている。

そういったこともあり、 Type 2 Tag と比べると多少の知識が必要になる。

メモリ構造

基本的な考え方■

FeliCa自体のメモリは、単なる RAM配列ではなく「ファイルシステム」という考え方になっている。

ハードディスクに「パーティション」「フォルダ」「ファイル」「クラスタ」があるように、 FeliCa には「システ

ム」「エリア」「サービス」「ブロック」がある。

「セクタは？」と思われそうだが、上記はクラスタでもセクタでもどっちでもよいだろう。

ブロック■

メモリの最小アクセス単位は「ブロック」である。 1ブロックは 16 byte (Type 2 Tagは 4 byte)。

ディスクのファイルシステムと照らし合わせると、 1 クラスタ = 1セクタ = 16 byte 、くらいになるだろ

うか。

サービス■

サービスとは、ブロックをグループにして、同一グループに対して同じアクセス方法を。

FeliCa Standardには、「ランダムサービス」「サイクリックサービス」「パースサービス」の 3つがある。

さらにその 3 つの中に、「読み書き可能」「読み込みのみ」や、「認証不要」「認証必要」などの属性が

あるため、種類としては 16あることになっている。

サービスの 16種類にはそれぞれ値があり、「サービスコード」と呼ばれている。

月刊 NDEF 2013年 1, 2, 3月号

サービス

しときました！

- 16 -

Type 3 Tagでは、その中で以下の２つをサポートしている(仕様書「 2.3.3 」)。

・ 「ランダムサービス」の「読み書き可能」で「認証不要」 : サービスコード = 0x0009

・ 「ランダムサービス」の「読み込みのみ」で「認証不要」 : サービスコード = 0x000B

ランダムサービスは、ブロック番号を指定してアクセスできる。ディスクのファイルシステムで考えると

「ファイル」と「ファイル属性」が一緒になったようなものと思えばよかろうか(ちょっと強引か)。

エリア■

FeliCa Standardには、エリアという考え方がある。

が、 Type 3 Tagにはないので、安心して忘れよう。

システム■

メモリ構造の一番上で、メモリにアクセスする場合には最初に指定することになる。

パーティションやドライブのようなイメージか。

たとえば Suica では「 0x0003 」というシステムを使っているが、 Edy では「 0xFE00 」というシステム

を使っている。かといって「 0x0003 」は Suica だけが使っているわけではなく、 nimoca など他のアプ

リもつかっているし、「 0xFE00 」も然りだ(なお、 0xFE00は「共通領域」というシステムで、他の人もた

くさんいる)。

Type 3 Tag では「 0x12FE 」というシステムを使うことになっている。 Lite はシステムとして

「 0x88B4 」を使っているが、設定によって「 0x12FE 」としても使うことができるようになっている。これ

は特殊な例で、通常１枚のカードが複数のシステムを持つ場合には、それぞれのシステムごとにメモ

リを分けるようになっている。

IDm■

Manufacture IDや NFCID2 とも呼ばれる(製造者コードだから Manufacturer ID じゃないのか？)。

主な用途としては、複数枚のカードが同時にかざされたとき、リーダライタが 1 枚を指定するために使

うものだと思っている(セッション IDみたいなものか)。

現在使われている製品には、 IDm だけで世の中から 1 枚の FeliCa カードを識別できる前提になっ

ているものもあるが、セキュリティが必要なところではそういうやり方はしないように注意しよう。

ないものは

忘れてしまえ

月刊 NDEF 2013年 1, 2, 3月号

システムで使うなら

しっかりと考えよう

- 17 -

アクセス

FeliCa Standardには多くのアクセスコマンドがあるが、 Type 3 Tagには 3つだけ用意されている。

Polling・

Check (Read Without Encryption)・

Update (Write Without Encryption)・

括弧内は、 FeliCaでの名称である。

詳細は仕様書を確認してほしいが、ここではわかりづらい(と私が思った)ところを説明する。

手順■

NFC リーダライタ側の目線で、アクセスする手順を書こう。

1 Polling(ワイルドカード)で、 Tagの存在を確認する

2 Polling(システムコード指定)で、アクセスしたいシステムを確認する

3 Checkや Updateを行う

4 接続を切る

Polling コマンドの戻り値として、 IDm と一緒にシステムコードを返してもらうこともできる。

このときに返ってくるシステムコードは「最初のシステムコード」である。携帯電話であればおそらく

「 FE00 」だろうし、 Liteであれば「 88B4 」である。

FeliCa Standardには「 Request SystemCode 」というコマンドがあり、カードが持っているシステム

コード一覧を取得することができるが、 Liteにはそれがない。つまり、 Liteは設定で Type 3 Tag とし

てアクセスできるようになっていたとしても、 Polling コマンドで取得することはできない。

どうするかというと、システムコード 12FC を指定して Polling を投げて確認するしかない。「なら、ワイ

ルドカードで Polling しなくていいではないか」と言われそうで、たぶんそうなのだろう。

いきなりアクセスできるか？■

システムコードもわかっていて、 IDm もわかっているならば、 Check や Update をいきなり使ってもよ

さそうだが、そうはいかない。

Pollingには「システムを捕捉する」という意味合いもあるので、やはり Pollingはいるのだ。

接続を切る？■

手順の最後で「接続を切る」と書いたが、これはリーダライタが送信している無線を止めることである。

ハード的に止めてもいいし、無線が届かない距離までカードを離してもよい。

NFC のタグは、だいたい電源を持っていない。リーダライタが送ってくる無線を使って発電してチップ

が動作するのだ。

FeliCa Lite の説明を読んだが、「電源を切ると、それ以降アクセスできないようにできる」というよう

に、電源が切れることによって設定が完了するものもあるので、気にしておくとよいかもしれない。

月刊 NDEF 2013年 1, 2, 3月号

無線が

降ってくるわ

- 18 -

Type 3 Tag と FeliCa Liteは同じものか？

Type 3 Tag と FeliCa Lite / Lite-Sの関係は、 Type 2 Tag と MIFARE Ultralightの関係と同じであ

る。

つまり「 Type 3 Tag 」は概念であり、それを製品化した一例が「 FeliCa Lite / Lite-S 」なのである。オ

ブジェクト指向っぽく考えると、 Type 3 Tag という基底クラスがあり、それを継承して FeliCa Lite とい

う派生クラスがある、という感じか。

FeliCa Liteは何が追加されている？

減算レジスタブロック Reg

1 ブロック分のユーザブロックだが、ランダムサービスのブロックのように自由に書き込めるわけでは

なく、条件を満たした場合のみ書き込みができる。

まず、 16 byteが以下のように 3分割されている。

RegA : 4 byte分・

RegB : 4 byte分・

RegC : 8 byte分・

RegA と RegBは、リトルエンディアンの 32bit値として扱われる(RegCは自由)。

以下の条件を満たすとき、このブロックに書き込みができる。

RegA : 現在の値以下の値・

RegB : 現在の値以下の値・

第２章 Type 3 TagとFeliCa

じゃあ、Type 3 Tag = FeliCaでよいね？Tag

月刊 NDEF 2013年 1, 2, 3月号

Type 3 Tag

FeliCa Lite

FeliCa Lite-S

そんなものかね

- 19 -

わかりづらいので、例を挙げよう。

なお、私は Regブロックを使ったことがないので、間違っていたら申し訳ない。

例■

Regブロックの値 : 67 45 23 01 EF CD AB 89 xx xx xx xx xx xx xx xxRegA : 0x01234567RegB : 0x89ABCDEF

この場合、書き込みたいのであれば、

RegA : 0x00000000～ 0x01234567RegB : 0x00000000～ 0x89ABCDEF

の値を書き込むことになる。 1 ブロック単位でしかアクセスできないので、一部だけ書き込みたい場合

でも 16 byte指定して書き込むことになる。

つまり、 RegA や RegB に現在値よりも小さい値を書き込むと、それより大きい値に戻すことはできな

いことになる。

使い道としては、回数券のように、制限を設けたい場合だろう。 RegA と RegB は同値でも書き込め

るので、書き込み回数が必ず制限されている、ということではないが、そこら辺は運用で考えることに

なるだろう。

片側認証

カードを発行した側が「このカードは第３者に書き込まれていないだろう」と認証する方法。

FeliCa Liteには「カード鍵ブロック」という値を書き込むブロックがある。そのブロックは書き込み専用

なので、書き込んだ人しかその値を知らない。

別のブロックとして「ランダムチャレンジブロック」というものがあり、そこに値を書き込むと、カード鍵の

値と書き込んだ値を使って、あるアルゴリズムを使った計算を行い、結果を「 MAC ブロック」として読

み込めるようになる。

カードを発行した人は、カード鍵の値と、ランダムチャレンジに書き込んだ値と、計算するアルゴリズム

がわかるので自分で計算し、読み込んだ MAC ブロックの値と比較して、カード鍵が発行したときと同

じものかどうかが識別できる、という考え方だ。

実際はもう少し手が込んでいるのだが、難しいので説明しない。

仕様書もあるので興味がある人は調べてみよう。

月刊 NDEF 2013年 1, 2, 3月号

ネズミにしか

興味がないな

- 20 -

FeliCa と NFCの関係は、MIFARE と NFCの関係と同じようなものだ。

ただ、 MIFARE について語ることができるほど私の知識は広くない。 FeliCa についてもそれほど広く

ないのだが、私の知っている範囲で書いていく。

NFC とは？

そもそも、「 NFC 」という語り方をしたときの「 NFC 」とは、一体なんなのだろうか。

13.56MHzの無線を使ったものを NFC と呼ぶのか、その通信距離が数 cmのものを呼ぶのか。

はたまた、 ISO/IEC 14443や ISO/IEC 18092を満たしているものを呼ぶのか。

どれも、間違っていないとは思うが、そうなると「 NFC ってなによ」というのが結局わからない。

なので私の場合は「 NFC Forumで規定している内容を満たしている(と思っている)」ものを NFC と呼

ぶようにしている。仕様を全部把握しているわけでもないので、この「月刊 NDEF 」シリーズもあやしい

ところはあるかもしれないが、気持ちとしてはそうしている。

NFC Forumから見ると？

NFC Forumでは、無線通信方式である Technology と、そのアクセス方式の Platform くらいまでし

か規定していない。

その視点からすると、 FeliCaは NFCに沿っている。

第3章 FeliCaとNFC

じゃあ、FeliCaと NFCの関係はどうなのだ？Tag

気持ちが大切でござい ます

月刊 NDEF 2013年 1, 2, 3月号

NFC Forum

NFC-A NFC-B NFC-F

Type 1

Type 2

Type 4A

Type 4B

Type 3

FeliCa

- 21 -

世の中には、 13.56MHz の無線を使って、数 cm のところでしか通信しないような規格がいくつもあ

り、それらは実際に運用されている。

NFC Forumでは、それらすべてを取り込もうとしている。だから、 NFC Forumから見ると、MIFARE

も NFC Forumの規格を満たしているし、 FeliCa も NFC Forumの規格を満たしている。

運用面から見ると？

MIFARE や FeliCa は、 NFC 製品と言うよりも、 NFC の規格を使ったシステムである。タグを使って

アクセスするのは、システムの一部に過ぎない。

システムについては詳しくないのだが、こういうイメージではなかろうか。

各拠点に NFC の R/W があり、そこで MIFARE なり FeliCa なりのカードにアクセスし、情報をやりと

りする。その情報はネットワークを介してサーバに集約される。最終的なお金の決済などは、サーバが

銀行のシステムなどとやりとりをする。

本当はもっと難しいシステムなのだろうが、こうやって見ると、 NFC の部分は大切ではあるけれども

わずかだ。大半は拠点とサーバをどうつなぐかとか、どうやって決済を行うだとか、そういうところが重

要になってくる。

NFC Forumでは、もちろんこういうことには触れていない。そもそも NFC通信のセキュリティには踏

み込んでいないので、実際に決済で使うのであれば各社が自前でセキュリティを用意するしかない。

その部分は「 NFC Forum対象外」なので、 NFC Forumの規格を守りつつ独自システムを組み入れ

ることは可能なのだ。

違う見方をすると、 NFC Forum としては MIFARE も FeliCa も規格内ではあるものの、相互交換が

できるのは NFC Forumで規定された範囲に限るのである。今のところ NDEFがそれにあたるが、セ

キュリティについては取り決めがないため、決済のような目的には使うことが難しい。

月刊 NDEF 2013年 1, 2, 3月号

- 22 -

決済方面での普及はゆっくりじゃなかろうか

「 NFC を使おう！」と考えたとき、このようなシステムを作ることを考えると、費用の面から二の足を踏

むだろう。既にクレジットカードのような金融システムがあることを考えると、爆発的に普及する、という

ことは難しいように思う。進んだとしても、ゆっくりじゃなかろうか。

もし NFC Forumがセキュリティにも言及した NDEF規格を作り、それがかなり万全なものであったと

しても、 MIFARE と FeliCaのタグにセキュアなアクセスができる、というところしか実現できない。

「海外で FeliCaを使いたい」と思ったときにやらないといけないのは、

現地で運用されている MIFAREなどの R/Wシステムを FeliCaにも対応・

MIFARE で運用しているシステムの決済方式と FeliCa で運用している運用方式をなんとかする・

と、可能ではあるけれども莫大な費用と時間がかかるようなことをやらないといかんのじゃなかろう

か。

そう思った矢先、 DoCoMoがいろいろとやっている話が出ていた。

http://www.itmedia.co.jp/mobile/articles/1302/27/news107.html

この記事にある「 NFC 」は、 GSMA が標準とした NFC 方式のことと思われる。携帯電話の決済、つ

まりモバイルペイメントの方である。

詳しくないので語るものがないが、なかなか大変そうである。

ゆっく り

月刊 NDEF 2013年 1, 2, 3月号

こりゃ大変だ

- 23 -

今のところ、 Type 3 Tag として動作させることができる NFC タグは、 FeliCa Lite/Lite-S(以下、

FeliCa Lite)しかないと考えている。

もちろん、 FeliCa Standardでも可能だとは思うが、お金がかかるので私は注文したことがない。

前提条件

FeliCa Liteを Type 3 Tag として使えるようにするためには、 NFC Forumの決まりとは関係ない操

作を行う必要がある。 MC というレジスタが 1 ブロックあるのだが、その中の SYS_OP(0 から数えて

先頭から 3番目)に 0x01を書き込むことで、 Type 3 Tagの条件であるシステムコードが NDEF対

応(0x12FC)になる。

詳細は、以下の資料を参照のこと。

FeliCa Liteユーザーズマニュアル・

購入したばかりの FeliCa Liteは、 SYS_OPが 0x00になっている。

このときはシステムコードが FeliCa Lite 用(0x88B4)になっているため、 NFC-F ではあるものの

Type 3 Tag としては動作させることができない。

なお、 FeliCa Plug という組込み機器用のタグがあるが、これも設定によって NDEF用のシステムコ

ードにするか、 FeliCa Plug用のシステムコード(0xFEEL)にするのかを決めることができる。

RC-S620/S のような NFC リーダライタでカードエミュレーションを行う場合は、システムコードを自由

に設定することができる。

注意■

FeliCa のカード検出のためにポーリングを行うが、システムコードをワイルドカード「 0xFFFF 」で行う

ようにしている場合が多い。

このときにシステムコードを返すように要求していると、 FeliCa Liteは 0x88B4を返す。 SYS_OPの

設定がどうであっても、ワイルドカードで指定した場合には最初にひっかかったシステムコードを返す。

FeliCa Standardの場合は「 Request System Code 」というコマンドがあり、カードが持つシステムコ

ード一覧を取得することができるが、 FeliCa Liteにはそのコマンドがない。

何が言いたいかというと、かざしたカードが NDEF 対応しているかどうかを確認するならばポーリング

時にシステムコードを「 0x12FC 」と指定して行わなくてはならない、ということである。

詳細は、以下の資料を参照のこと。

FeliCa Liteに関するソフトウェア開発テクニカルノート・

フォーマット判別シーケンス設計ガイドライン・

付録 Type 3 Tagヘッダ

Type 3 Tagのヘッダを見ておこう。Tag

月刊 NDEF 2013年 1, 2, 3月号

- 24 -

Type 3 Tagヘッダ

Type 3 Tagヘッダは、 FeliCa Liteの 0ブロック目(PAD0)に書き込む。

Ver Nbr Nbw Nmaxb - - - - WriteF RW Ln Checksum

10 04 01 00 0D 00 00 00 00 00 01 00 00 4C 00 6F

Ver■

バージョン。現在は 1.0なので、 0x10 。

Nbr■

同時読み込み可能ブロック数。「同時」とは、 1回の Read Without Encryptionで指定できるブロック

数と考えてよい。 FeliCa Liteは 4ブロックまでなので、 0x04 。

Nbw■

同時書き込み可能ブロック数。「同時」とは、 1回のWrite Without Encryptionで指定できるブロック

数と考えてよい。 FeliCa Liteは 1ブロックまでなので、 0x01 。

Nmaxb■

NDEFデータ部として使用できるブロック数。 FeliCa Liteのユーザブロックは、 PAD0～ PAD13ま

での 14 と、減算レジスタ REG が 1 つの計 15 ブロックある。このうち自由に書き込みができるのは

PAD0 ～ 13 で、 PAD0 はヘッダとして使われているため、 13 ブロックが使用できる。よって 0x0D 。

ビッグエンディアン。

WriteF■

Write Flag 。 NDEF として書き込む前に 0x0Fにし、書き込みが終わったら 0x00にする。 NDEF と

して読み込む前にチェックし、 0x00 じゃなかったら読み込みを行わないようにするという取り決め。書

き込んでいる間に NFC タグが離れて中途半端な書き込みになることを想定したものだろう(Write

Without Encryption コマンド 1回は成功するか失敗するかしかない)。

なお、書き込み時にはフラグをチェックしない。

FeliCa Lite自体の機能を制限するものではないので、使う側が注意することになる。

RW■

RW Flag 。 0x00であれば読み込み専用、 0x01であれば読み書き可能という取り決め。

FeliCa Lite自体の機能を制限するものではないので、使う側が注意することになる。

月刊 NDEF 2013年 1, 2, 3月号

- 25 -

Ln■

実際に書き込んでいる NDEFデータサイズ(ヘッダは含まない)。単位はバイト。

FeliCa Liteは Nmaxbが 13ブロックなので、全部使っても 208バイト。

ビッグエンディアン。

Checksum■

ヘッダ部のチェックサム。 Verから Lnまで(0から 13まで)を単純に 1バイトずつ足していった値。

ビッグエンディアン。

感想

Type 2 Tag(以下、 T2T)と比較すると、ちょっとめんどくさく感じる。

Ln に相当するものは T2T にはない。 Lnがあるから Checksum もあるのだろう。同時アクセスブロッ

ク数も、あってもなくてもなあ、と感じてしまう。

NDEF アクセスに高速性と安全性を求めるならば、同時にアクセスできる最大ブロック数がわかった

方がよいと思う。 1回分のアクセスは FeliCa Liteが保障することになっているからだ。

ただ、ちょっと書いたが FeliCa Plug も NDEF タグとして動かすことができる。 Nbr は 12(0x0C)、

Nbw は 12(0x0C)で、 Nbmax に至ってはほぼ自由である。そこまで視野に入れると、巨大な NDEF

タグも作り出すことができるので、こうなるしかないか、という気もする。

新たな製品が出たときにも対応できるようにこうなった、と思っておこう。

いざというとき

対応できるよう

月刊 NDEF 2013年 1, 2, 3月号

- 26 -

単に、 3回作った内容を 1つにしただけです。

単に「まとめたら何ページくらいになるんだろう？」ということを

確認したかっただけです。

2013/03/27 10:45

編集後記

月刊 NDEF 2013年 1, 2, 3月号