
「NFCタグをコピーしたい」と言うとき、実際には読み取り・別タグへの書き込み・完全複製(クローン)のどれを指すかが曖昧になりがちです。
本記事ではNFC Type3 Type2 コピーの可否を、規格差と権限の観点からケース別に整理します。
対象はNFC Forum Type 3 Tag(FeliCa系・NFC-F)とType 2 Tag(MIFARE Ultralight/NTAG系・NFC-A)です。
Suicaなどの交通系ICや、認証付きセキュリティカードの単純複製ができる、という誤解は避けます。
「コピーできる」は、NDEFなどのユーザーデータを別タグへ書き戻せる、という意味であることが多いです。
IDm/UIDごと、鍵ごと、認証必須領域まで含めた完全複製は、別問題として切り分けてください。
コピーを3層に分けて考える
実務では、次の3層を分けて考えます。
同じ「コピー」でも、難易度と可否が大きく変わります。
| 層 | 意味 | 典型例 |
|---|---|---|
| 読み取り | タグから見えるデータを取得する | NDEFのURL、公開ブロックの内容 |
| 別タグ書き込み | 取得した内容を、書き込み可能な別タグへ保存する | URLをNTAGへ書き直す |
| 完全複製 | 識別子・鍵・認証領域まで含めて同一に見せる | IDm/UIDごとクローンする意図 |
完全複製は、チップ製造時に固定された識別子や、鍵で保護された領域まで含む話です。
書き込み可能なユーザー領域の転記とは、結論が別になります。
Type3とType2の規格差
NFC Forumのタグ種別は、NDEFの載せ方と下位通信技術の組み合わせです。
Type 3はNFC-F(JIS X 6319-4/FeliCa互換)、Type 2はNFC-A系のメモリタグとして定義されています。
| 項目 | Type 3(FeliCa系) | Type 2(NTAG等) |
|---|---|---|
| 通信 | NFC-F | NFC-A |
| 識別子 | IDm(8バイト)+PMm | UID(NTAG21xは7バイト等) |
| メモリ単位 | 16バイトブロック+サービス | 4バイトページ/ブロック |
| NDEFの入口 | 属性情報ブロック+サービスコード | Capability Container(CC) |
| アクセス制御 | サービス属性・認証コマンド | ロックビット・パスワード等 |
この差があるため、Type3の生メモリをType2へバイト単位で移しても、同じタグにはなりません。
移植しやすいのは、両者が共通に扱えるNDEFメッセージの中身です。
IDmとUIDの違い
Type 3ではPolling応答でIDmとPMmを取得し、以降の通信相手を識別します。
SonyのFeliCa Lite-Sマニュアルでは、IDmとPMmはIC製造時に設定された値から変更できない、と明記されています。
IDm and PMm cannot be changed from the value set when the IC is manufactured.
引用:FeliCa Lite-S User’s Manual – Sony
Type 2のNTAG21xでは、製造時に書き込まれた7バイトUIDがページ0付近に置かれます。
ユーザー領域の書き換えとは別に、UID自体は製造情報として扱う前提です。
https://www.nxp.com/docs/en/data-sheet/NTAG213_215_216.pdf
したがって「データのコピー」と「識別子まで同じクローン」は同義ではありません。
多くの正規タグでは、IDmやUIDを任意の値へ書き換えて完全一致させることは想定されていません。
メモリ構造とサービスコード
Type 2はページ単位の平坦なEEPROMに近い構造です。
CC、ロックバイト、ユーザー領域が並び、NDEFはCCを起点に解釈されます。
Type 3はArea/Serviceの概念があり、読み書きはサービスコードを指定してブロックへアクセスします。
認証不要の読み取りはRead Without Encryption(コマンド06h)、書き込みはWrite Without Encryption(08h)です。
https://www.sony.net/Products/felica/business/tech-support/data/card_usersmanual_2.3e.pdf
NFC Forum Type 3 TagとしてNDEFを載せる場合、FeliCa Lite-Sでは読み取り用サービス000Bh、読み書き用0009hといったサービス属性が使われます。
NDEF対応時はSystem Code 12FChへの応答も絡むため、「ブロックを読めた=自由に全部書ける」ではありません。
認証とアクセス制御
Type 2では、静的/動的ロックビットで領域を読み取り専用へ固定できます。
NTAG21xは32ビットパスワード保護もあり、AUTH0以降のページへの不正書き込みを防げます。
Type 3/FeliCa Standardでは、認証必須サービスに対してAuthentication1/2のあとRead/Writeを使う流れがあります。
認証不要サービスだけがWithout Encryptionで扱える、という切り分けが基本です。
鍵を持たない第三者が、交通系や社員証相当の保護領域を合法に丸ごと複製できる、という前提にはなりません。
読み取れる公開情報と、保護された価値あるデータは別物です。
Type3→Type2コピーの可否
Type3からType2への移行は、プロトコル互換ではなく、内容の再配置です。
次のように整理すると判断しやすいです。
| やりたいこと | 可否の目安 | 条件・注意 |
|---|---|---|
| NDEF(URL等)の読み取り | 可能なことが多い | 相手がNDEF対応で、読み取り権限がある |
| 同じNDEFをNTAGへ書き込み | 条件付きで可能 | 容量・書き込み可・ロック未設定 |
| FeliCaのサービス構造ごと移植 | 不可に近い | Type2にサービスコード概念がない |
| IDmをUIDとして再現 | 正規用途では不可 | 識別子の体系自体が異なる |
| 認証必須領域の完全コピー | 実質不可 | 鍵と権限が必要。推測で断定しない |
具体例として、FeliCa Lite-S上のNDEFに入ったWeb URLを読み、空のNTAG216へ同じNDEFを書き直す、という用途は現実的です。
一方、元タグのIDm依存で端末や改札が動く用途は、Type2へ移しても意味がありません。
「Type3の中身をType2へコピーした」ように見えても、読めるのは共通フォーマット層のユーザーデータです。
チップ同一性の複製ではない点を押さえてください。
Type3→Type3コピーの可否
Type3同士でも、「常に完全コピーできない」「常にできる」のどちらも正確ではありません。
チップ種、サービス属性、書き込み権限、発行状態で結論が分かれます。
- 書き込み可能なNDEFタグ同士なら、NDEFメッセージの転記は可能なことが多い
- 読み取り専用へロック済み、またはROサービスしか無い場合、別タグへの書き戻しはできない
- IDm/PMmは製造時固定のため、正規タグ間で識別子まで一致させる完全クローンにはならない
- 認証必須サービスは、正当な鍵と手順が無ければ読み書きできない
- FeliCa Lite-SとFeliCa Standardではコマンド集合やセキュリティ機能が異なる
実務例としては、開発用の書き込み可能FeliCa Lite-Sから、別の未ロックLite-SへNDEFを移す、というケースは「別タグ書き込み」として成立し得ます。
ただし新しいタグのIDmは別物なので、IDmを鍵や会員IDに使っているシステムでは同一視されません。
交通系ICカードのように、残高・乗車券情報が認証付き領域で管理されるカードは、市販スマホのNDEFコピー感覚では扱えません。
ここを「Type3同士だから複製できる」と一般化しないでください。
Android・iOSでの実装と制約
モバイル実装は、NDEF共通APIと、ネイティブ技術APIの二段構えです。
ここではコピー可否の判断に効く制約だけを押さえます。
Android
AndroidはNDEFに加え、NfcA・NfcF・任意でMifareUltralightなどへ直接アクセスできます。
Type2相当はNFC-A/Ultralight系、Type3相当はNFC-F(JIS 6319-4)側で扱います。
NDEFの読み書きだけで足りるならNdef/NdefFormatableが最短です。
サービスコード単位のFeliCa操作や、ページ単位のType2操作が必要なら技術クラスへ降りてください。
端末差もあります。
すべてのAndroidが同じFeliCaコマンドやMIFARE拡張を保証するわけではありません。
iOS
iOSはCore NFCでNDEFの読み書きと、ネイティブタグアクセスを提供します。
FeliCaはNFCFeliCaTag経由で、認証不要系のwriteWithoutEncryptionやコマンド送信が可能です。
制約として、フォアグラウンドのReader Sessionが基本で、バックグラウンド常時ポーリングのような自由度はAndroidより狭いです。
FeliCa利用時はInfo.plistへ対象System Codeの宣言が必要で、ワイルドカード運用にも制限があります。
NDEF書き込みは可能でも、交通系ICの保護領域へ自由に書き込める、という意味ではありません。
OSがタグ種を見せても、カード側の権限が通らなければ失敗します。
対応可能・不可能なケース早見
迷ったときの早見です。
最終判断は、実タグのNDEF状態・ロック・サービス属性・鍵の有無で行ってください。
- 可能になりやすい: 書き込み可なType3/Type2間でのNDEF(URL・テキスト等)転記
- 条件付き: Type3同士のユーザーブロック転記(認証不要かつ書き込み可サービスがある場合)
- できない/別問題: IDmやUIDまで含めた完全クローン、認証必須領域の無鍵複製
- 誤解しやすい: Suica等の交通系ICを「NFCタグのコピー」と同じ語感で語ること
参考資料
本記事の技術判断は、次の公式・準公式資料を優先しています。
版の更新で細部が変わることがあるため、実装前に一次資料を確認してください。
- NFC Forum Type 3 Tag Specification(NFC-F/JIS X 6319-4互換のNDEF操作)
- Sony FeliCa Card User’s Manual Excerpted Edition(コマンドとIDm/サービス)
- Sony FeliCa Lite-S User’s Manual(IDm固定、NDEF向けサービス/System Code)
- NXP NTAG213/215/216 データシート(UID、ロック、パスワード)
- Android Developers Advanced NFC、Apple Core NFC(NFCFeliCaTag)
上記以外の市販ツール挙動や、エミュレータ特有の挙動は推測領域として扱い、本記事の断定対象から外しています。
まとめ
NFC Type3とType2のコピー可否は、通信方式・識別子・メモリモデル・アクセス制御が違う前提で見る必要があります。
現実的に多いのは、NDEFなど共通層のユーザーデータを、書き込み可能な別タグへ移す作業です。
Type3→Type2では構造互換のクローンは期待せず、内容の再エンコードとして考えてください。
Type3→Type3でも、権限とチップ種次第で転記はできても、IDmまで含めた完全複製にはなりません。
交通系ICや認証付きカードは、空きNFCタグの複製話と混ぜないことが安全です。
実装前はNFC Forum/Sony/NXP/OS公式の一次資料で、対象タグの書き込み条件を確認してください。
- Original:https://minory.org/nfc-type3-type2-copy.html
- Source:minory
- Author:管理者