はじめに

唐突ですが、持ってますか？　パスポート。

外務省が公開している旅券統計を見る限り、だいたい4人に1人が有効なパスポートを保有しているのではないかと思います。
私は海外旅行以外の用途では業務周りでしか使っていませんが、身分証明書として使っている人もいるかもしれません。

そんなパスポートですが、その中にどんなデータが格納されているのか知っている人は、果たしてどれだけいるでしょうか？
パスポートの顔写真等が記載されたページを見ればある程度の予想はできると思いますが、仕様書まで読んだことがある人はほとんどいないのではないでしょうか。

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

なお、ICチップを搭載していない古いパスポートに関しては、全く考慮していません。
また、パスポートから各種論理ファイルの内容を読み出すまでに関しても一切触れないので、あらかじめご了承ください。

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

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

パスポートの標準仕様はICAO(国際民間航空機関)によって制定・公開されています。
そのため、仕様書は「machine readable travel documents icao」とでもググればすぐに見つかるかと思います。

2019/12/20現在、論理ファイルに関する仕様書としては「Part 10: Logical Data Structure (LDS) for Storage of Biometrics and Other Data in the Contactless Integrated Circuit (IC)」というPDFファイルが見つかります。この時点では、「Seventh Edition, 2015」となっていました。

ファイルの構成

パスポートには、以下のような構成の論理ファイルが入っています。
「:」以降にはファイルの内容を記載しています。

MF
└── eMRTD Application
　　　 ├── EF.COM: Common Data
　　　 ├── EF.SO_D: [Document Security Object] (#document-security-object)
　　　 ├── EF.DG1: Machine Readable Zone Information
　　　 ├── EF.DG2: Encoded Identification Features — Face
　　　 ├── EF.DG3: Additional Identification Feature — Finger(s)
　　　 ├── EF.DG4: Additional Identification Feature — Iris(es)
　　　 ├── EF.DG5: Displayed Portrait
　　　 ├── EF.DG6: Reserved For Future Use
　　　 ├── EF.DG7: Displayed Signature or Usual Mark
　　　 ├── EF.DG8: Data Feature(s)
　　　 ├── EF.DG9: Structure Feature(s)
　　　 ├── EF.DG10: Substance Feature(s)
　　　 ├── EF.DG11: Additional Personal Detail(s)
　　　 ├── EF.DG12: Additional Document Detail(s)
　　　 ├── EF.DG13: Optional Details(s)
　　　 ├── EF.DG14: Security Options
　　　 ├── EF.DG15: Active Authentication Public Key Info
　　　 └── EF.DG16: Person(s) to Notify

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

仕様書を見れば他にも幾つかファイルが定義されていることわかると思いますが、本記事ではeMRTD Application以下のファイルのみ紹介することとします。
ちなみに、eMRTDは"Electronic Machine Readable Travel Document"の略です。
ICパスポート("Electronic Machine Readable Passport"または"eMRP")はeMRTDの一種という扱いになっているようです。

ファイルのデータ構造

EF.DG1やEF.DG2といった各ファイルの中には、タグフィールド(T)、長さフィールド(L)、値フィールド(V)の3つで構成されるTLVデータが格納されています。

TLVデータ
T	L	V

TLVデータは複数並べることや、

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

あるTLVデータの値フィールドに更にTLVデータが入っているような構造を取ることも可能です。

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

タグフィールドって？

タグフィールドは、対応する値フィールドにどういったデータが格納されているのかを知るための1バイト以上の値です。要はラベルのようなものだと考えてください。

例えば、タグフィールドの値が"5F1F"であれば、対応する値フィールドにはMRZ Dataが格納されているとわかります。

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

長さフィールドとは？

長さフィールドは、後述の値フィールドの長さを示す1バイト以上の値です。
以下の2パターンが存在しています。

(A) 1バイト目のb8が0の場合

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

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

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

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

(B) 1バイト目のb8が1の場合

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

b8	b7～b1
1	以降の何バイトで長さを表現するか

例えば1バイト目が"82"の場合、値フィールドの長さは以下のように2バイト目と3バイト目の計16ビットで表現される0("0000")～65535("FFFF")のいずれかの値となります。

第1バイト	第2バイト	第3バイト
"82"	16ビットで表現される値

具体例として長さフィールドが16進数で"822710"となる3バイトとしたとき、値フィールドの長さは2バイト目の値と3バイト目で表現される値を10進数に変換して10000となります。

値フィールドとは？

値フィールドは、名前の通り値が入ったフィールドです。
長さフィールドの値が"00"、すなわち値フィールドの長さが0の時、値フィールドは存在しません。

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

値フィールドにTLVデータではなく符号化されたデータ(文字列や画像等)が格納されている場合、それがどのように符号化されているかは、値フィールドによって異なります。各値フィールドの符号化方式に関しては仕様書をご参照ください。

各ファイルの内容

各ファイルにどのような情報がどのように格納されているのか紹介します。
「Common Data」や「Machine Readable Zone Information」のようなファイルやデータの内容を示す単語は、仕様書そのままの表現としていますのでご理解ください。

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

なお、以降で登場するTLVデータの具体例のうち、氏名や生年月日のように個人情報に関連するものは実際のデータを参考に作成した架空のデータとなっています。

キーワード

以降で登場するキーワード**「REQUIRED(必須である)」および「OPTIONAL(任意である)」**はRFC 2119で定義されています。

**「CONDITIONAL」**の説明は「Part 1: Introduction」に以下のようにあります。

The usage of an item is dependent on the usage of other items. It is therefore further qualified under which conditions the item is REQUIRED or RECOMMENDED. This is an additional key word used in Doc 9303 (not part of RFC 2119).

Common Data

MF/eMRTD Application/EF.COMはREQUIREDなファイルです。
このファイルには、Common Dataが格納されています。

具体的には、LDS Version Number、Unicode Version Level、Tag listと言った、パスポートから他のデータを読み出す際に知っておくべき情報が格納されています。

実際にどう言った値が格納されているのか、以下の具体例を用いて紹介します。

60165F0104303130375F36063034303030305C0461756D6F

"60"は、値フィールドの中にCommon Dataの各値が格納されていることを示し、"16"は値フィールドの長さが22であることを示します。

値フィールドをさらにTLVデータとしてパースしてみると、以下で紹介する三つのデータが並んでいることがわかります。

LDS Version Number

5F010430313037

"5F01"はLDS Version Numberであることを、"04"は値フィールドの長さが4であることを示しています。

仕様書によるとLDSは"Logical Data Structure"の略称とのことで、LDS Version Numberの値はどの時点の論理ファイルや論理ファイル内のデータ構造に対応したデータが、パスポートに格納されているのかを示しているようです。

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

"30"	"31"	"30"	"37"
0	1	0	7

得られた「0107」はバージョン1.7のことを指しているようです。

Unicode Version Level

5F3606303430303030

"5F36"はUnicode Version Levelであることを、"06"は値フィールドの長さが6であることを示しています。

Unicode Version Levelはパスポート内に格納された文字列が、Unicodeのどのバージョンに基づいて符号化されているのかを示しています。
値フィールドをUnicodeに基づいて変換していくと、以下のようになります。

"30"	"34"	"30"	"30"	"30"	"30"
0	4	0	0	0	0

得られた「040000」はUnicode 4.0.0のことを指しているようです。

Tag List

5C0461756D6F

"5C"はTag Listであることを、"04"は値フィールドの長さが4であることを示しています。

Tag Listは仕様書に定義されたData Group 1～16のうち、どのデータがパスポート内に格納されているのかを示す値です。各Data Groupに対応する1バイトのタグ番号が並べられています。

"61756D6F"の場合、Data Group1("61")、Data Group2("75")、Data Group13("6D")、Data Group15("6F")がパスポートに格納されていることを示しています。

Data Groupとタグ番号の対応関係は以下の通りです。

Data Group	タグ番号(16進数)
Data Group1	61
Data Group2	75
Data Group3	63
Data Group4	76
Data Group5	65
Data Group6	66
Data Group7	67
Data Group8	68
Data Group9	69
Data Group10	6A
Data Group11	6B
Data Group12	6C
Data Group13	6D
Data Group14	6E
Data Group15	6F
Data Group16	70

Document Security Object

MF/eMRTD Application/EF.SO_DはREQUIREDなファイルです。
このファイルにはDocument Security Objectが格納されています。

具体的には、以下のような形で値フィールドに署名値や各Data Groupのデータのハッシュ値が格納されています。

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

具体例に関しては割愛します。データ構造の詳細に関しては、仕様書をご参照ください。

Data Group 1

MF/eMRTD Application/EF.DG1はREQUIREDなファイルです。
このファイルには、Machine Readable Zone Informationが格納されています。

パスポートの顔写真等が印刷されているページの下の方には以下のような文字列が印刷されていて、この文字列が印刷されている領域をMRZ(Machine Readable Zone)と呼びます。

P<JPNTANAKA<<TAROU<<<<<<<<<<<<<<<<<<<<<<<<<<
TR12345672JPN0001018M2501017<<<<<<<<<<<<<<08

このファイルにはMRZに印刷されているものと同じ文字列がテキストデータとして格納されています(改行は含まれません)。

実際にどう言った値が格納されているのか、以下の具体例を用いて紹介します。

615B5F1F58503C4A504E54414E414B413C3C5441524F553C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C545231323334353637324A504E303030313031384D323530313031373C3C3C3C3C3C3C3C3C3C3C3C3C3C3038

"61"はMRZ Infomationの値が格納されていることを、"5B"は値フィールドの長さが91であることを示しています。

値フィールドをさらにTLVデータとしてパースしてみると、以下のようになっていることがわかります。

MRZ Data

5F1F58503C4A504E54414E414B413C3C5441524F553C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C3C545231323334353637324A504E303030313031384D323530313031373C3C3C3C3C3C3C3C3C3C3C3C3C3C3038

"5F1F"はMRZ Dataが格納されていることを、"58"は値フィールドの長さが88であることを示しています。

値フィールドに格納されている値をUnicodeに基づいて変換していくと、上述の例と同じ以下のような文字列を得ることができます。見やすいように半分の44文字で改行しています。

P<JPNTANAKA<<TAROU<<<<<<<<<<<<<<<<<<<<<<<<<<
TR12345672JPN0001018M2501017<<<<<<<<<<<<<<08

見ただけでも何となく分かると思いますが、この文字列が何を意味するのか一応紹介します。
各情報は文字数が決まっているため、決まった文字数を順番に見ていけばどんな情報が文字列に含まれているのか簡単にわかります。

Document Code

P<JPNTANAKA<<TAROU<<<<<<<<<<<<<<<<<<<<<<<<<<

1～2文字目はドキュメントの種別を示しています。
「P<」の場合、そのドキュメントがパスポートであることを意味します。

Issuing State or Organization

P<JPNTANAKA<<TAROU<<<<<<<<<<<<<<<<<<<<<<<<<<

3～5文字目は発行国を示しています。
「JPN」の場合、パスポートが日本で発行されたものであることを意味します。

Name of Holder

P<JPNTANAKA<<TAROU<<<<<<<<<<<<<<<<<<<<<<<<<<

6～44文字目は氏名を示しています。
「TANAKA<<TAROU」はパスポート所有者の姓が「TANAKA」で、名が「TAROU」であることを意味します。
姓名の間の「<<」は姓と名の区切りであることを示しています。海外で発行されたパスポートでも、姓と名は同じ並びのようです。仕様書(Part 3)に記載された例では、ミドルネームは名の方に含まれていました。
末尾の「<<<<<<<<<<<<<<<<<<<<<<<<<<」は余白です。

Document Number

TR12345672JPN0001018M2501017<<<<<<<<<<<<<<08

45～53文字目はドキュメント番号を示しています。
Document Codeが「P<」でパスポートを示しているので、「TR1234567」はパスポート番号となります。

ちなみに、有効期限が10年のパスポートは先頭が「T」で始まり、5年のパスポートは「M」で始まるようです。