在留カード等に格納されたデータを紹介してみる

はじめに

唐突ですが、持ってますか？　在留カード or 特別永住者証明書。

たぶん、保有している人はあまりいないですよね。そもそも日本国籍の人に発行されるものではありませんし。
もしかすると、見たことすらないという人も多いのかもしれません。
でも、名前くらいは聞いたことがあるのではないでしょうか。

そんなちょっとマイナーな在留カードと特別永住者証明書ですが、その中にどんなデータが格納されているのか知っている人は、恐らくほとんどいないでしょう。
券面に書かれている内容からある程度の予想はできると思いますが、そもそも券面をお目にかかる機会自体あまりないのではないでしょうか。

と言うことで、この記事では在留カードと特別永住者証明書のICチップの中にはいったいどんなデータが格納されているのか、2019/12/12現在における仕様書の内容をベースにふわっと紹介します。

なお、在留カードと特別永住者証明書から各種論理ファイルの内容を読み出すまでに関しては一切触れないので、あらかじめご了承ください。

(ちなみに上記の画像は、法務省のページから拝借してきた画像を加工したものです。)

仕様書はどこにあるのか？

法務省によって、普通にネット上に公開されています。「在留カード 仕様」とでもググればすぐに見つかるかと思います。

2019/12/12現在では、「在留カード等仕様書（一般公開用）Ver１．３」というPDFファイルが見つかります。
タイトルに「等」とあるように、特別永住者証明書の仕様もこのファイルで説明しています。

※追記(2021/04/09)
上記の仕様書へのリンクはリンク切れとなったようです。新しいリンクは以下となります。
在留カード等仕様書（一般公開用）Ver１．３

ファイルの構成

在留カードおよび特別永住者証明書には、以下のような構成の論理ファイルが入っています。
「:」以降にはファイルの内容を記載しています。

MF
├── EF01: 共通データ要素
├── EF02: カード種別
├── DF1
│　　 ├── EF01: 券面(表)イメージ
│　　 └── EF02: 顔画像
├── DF2
│　　 ├── EF01: 住居地(裏面追記)
│　　 ├── EF02: 裏面資格外活動包括許可欄
│　　 ├── EF03: 裏面資格外活動個別許可欄
│　　 └── EF04: 裏面在留期間等更新申請欄
└── DF3
　　　 └── EF01: チェックコード、公開鍵証明書

MFとDFは、Windowsのファイルシステムで例えると、それぞれ「ルートフォルダ」と「フォルダ」、EFおよびIEFは「ファイル」のようなものだと思ってください(Linux界隈の人は「フォルダ」を「ディレクトリ」に読み替えてください)。
そのため、上記のようにMFやDFの下にEFやIEFがあるような構成を取ることができます。

ファイルのデータ構造

EF01やEF02といった各ファイルの中には、タグフィールド(T)、長さフィールド(L)、値フィールド(V)の3つで構成される基本符号化TLV(BER-TLV)フォーマットのデータ(以降「TLVデータ」)が1つ以上並んでいます。

TLVデータ1			TLVデータ2			TLVデータ3			・・・
T	L	V	T	L	V	T	L	V	・・・

タグフィールドとは？

タグフィールドには、対応する値フィールドにどういったデータが格納されているのかを知るための値が入っています。要はラベルのようなものだと考えてください。
仕様書を見る限り、16進数で"C0"～"DB"となる1バイトの値が入っているようです。

例えば、「共通データ要素」のデータが入っているMF/EF01で、あるTLVデータのタグフィールドの値が"C0"であれば、対応する値フィールドには仕様バージョン番号が入っていると判断できます。

タグフィールドと値フィールドの内容の対応関係に関しては、仕様書に記載されています。

長さフィールドとは？

長さフィールドは、後述の値フィールドの長さを示します。
表現方法として、(A)～(C)の3パターンが仕様書には定義されています。

(A) 長さフィールドが"00"～"7F"

長さフィールドは、以下のようにb8(最上位ビット)が0で、続くb7～b1で0～127の整数を符号化(上位先順)する1バイトの形を取ります。
b7～b1で表現される値は、値フィールドの長さを示しています。

b8	b7～b1
0	値フィールドの長さ

このパターンの場合、読み込んだ1バイトの値を単純に10進数に変換した値が、値フィールドの長さとなります。そのため、値フィールドの長さは0("00")～127("7F")の値のいずれかとなります。

例えば、長さフィールドが16進数で"64"となる1バイトのとき、値フィールドの長さは100となります。

ちなみに、長さフィールドの1バイト目のb8が0でない場合、後述の(B)または(C)のいずれかのパターンであると判断することができます。

(B) 長さフィールドが"8100"～"81FF"

長さフィールドは、1バイト目が"81"となり、2バイト目が"00"～"FF"となります。

1バイト目	2バイト目
"81"	"00"～"FF

1バイト目の"81"は続く1バイトで長さを表現することを示しています。
2バイト目の値を10進数とした値が、値フィールドの長さとなります。そのため、値フィールドの長さは0("00")～255("FF")の値のいずれかとなります。

例えば、長さフィールドが16進数で"81FF"となる2バイトのとき、値フィールドの長さは255となります。

(C) 長さフィールドが"820000"～"82FFFF"

長さフィールドは、1バイト目が"82"となり、2バイト目と3バイト目が"00"～"FF"となります。

1バイト目	2バイト目	3バイト目
"82"	"00"～"FF	"00"～"FF

1バイト目の"82"は続く2バイトで長さを表現することを示しています。
2バイト目と3バイト目で表現される値を10進数とした値が、値フィールドの長さとなります。そのため、値フィールドの長さは0("0000")～65535("FFFF")の値のいずれかとなります。

例えば、長さフィールドが16進数で"822710"となる3バイトのとき、値フィールドの長さは10000となります。

値フィールドとは？

値フィールドは、名前の通り値が入ったフィールドです。
長さフィールドの値が"00"、すなわち値フィールドの長さが0の時、値フィールドは存在せず、長さフィールドのすぐ後に、次のTLVデータのタグフィールドが来ることになります。

値フィールドに何のデータが格納されているかは、タグフィールドの値を見ればわかります。

値がどのように符号化されているかは、値フィールドによって異なります。各値フィールドの符号化方式に関しては仕様書をご参照ください。

各ファイルの内容

各ファイルにどのような情報がどのように格納されているのか紹介します。
「共通データ要素」や「券面(表)イメージ」のようなファイルやデータの内容を示す単語は、仕様書そのままの表現としていますのでご理解ください。

分かりやすくするため、タグフィールドを青色、長さフィールドを赤色、値フィールドを緑色とした、16進数で表現することとします。

共通データ要素

MF/EF01には共通データ要素が格納されています。これは在留カード・特別永住者証明書共通のデータです。
具体的には、仕様バージョン番号のみが格納されています。

仕様バージョン番号は、その名の通り対応する仕様のバージョン番号です。仕様のどのバージョンに則ったデータが格納されているのかを示しているものと思われます。

TLVデータは、例えば以下のようになります。

C00430303031

"C0"は仕様バージョン番号であることを、"04"は値フィールドの長さが4であることを示しています。

値フィールドをJIS X 0201に基づいて変換していくと、以下のようになります。

"30"	"30"	"30"	"31"
0	0	0	1

仕様書によると、0001、0002、0003、・・・と世代管理を行う予定らしいです。

カード種別

MF/EF02にはカード種別が格納されています。これは在留カード・特別永住者証明書共通のデータです。
具体的には、カード種別のみが格納されています。

カード種別は読んで字の通りカードの種類を示すもので、この値を用いてカードが在留カードなのか特別永住者証明書なのか判別することができます。

TLVデータは、例えば以下のようになります。

C10131

"C1"はカード種別であることを、"01"は値フィールドの長さが1であることを示しています。

値フィールドをJIS X 0201に基づいて変換すると、カード種別として「1」を得られます。
仕様書によると1は在留カードであることを示すとあるので、このカードは在留カードであるものと判断できます。

ちなみに、特別永住者証明書の場合は「2」(TLVデータは"C10132")となります。

券面(表)イメージ

MF/DF1/EF01には券面(表)イメージが格納されています。これは在留カード・特別永住者証明書共通のデータです。
具体的には、カード表(おもて)面に対応した画像一つのみが格納されています。

TLVデータは、以下のような形になります。

D0長さフィールド値フィールド

"D0"は券面(表)イメージであることを示しています。

詳細な具体例は挙げませんが、格納された画像データは普通のTIFFデータなので、適当にファイルに書き出して適当な画像ビューアで開けばどういった画像かはわかると思います。
ちなみに圧縮アルゴリズムはMMR(ファクシミリ互換のITU-T Group4)となっています。

得られたTIFF画像をPNGに変換すれば、以下のような画像が得られます。
なお、画像は実際に読み出した画像をベースに作成した、架空の在留カードの券面(表)画像です。
下記の例では、画像の大きさを分かりやすくするため画像の端を黒くしていますが、実際に読み出せる画像に黒線は存在しませんのでご注意ください。画像の大きさは実際に読み出してみた画像と同じにしています。

一方、出入国在留管理庁のページから拝借してきた在留カードの表面のサンプル(余白は削ってます)は以下になります。

見比べてみればわかりますが、「日本国政府」や「氏名 NAME」、「このカードは～です。」のようなすべてのカードに共通する部分以外が券面(表)イメージの画像となっているようです。顔写真も別で格納されているため、この画像には含まれません。

特別永住者証明書も読み出してみましたが、同様にカードの表面から共通している部分と顔写真を除いたものが画像として格納されているようです。

顔画像

MF/DF1/EF02には顔画像が格納されています。これは在留カード・特別永住者証明書共通のデータです。
具体的には、顔写真一つのみが格納されています。

TLVデータは、以下のような形になります。

D1長さフィールド値フィールド

"D1"は顔画像であることを示しています。

画像はJPEG2000フォーマットのカラー画像が格納されています。
余談ですが、運転免許証の場合はカード上に印刷されている顔写真はカラー画像であるのに対し、ICチップ内の画像はモノクロの画像だったりします。

仕様書には、16歳未満の中長期在留者（永住者含む）及び特別永住者に交付されるカードではこのデータはカード内に格納されない(ただし、16歳未満であっても16歳の誕生日の半年前に交付されたカードに関してはこの限りではない)旨が記載されているるため、一部のカードにはこのデータは格納されていないようです。

住居地(裏面追記)

MF/DF2/EF01には住居地(裏面追記)が格納されています。これは在留カード・特別永住者証明書共通のデータです。
具体的には、裏面に追記された住居地に関する情報が格納されています。

実際にどう言った値が格納されているのか、TLVデータの具体例を交えて紹介します。追記が行われているカードを読み出したことがないため、あまり具体的なことは書けませんが。。

追記書き込み年月日

D2080000000000000000

"D2"は"追記書き込み年月日"であることを、"08"は値フィールドの長さが8であることを示しています。

例の場合、裏面に住居地の追記が行われていないカードであるため"00"の羅列が格納されています。
住居地が追記されているカードの場合、仕様書によると"3230313230333130"のような値が格納されているようです。

ちなみに、この場合の値フィールドをJIS X 0201に基づいて変換していくと以下のようになり、2012年03月10日という年月日を得ることができます。

"32"	"30"	"31"	"32"	"30"	"33"	"31"	"30"
2	0	1	2	0	3	1	0

市町村コード

D306000000000000

"D3"は"市町村コード"であることを、"06"は値フィールドの長さが6であることを示しています。

例の場合、追記が行われていないカードであるため"00"の羅列が格納されています。
追記が行われているカードの場合、仕様書によると値フィールドには"313331303136"のような値が格納されているようです。

ちなみに、この場合の値フィールドをJIS X 0201に基づいて変換していくと以下のようになり、「131016」という東京都千代田区を示す市町村コードを得ることができます。

"31"	"33"	"31"	"30"	"31"	"36"
1	3	1	0	1	6

市町村コードの対応関係は以下のサイトを見るようにと仕様書にはありますが、リンク切れのようです。
https://www.j-lis.go.jp/code-address/jititai-code.html

恐らく、以下のリンクが新しいページだと思われます。
https://www.j-lis.go.jp/spd/code-address/jititai-code.html

住居地

D482014000......00(320バイト)

"D4"は"住居地"であることを、"820140"は値フィールドの長さが320であることを示しています。

例の場合、追記が行われていないカードであるため"00"の羅列が格納されています。
"00"の羅列以外の値が格納されたカードを読み取ったことがないため、これ以上の具体例を紹介できませんが、仕様書によるとJIS X 0213:2004によって符号化された、最大320バイトの値が格納されているとのことです。

裏面資格外活動包括許可欄

MF/DF2/EF02には裏面資格外活動包括許可欄が格納されています。これは在留カードのみのデータです。
具体的には、包括許可欄の記載内容のみが格納されています。
資格外活動包括許可が何を指すのか詳しくは把握していませんが、恐らく資格外活動の許可（入管法第19条）に関連しているのではないかと思われます。

TLVデータは、例えば以下のようになります。

D578000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

"D5"は包括許可欄記載内容であることを、"78"は値フィールドの長さが120であることを示しています。

"00"の羅列以外の値が格納されたカードを読み取ったことがないため、許可を受けた人のカードにどのような値が格納されているのかを示す具体例は紹介できませんが、仕様書によるとJIS X 0213:2004によって符号化された、最大320バイトの値が格納されているとのことです。

なお、特別永住者証明書にもこのファイルは存在するらしく、実際に読み出してみたカードでは上記の具体例のように値フィールドが"00"で埋められた形になってはいましたが、TLVデータも存在しました。
もっとも、TLVデータからは特に有意な値が取れないはずなので、このファイルを読み出すこと自体あまりしないかもしれませんが。

裏面資格外活動個別許可欄

MF/DF2/EF03には裏面資格外活動個別許可欄が格納されています。これは在留カードのみのデータです。
具体的には、個別許可欄の記載内容のみが格納されています。
資格外活動包括許可と同じく、資格外活動個別許可が何を指すのか詳しくは把握していません。

TLVデータは、例えば以下のようになります。

D678000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

"D6"は個別許可欄記載内容であることを、"78"は値フィールドの長さが120であることを示しています。

"00"の羅列以外の値が格納されたカードを読み取ったことがないため、許可を受けた人のカードにどのような値が格納されているのかを示す具体例は紹介できませんが、仕様書によるとJIS X 0213:2004によって符号化された、最大320バイトの値が格納されているとのことです。

なお、裏面資格外活動個別許可欄の場合と同様に、特別永住者証明書にもファイルが存在するようです。実際に読み出してみたカードでは上記の具体例のように値フィールドが"00"で埋められた形になってはいましたが、TLVデータも存在しました。

裏面在留期間等更新申請欄

MF/DF2/EF04には裏面在留期間等更新申請欄が格納されています。これは在留カードのみのデータです。
具体的には、在留期間更新等の許可申請を行っているかいないかを示す値のみが格納されています。

TLVデータは、例えば以下のようになります。

D70130

"D7"は在留期間更新等許可申請ステータスコードであることを、"01"は値フィールドの長さが1であることを示しています。

値フィールドをJIS X 0201に基づいて変換すると、ステータスコードとして「0」を得られます。
仕様書によると0は「無し」であることを示すとあるので、このカードの持ち主は現在申請を行っている訳ではないと判断できます。

ちなみに、申請中の場合は「1」(TLVデータは"D70131")となります。

なお、裏面資格外活動個別許可欄の場合と同様に、特別永住者証明書にもファイルが存在するようです。実際に読み出してみたカードでは"D70100"のように値フィールドが"00"になってはいましたが、TLVデータも存在しました。

チェックコード、公開鍵証明書

MF/DF3/EF01にはチェックコード、公開鍵証明書が格納されています。これは在留カード・特別永住者証明書共通のデータです。
具体的には、チェックコード及び公開鍵証明書が格納されています。

仕様書には、16歳未満の中長期在留者（永住者含む）及び特別永住者に交付されるカードではこのデータはカード内に格納されない(ただし、16歳未満であっても16歳の誕生日の半年前に交付されたカードに関してはこの限りではない)旨が記載されているため、一部のカードにはこれらのデータは格納されていないようです。

実際にどう言った値が格納されているのか、TLVデータの具体例を交えて紹介します。値フィールドの内容は適当です。

チェックコード

DA82010001234567(以下略)

"DA"はチェックコードであることを、"820100"は値フィールドの長さが256であることを示しています。

チェックコードは署名検証を行う際に使用します。詳しくは仕様書をご参照ください。

公開鍵証明書

DB82039E3082039A(以下略)

"DB"は公開鍵証明書であることを、"82039E"は値フィールドの長さが926であることを示しています。

公開鍵証明書は、X.509形式のものがCER符号化された形で格納されている旨が仕様書には記載されています。
が、実際に取り出したデータを眺めてみたところ、DERで符号化されているように見受けられました。(恥ずかしながら知人に指摘されるまで「へー、そうなんだ」くらいに考えて仕様書鵜呑みにしてました。。)

公開鍵証明書はチェックコードと同じく、署名検証を行う際に使用します。詳しくは仕様書をご参照ください。

補足1

公開鍵証明書のデータがDERで符号化されていると判断した理由は割愛しますが、CERで符号化されていないと判断した理由については一応説明しておきます。
上記の値フィールドの内容は、以下のようなTLVデータになっています。

3082039A30820282(以下略)

CERの詳細は省きますが、本当にCERで符号化されているのであれば、長さフィールドは可変長であることを示す"80"になっているはずなのですが、実際は"82039A"となっています。
この時点で、CERで符号化されていないと判断できます。

補足2

X.509（ver.3）形式 CER符号化ファイル(拡張子cer)

仕様書(Ver1.3)では、公開鍵証明書のフォーマットに関してこのように記載されています。
通常、拡張子の「.cer」は証明書(certificate)ファイルであることを意味するのであって、符号化方式がCER(Canonical Encoding Rules)であることを指すわけではないと思うのですが、どういった意図でこのような表記になっているのかは不明です。

文字の符号化

これまでしれっと登場していたJIS X 0201やJIS X 0213:2004による符号化に関してですが、一応説明しておきます。

JIS X 0201

JIS X 0201は規格名称を「7ビット及び8ビットの情報交換用符号化文字集合」と言います。
この規格の中には、0～9の数字やa～z及びA～Zのアルファベット、「*」や「?」のような記号と8ビット(1バイト)の値との対応関係が含まれます。
在留カード等のデータのうち数字のみで表現されるようなデータは、この対応関係を用いて各数字に一対一で対応する1バイトの値を並べたものを格納しています

JIS X 0213:2004

JIS X 0213:2004は、2004年改正版のJIS X 0213のことを示していると考えてください。
ちなみに、JIS X 0213は2000年に制定後、2004年と2012年に改正が行われています。

JIS X 0213は規格名称を「7ビット及び8ビットの2バイト情報交換用符号化拡張漢字集合」と言います。
JIS X 0208の文字集合(数字、ひらがな、カタカナ、漢字等)に第三・第四水準漢字等を加えた文字集合を規定しており、JIS X 0208まで用いられていた「区-点」に「面」を加え、「面-区-点」でコード表記を行います。

この規格の中には、規定された文字集合と2バイトの値との対応関係が含まれます。
が、各文字に対応するこの2バイトの値にはどうやら「面」に関する情報が含まれないらしく、この値だけではどちらの面(1面 or 2面)に含まれる文字なのか判断がつかない場合があります(2バイトの値一つが、一つまたは二つの文字に対応します)。
そのため、在留カードの住居地等にそのまま2バイトの値だけが並べられているということはなさそうな気がします。仕様書を見る限り、1文字が最大4バイトになることを想定してそうですし。

住居地等に"00"以外の具体的なデータが書き込まれたカードを読み出したことがあれば、もっと詳しく書けたかもしれませんが、残念ながらそういった機会はありませんでした。
せめて仕様書に具体例くらい書いといてくれれば。。

所感

画像として格納されている氏名や生年月日ですが、テキストデータとして取り出せた方が何かと便利だったんじゃないかと思いました。

参考文献

http://www.immi-moj.go.jp/info/pdf/120424/data_01.pdf
http://www.immi-moj.go.jp/tetuduki/zairyukanri/whatzairyu.html
http://www.immi-moj.go.jp/tetuduki/tokubetu/shomeisho.html
http://eternalwindows.jp/security/scard/scard08.html
https://ja.wikipedia.org/wiki/JIS_X_0201
https://ja.wikipedia.org/wiki/JIS_X_0208
https://ja.wikipedia.org/wiki/JIS_X_0213
https://en.wikipedia.org/wiki/X.690
https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
http://www.snap-tck.com/room03/c02/cg/cg05_01.html
http://www5d.biglobe.ne.jp/~stssk/asn1/index.html
http://shaw.la.coocan.jp/security/asn1/ber.php

似たような記事

良ければこちらもどうぞ。

• IC運転免許証に格納されたデータを紹介してみる
• ICパスポートに格納されたデータを紹介してみる