MIFARE Ultralight周りのNXP製品の整理
旧知の友より「最近は専門的な内容ばかりでポカーンとなる」との指摘を受けたばかりであるが今回も技術ネタです。申し訳ないっす……。たまには見た目に華やかな内容あるからそっち見てね!
てなわけでいわゆるNFCタグのお話をば。NFC Tagと一口に言っても考え方によって指す範囲が変わってくる。例えばNFC Forum Tagのことを言うならば、
- Topaz
- MIFARE Ultralight
- FeliCa Lite
- MIFARE DESFire(ISO/IEC 14443-4)
のいずれかがベースになっていて、かつNFC Forum Tagとして扱えるようフォーマットされているタグのことを指すし、NFC Tagの「NFC」がRF層的な意味を表すならばこれらに以下の製品らが加わってくる。
- MIFARE Classic 1K / 4K
- FeliCa Standard
- 各種TypeV製品
もしくはいっそ上記のうち特定の製品を指してNFC Tagだなんて呼んでいるパターンだってあるかもしれない。正直、このあたりの整理は未だ私にもついていない。要勉強。ガリガリ。
ひとまずここでは、広義(すなわちRF層的な意味)でNFC Tagを定義しておく。
このようにNFC Tagと一口に言ってもたくさん種類があって分からないよ、という状況に陥ってしまいがちなのだが、一方で2012年6月現在、日本で簡単に手に入りかつ遊べるタグというものは割と限定されていたりする。
- MIFARE Ultralight (MFUL)
- MIFARE Ultralight C (MFULC)
- NTAG203
- FeliCa Lite
- MIFARE Classic 1K
私の場合、新しく遊べるタグを手に入れたとき上に挙げたいずれかの製品であることが多い。なお、我が国でもっとも普及率が高いと思われるFeliCa Standardはユーザーが自由に書き込みできないという点(当然だ)で除外した。
これらをNFC Forum Tag的な見方で分類すると以下のようになる。
- NFC Forum Type 2 Tag : MFUL, MFULC, NTAG203
- NFC Forum Type 3 Tag : FeliCa Lite
- 非 NFC Forum Tag : MIFARE Classic 1K
今回はこのうちNFC Forum Type 2 Tagに分類される3製品にフォーカスを絞って調べてみた。
MIFARE Ultralight
データシート(PDF)がNXPのサイトで公開されている。
メモリ全体の容量は512bit(64Byte)である。MIFARE Ultralightでは4Byteひとまとめの単位であるpageでデータを扱う。この表し方だと容量は16pageということになる。
このうち、ユーザエリアは12page(48Byte/384bit)である。細かいメモリ構成を以下に示す。
Page Address | Byte number | ||||
---|---|---|---|---|---|
Decimal | Hex | 0 | 1 | 2 | 3 |
0 | 00h | serial number | |||
1 | 01h | serial number | |||
2 | 02h | Serial number | internal | lock bytes | lock bytes |
3 | 03h | OTP | OTP | OTP | OTP |
4~15 | 04~0Fh | user memory |
lock bytesではuser memory領域のロックのみならず、OTP領域(デフォルトオールビット0で、全てのビットは1に設定すると元に戻せない領域)のロックや、lock bytes自身のロックの設定ができたりするようだ。それ以外は普通の記憶媒体と捉えて問題ない。
MIFARE Ultralight C
データシート(PDF)がNXPのサイトで公開されている。
MFULの容量・機能では流石に貧弱すぎると判断されたのかどうかは分からないが、このMFULCは大分高機能である。48page(192Byte/1536bit)というMFULの3倍のメモリ容量を持ち、ユーザエリアも36page(144Byte/1152bit)に増している。さらにMFULにはなかった認証機能を持っていたりするみたいだ。細かいメモリ構成を以下に示す。
Page Address | Byte number | ||||
---|---|---|---|---|---|
Decimal | Hex | 0 | 1 | 2 | 3 |
0 | 00h | serial number | |||
1 | 01h | serial number | |||
2 | 02h | Serial number | internal | lock bytes | lock bytes |
3 | 03h | OTP | OTP | OTP | OTP |
4~39 | 04~27h | user memory | |||
40 | 28h | lock bytes | lock bytes | – | – |
41 | 29h | 16bit counter | 16bit counter | – | – |
42 | 2Ah | authentication configuration | |||
43 | 2Bh | authentication configuration | |||
44~47 | 2C~2Fh | authentication key |
前半部分を見れば分かるように、MFULと互換性のあるように設計されている。そのためかlock bytesの場所が02hと28hでとびとびになっているのが印象的である。
NTAG203
データシート(PDF)がNXPのサイトで公開されている。
NFC Forum Type 2 Tagとして、MIFARE Ultralight が採用された。しかし、そのままの製品ではあまりにもメモリ容量が少ない。MFULCもあるけれど、蛇足な機能(認証機能)がついている。ということで作られたのがNTAG203ではないだろうかと勝手に思っている。
ちなみにNTAGは「NFC Tag(NFC Forum Tag)」を意味しており203はそれぞれ、
- 2 …… プラットフォーム(Type 2?)
- 0 …… 通し番号(0番目、すなわち最初にできたという意味)
- 3 …… メモリサイズのコード(0:64Byte以下、1:64から96Byte、2:96から128Byte、3:128から256Byte)
を表している。
さて、このNTAG203、メモリ容量は42page(168Byte/1344bit)、ユーザエリアは36page(144Byte/1152bit)とスペック的にはMFULCに非常に酷似している。というかMFULCから認証部分を取り除いたらそのままNTAG203になる。一応、表に示すと以下のような感じだろうか。
Page Address | Byte number | ||||
---|---|---|---|---|---|
Decimal | Hex | 0 | 1 | 2 | 3 |
0 | 00h | serial number | |||
1 | 01h | serial number | |||
2 | 02h | Serial number | internal | lock bytes | lock bytes |
3 | 03h | OTP | OTP | OTP | OTP |
4~39 | 04~27h | user memory | |||
40 | 28h | lock bytes | lock bytes | – | – |
41 | 29h | 16bit counter | 16bit counter | – | – |
実は拡張方法についてはNFC ForumのNFC Forum Type 2 Tag技術仕様(NFC Forumのサイトからダウンロードできる)の「2.2 Dynamic Memory Structure」に載っていたりする。
内容を要約すると、MFULの時点で48Byte(12page)分はlock指定できるんだから、それ以外のところもlock指定できるようにしなくちゃならない。どのくらいのlock指定のための領域が必要かはユーザエリアのサイズに依存してて、以下の式で求められる。
必要なロックビット数 = (ユーザエリアサイズ – 48[Byte]) / 8
つまりNTAG203の場合はユーザエリアが144Byteだから上の式からlock bytes分として12bit(すなわち2Byte)必要だということが導かれる。……となると最後の16bit counter(MFULには存在しなかった)の意味であるが、これはよくわからない。おまけ?
これらをまとめると
もともとあったのが、単純な作りのMFULで、それを容量・機能で拡張したのがMFULC、NFC Forum Type 2 Tag準拠に容量を拡張したのがNTAG203といったところであろうか。
[余談]NFC Forum Type 2 Tagとして使うには
メモリ構造を見ることができるAndroidアプリ「NFC TagInfo」で調べてみた限り、「NFC Forum Type 2 Tag」として認識されるタグには共通の状態があった。すなわち、OTPエリア(page address:03h)がHEXで「E1h 10h 12h 00h」となっていたのだ。仕様との関連性を現段階でうまく説明できないが、これがMIFARE Ultralight系タグをNDEF Tagとする決まり事みたいなものなのだろうか。