サイトトップへこのカテゴリの一覧へ

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

(1) 

目 次 

ページ 

序文 ··································································································································· 1 

1 適用範囲························································································································· 1 

2 引用規格························································································································· 2 

3 用語及び定義 ··················································································································· 2 

4 記号及び略語 ··················································································································· 8 

5 コマンドレスポンス対 ······································································································ 10 

5.1 処理の条件(コマンドレスポンス対実行前の物理インタフェースを有効にする手順) ················ 10 

5.2 構文法 ························································································································ 10 

5.3 連鎖手続き ·················································································································· 11 

5.4 クラスバイト ··············································································································· 13 

5.5 コマンドバイト ············································································································ 15 

5.6 状態バイト ·················································································································· 18 

6 データオブジェクト ········································································································· 21 

6.1 簡易符号化TLVデータオブジェクト ················································································ 21 

6.2 BER-TLVデータオブジェクト ························································································· 21 

6.3 構造化DO対基本DO ···································································································· 22 

7 アプリケーション及びデータの構造 ···················································································· 22 

7.1 利用可能な構造 ············································································································ 22 

7.2 有効領域 ····················································································································· 23 

7.3 構造選択 ····················································································································· 25 

7.4 ファイル制御情報及びデータ制御情報··············································································· 28 

8 DO特有の使用法及び関連する概念····················································································· 35 

8.1 BER-TLVペイロード及びパディング ················································································ 35 

8.2 カレントテンプレート及びデータオブジェクトの世代 ·························································· 36 

8.3 データ要素及びデータオブジェクトの識別 ········································································· 37 

8.4 DO及びデータ要素の参照及び読出し ··············································································· 40 

9 セキュリティ機構 ············································································································ 44 

9.1 共通事項 ····················································································································· 44 

9.2 暗号機構識別子テンプレート ·························································································· 45 

9.3 セキュリティ属性 ········································································································· 46 

9.4 セキュリティ支援データ要素 ·························································································· 63 

10 セキュアメッセージング ································································································· 64 

10.1 SMフィールド及びSM DO ··························································································· 64 

10.2 基本SM DO ··············································································································· 66 

10.3 補助SM DO ··············································································································· 69 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 目次 

(2) 

ページ 

10.4 コマンドレスポンス対へのSMの影響 ············································································· 74 

11 情報交換のためのコマンド ······························································································ 76 

11.1 選択 ·························································································································· 76 

11.2 データ単位の扱い ········································································································ 80 

11.3 レコードの扱い ··········································································································· 84 

11.4 データオブジェクトの扱い ···························································································· 94 

11.5 基本セキュリティの扱い ······························································································ 105 

11.6 その他 ······················································································································ 116 

11.7 伝送用コマンドの扱い ································································································· 118 

12 アプリケーション非依存のカードサービス ········································································ 119 

12.1 カード識別 ················································································································ 119 

12.2 アプリケーション識別及び選択 ····················································································· 125 

12.3 パスによる選択 ·········································································································· 129 

12.4 データ読出し ············································································································· 130 

12.5 カード創生バイト列 ···································································································· 130 

12.6 一般的特徴管理 ·········································································································· 131 

12.7 APDU管理 ················································································································ 133 

附属書A(参考)オブジェクト識別子及びタグ割付け体系の例···················································· 134 

附属書B(参考)セキュアメッセージングの例 ········································································· 137 

附属書C(参考)GENERAL AUTHENTICATEコマンドによる認証機能の例································· 145 

附属書D(参考)発行者識別番号を使用するアプリケーション識別子 ··········································· 153 

附属書E(参考)BER符号化規則·························································································· 154 

附属書F(参考)BER-TLVデータオブジェクトの扱い ······························································ 156 

附属書G(参考)タグ付ラッパによるテンプレート拡張 ···························································· 164 

附属書H(参考)対象DOに対する拡張ヘッダの分析 ······························································· 168 

参考文献 ··························································································································· 170 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

(3) 

まえがき 

この規格は,工業標準化法第14条によって準用する第12条第1項の規定に基づき,一般社団法人日本

ICカードシステム利用促進協議会(JICSAP)及び一般財団法人日本規格協会(JSA)から,工業標準原案

を具して日本工業規格を改正すべきとの申出があり,日本工業標準調査会の審議を経て,経済産業大臣が

改正した日本工業規格である。 

これによって,JIS X 6320-4:2009は改正され,この規格に置き換えられた。 

この規格は,著作権法で保護対象となっている著作物である。 

この規格に従うことは,次の者の有する特許権等の使用に該当するおそれがあるので,留意する。 

− 氏名:株式会社東芝 

− 住所:東京都港区芝浦1丁目1-1 

− 特許番号:JPN 2033906,JPN 2137026,JPN 2537199,JPN 2557838,JPN 2831660,JPN 2856393 

− 氏名:Orga Kertensysteme Gmbh 

− 住所:Am Hoppenhof 33 D-33104 Paderborn Germany 

− 特許番号:DE 198 55 596 

上記の,特許権等の権利者は,非差別的かつ合理的な条件でいかなる者に対しても当該特許権等の実施

の許諾等をする意思のあることを表明している。ただし,この規格に関連する他の特許権等の権利者に対

しては,同様の条件でその実施が許諾されることを条件としている。 

この規格に従うことが,必ずしも,特許権の無償公開を意味するものではないことに注意する必要があ

る。 

この規格の一部が,上記に示す以外の特許権等に抵触する可能性がある。経済産業大臣及び日本工業標

準調査会は,このような特許権等に関わる確認について,責任はもたない。 

なお,ここで“特許権等”とは,特許権,出願公開後の特許出願又は実用新案権をいう。 

JIS X 6320の規格群には,次に示す部編成がある。 

JIS X 6320-1 第1部:外部端子付きICカードの物理的特性 

JIS X 6320-2 第2部:外部端子付きICカードの端子の寸法及び位置 

JIS X 6320-3 第3部:外部端子付きICカードの電気的インタフェース及び伝送プロトコル 

JIS X 6320-4 第4部:情報交換のための構成,セキュリティ及びコマンド 

JIS X 6320-5 第5部:アプリケーション提供者識別子の登録 

JIS X 6320-6 第6部:交換のための産業間共通データ要素 

JIS X 6320-8 第8部:セキュリティ処理コマンド 

JIS X 6320-9 第9部:カード管理共通コマンド 

JIS X 6320-11 第11部:バイオメトリクスを用いた本人確認 

JIS X 6320-13 第13部:マルチアプリケーション環境におけるアプリケーション管理用コマンド 

JIS X 6320-15 第15部:暗号情報アプリケーション 

日本工業規格          JIS 

X 6320-4:2017 

(ISO/IEC 7816-4:2013) 

識別カード−ICカード−第4部: 

情報交換のための構成,セキュリティ及びコマンド 

Identification cards-Integrated circuit cards- 

Part 4: Organization, security and commands for interchange 

序文 

この規格は,2013年に第3版として発行されたISO/IEC 7816-4[Corrigendum 1(2014)を含む。]を基

に,技術的内容及び構成を変更することなく作成した日本工業規格である。 

なお,この規格で点線の下線を施してある参考事項は,対応国際規格にはない事項である。 

適用範囲 

この規格は,全ての活動分野でこの規格が使用されることを目的とし,次のことを規定する。 

− カードのインタフェースで交換されたコマンドレスポンス対の内容 

− カードのデータ要素及びデータオブジェクトの読出し手段 

− カードの動作特性について記述する管理情報バイトの構造及び内容 

− コマンドを処理するときに,カードのインタフェース上に現れるカードのアプリケーション及びデー

タの構造 

− カードのファイル及びデータのアクセス方法 

− カードのファイル及びデータにアクセスする権限を定義するセキュリティ機構 

− カードのアプリケーションを識別し指定するための手段及び機構 

− セキュアメッセージングの方法 

− カードによって処理される暗号化アルゴリズムへのアクセス方法。これらのアルゴリズムについては,

規定しない。 

この規格は,ICカードの内部実装又はICカードにアクセスする外部装置については規定しない。 

この規格は,物理的インタフェース技術には依存せず,外部端子付きのICカード,外部端子なしの密着

結合型ICカード,及び非接触型(近接型及び近傍型)のICカードに適用する。カードが二つ以上の物理

インタフェースの同時使用を可能とする場合,異なる物理インタフェース間で発生する事象との関係は,

この規格の適用範囲外である。 

注記 この規格の対応国際規格及びその対応の程度を表す記号を,次に示す。 

ISO/IEC 7816-4:2013,Identification cards−Integrated circuit cards−Part 4: Organization, security 

and commands for interchange(IDT) 

なお,対応の程度を表す記号“IDT”は,ISO/IEC Guide 21-1に基づき,“一致している”こ

とを示す。 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

引用規格 

次に掲げる規格は,この規格に引用されることによって,この規格の規定の一部を構成する。これらの

引用規格のうちで,西暦年を付記してあるものは,記載の年の版を適用し,その後の改正版(追補を含む。)

は適用しない。西暦年の付記がない引用規格は,その最新版(追補を含む。)を適用する。 

JIS X 6320-3 識別カード−ICカード−第3部:外部端子付きICカードの電気的インタフェース及び

伝送プロトコル 

注記 対応国際規格:ISO/IEC 7816-3,Identification cards−Integrated circuit cards−Part 3: Cards with 

contacts−Electrical interface and transmission protocols(IDT) 

JIS X 6320-6 ICカード−第6部:交換のための産業間共通データ要素 

注記 対応国際規格:ISO/IEC 7816-6,Identification cards−Integrated circuit cards−Part 6: Interindustry 

data elements for interchange(IDT) 

ISO/IEC 8825-1:2002,Information technology−ASN.1 encoding rules: Specification of Basic Encoding Rules 

(BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) 

注記 対応するJISとしてJIS X 5606-1:1998があったが2015年6月に廃止された。また,この国

際規格の2002年版に未対応であることから,国際規格を引用した。 

用語及び定義 

この規格で用いる主な用語及び定義は,次による。 

なお,対応国際規格で細分箇条の番号3.51を重複して使用しているため,3.52を含む以降の細分箇条の

番号を,一つずつずらした。 

3.1 

アクセス規則(access rule) 

実行前に関連するアクセスモード及び実行前に満足しているセキュリティ条件を含むデータ要素。 

3.2 

リセット応答ファイル(Answer-to-Reset file) 

カードの動作特性を示す任意選択のEF。情報ファイルとしても知られている。 

3.3 

アプリケーション(application) 

特定の機能実行のために必要な構造,データ要素及びプログラムモジュール。 

3.4 

アプリケーションDF(application DF) 

カードのアプリケーションを収める専用ファイル(DF)。 

3.5 

アプリケーション識別子(application identifier) 

アプリケーションを識別する16バイト以内のデータ要素。 

3.6 

アプリケーションラベル(application label) 

マンマシンインタフェースで使用するデータ要素。 

3.7 

アプリケーション提供者(application provider) 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

カード内アプリケーションの構成要素を提供するエンティティ。 

3.8 

アプリケーションテンプレート(application template) 

一つのアプリケーション識別子データオブジェクトを含む,アプリケーションに関連するデータオブジ

ェクトの集合。 

3.9 

非対称暗号技術(asymmetric cryptographic technique) 

二つの関連する処理(公開の数値又は公開鍵で定義された公開処理,及びプライベートの数値又はプラ

イベート鍵で定義されたプライベート処理)を用いる暗号技術。 

注記 2種類の処理は,公開処理は与えられるが,プライベート処理を導き出すことは計算上実行不

可能という特性をもっている。 

3.10 

基礎テンプレート(base template) 

間接参照し解決した結果のDOを除いた構造化データオブジェクトの値フィールド。 

3.11 

証明書(certificate) 

特定の人又はオブジェクト,及びその関連する公開鍵を結び付けるディジタル署名が付いた文書(証明

書)。 

注記 証明書を出すエンティティは,さらに,証明書内のデータ要素に関してのタグ割付け機関の役

割を果たす。 

3.12 

コマンドレスポンス対(command-response pair) 

カードのインタフェース上に現れる二つのメッセージの対。コマンドAPDUとこれに続く逆方向からの

レスポンスAPDUとからなる。 

3.13 

コマンド連鎖(command chaining) 

連続するコマンドレスポンス対の複数のコマンドデータを一括して処理しなければならないとカードに

連絡するために,カードの外部世界によって使用される手段。 

3.14 

状況依存クラス(context-specific class) 

先頭バイトの値又は1バイトのときは,その値が“80”〜“BF”のタグのクラス。 

このクラスのタグは用いられるデータオブジェクトに応じて,各タグのもつ意味付けが異なる。 

3.15 

カレントテンプレート(current template) 

交換のためのコマンド中のタグで直接参照するデータオブジェクトの連続,すなわち,カレントの構造

化DOの値フィールド(仮想の構造化であってもよい。)。 

3.16 

データ要素(data element) 

名前,論理的内容の識別子,構成及び符号化方法が特定された,インタフェース上に現れる情報項目。 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

3.17 

データオブジェクト(data object) 

カードのインタフェース上に現れる,必須のタグフィールド,必須の長さフィールド及び条件付きの値

フィールドの連結からなる情報。 

3.18 

データ単位(data unit) 

データ単位を採用するEF内で,明示的に参照することができるビットの最も小さい集合。 

3.19 

専用ファイル(dedicated file) 

ファイル制御情報と任意選択として割付け利用可能なメモリとを含んでいる構造。 

3.20 

DF名(DF name) 

カードのDFを一意に識別する16バイト以内のデータ要素。 

3.21 

ディジタル署名(digital signature) 

対象とするデータ列の原本性及び完全性を証明し,(例えば,データ受領者による)偽造に対して保護す

るために,そのデータ列に追加されるデータ,又はそのデータ列を暗号によって変換したもの。 

3.22 

ディレクトリファイル(directory file) 

カードが提供するアプリケーションと任意選択として関連するデータ要素とのリストを含んでいる任意

選択であるEF。 

3.23 

基礎ファイル(elementary file) 

同一ファイル識別子を共有するデータオブジェクト,レコード,又はデータ単位の集合。 

3.24 

拡張ヘッダ(extended header) 

構造化DOの中で一つ以上のDOを参照するデータ要素。 

3.25 

拡張ヘッダリスト(extended header list) 

拡張ヘッダを連結したもの。 

3.26 

ファイル(file) 

コマンドを処理するときに,カードのインタフェース上に現れる,カード内のアプリケーション及び/

又はデータのための構造。 

3.27 

ファイル識別子(file identifier) 

ファイルを指定するために使用される2バイトのデータ要素。 

3.28 

ヘッダリスト(header list) 

タグフィールド及び長さフィールドの対を区切りなく連鎖したもの。 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

3.29 

情報ファイル(information file) 

リセット応答ファイルとして知られている,カードの動作特性を示す任意選択のEF。 

3.30 

産業間共通利用(interindustry) 

JIS X 6320規格群 [6] で規格化され,産業間で共通に使用可能であること。 

3.31 

内部EF(internal EF) 

カードが解釈し実行するデータを格納するEF。 

3.32 

鍵(key) 

暗号の処理(例えば,署名生成,署名検証,動的認証におけるプライベート又は公開処理,暗号化,復

号)を制御するシンボルの列。 

3.33 

主ファイル(master file) 

DFの階層構造を用いているカードでファイル構成の根幹となる唯一のDF。 

3.34 

オフセット(offset) 

データ単位を提供するEFでデータ単位の相対位置を示す数値,又はレコードでバイトの相対位置を示

す数値。 

3.35 

オーバサイズペイロード(oversize payload) 

1回のAPDUで送信することができず,複数の連続するAPDUによって送られるコマンドデータ又はレ

スポンスデータ。 

注記 対応国際規格では,“APDUのカレントサイズの制約を超えるペイロード”としているが,5.3.2

によって定義文を変更した。 

3.36 

親ファイル(parent file) 

DF階層構造において,そのファイルの直上にあるDF。 

3.37 

パスワード(password) 

アプリケーションが必要とすることのある,認証目的で利用者がカードに提示するデータ。 

3.38 

パス(path) 

区切りのないファイル識別子の連結。 

3.39 

ペイロード(payload) 

一括して処理するためにカードへ,又はカードから送られる任意長のデータ。 

3.40 

プライベート鍵(private key) 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

エンティティの非対称鍵対のうち,そのエンティティだけによって使用されるのが望ましい鍵。

(ISO/IEC 9798-1 [10] 参照)。 

3.41 

提供者(provider) 

カードにDFを作成する権限をもつか,又はその権限を与えられた者。 

3.42 

公開鍵(public key) 

エンティティの非対称鍵対のうち,公にされて使用される鍵(ISO/IEC 9798-1 [10] 参照)。 

3.43 

レコード(record) 

レコード形式のEFで,カードによって参照され取り扱われるバイト列。 

3.44 

レコード識別子(record identifier) 

レコード形式のEFで,一つ以上のレコードを参照するために使用される数値。 

3.45 

レコード番号(record number) 

レコード形式のEFで,一意に各レコードを識別する連続する数。 

3.46 

アプリケーション提供者識別子(registered application provider identifier) 

一意にアプリケーション提供者を識別する5バイトのデータ要素。 

3.47 

リセットコード(resetting code) 

カウンタ値を修正するためにカードへ提示するデータ。 

3.48 

レスポンス連鎖(response chaining) 

GET RESPONSEコマンドの連続するコマンドレスポンス対によって読み出される一連のレスポンスデ

ータが一括して処理されるべきであることを,カードの外部世界に連絡するために,カードによって使用

される手段。 

3.49 

秘密鍵(secret key) 

対称暗号技術を用いて,指定された一組のエンティティによって使用される鍵(ISO/IEC 11770-3 [17] 参

照)。 

3.50 

セキュアメッセージング(secure messaging) 

コマンド及びその応答に対して,その一部又は全体を暗号によって保護するための方法。 

3.51 

セキュリティ属性(security attribute) 

格納されたデータ及びデータ処理機能を含むカードのオブジェクトの使用条件であって,一つ以上のア

クセス規則を含むデータ要素として表されるもの。 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

3.52 

セキュリティ環境(security environment) 

セキュアメッセージング又はセキュリティ処理のために,カードのアプリケーションが要求する構成要

素の集合。 

3.53 

自己制御DO(self-controlled DO) 

セキュリティ属性を入れ子にしているDO“62”を,少なくとも入れ子にする構造化DO。 

3.54 

短縮EF識別子(short EF identifier) 

基礎ファイルを指定するために使用される5ビットのデータ要素。 

3.55 

構造(structure) 

DF,EF,レコード,データ列,又はDO。 

3.56 

対称暗号技術(symmetric cryptographic technique) 

発信者及び受信者の双方の処理で同じ秘密鍵を使用する暗号技術(秘密鍵なしで,一方の処理を計算す

ることは実行困難である方法)。 

3.57 

タグリスト(tag list) 

区切りのないタグフィールドの連結。 

3.58 

タグ付ラッパ(tagged wrapper) 

他のDOを局所的に参照するために付加されたタグを提供するラッパ。 

3.59 

テンプレート(template) 

構造化BER-TLVデータオブジェクトの値フィールドを形成するBER-TLVデータオブジェクトの連結。 

3.60 

テンプレート拡張(template extension) 

間接参照の自動解決によって得られる構造化DOの値フィールドの部分。 

3.61 

一時的選択(transient selection) 

(本体で使用していないため定義を削除し,用語の和訳だけの記載とした。) 

3.62 

一時的VA(transient VA) 

DOを扱うコマンドの実行中に一時的に設定される有効領域(VA)。 

3.63 

ユーザ(user) 

カード所持者とも呼ばれているカード使用者。 

3.64 

有効領域(validity area) 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

ある論理チャネルで選択が実行されたときに成功した全ての選択の結果。 

3.65 

仮想根幹DO(virtual root DO) 

ファイル,レコード又はDOを扱うデータ列の選択によって処理の対象にされた仮想の構造化DO“7F70”。 

3.66 

ラッパ(wrapper) 

DOを参照するDOの連結。 

3.67 

作業用EF(working EF) 

カードが解釈しない外部データを格納するEF(3.31参照)。 

3.68 

カレント(current) 

現在,実行可能な状態にあること。 

注記 この規格の中で多用している用語であることから,規格利用者の理解の一助とするために追加

した。 

記号及び略語 

この規格では,次の記号及び略語表記を用いる。 

AID 

アプリケーション識別子(application identifier) 

AMB 

アクセスモードバイト(access mode byte) 

AMF 

アクセスモードフィールド(access mode field) 

APDU 

アプリケーション プロトコルデータ単位(application protocol data unit) 

ARR 

アクセス規則参照(access rule reference) 

ASN.1 

抽象構文記法1(abstract syntax notation one)(ISO/IEC 8825-1参照) 

AT 

認証制御参照テンプレート(control reference template for authentication) 

ATR 

リセット応答(Answer-to-Reset) 

BER 

ASN.1の基本符号化規則(basic encoding rules of ASN.1)(ISO/IEC 8825-1参照) 

CCT 

暗号化チェックサム制御参照テンプレート(control reference template for cryptographic 

checksum) 

CLA 

クラスバイト(class byte) 

CRT 

制御参照テンプレート(control reference template) 

CT 

機密性制御参照テンプレート(control reference template for confidentiality) 

CP 

制御パラメタ(ファイル制御パラメタ又はデータオブジェクト制御パラメタ) 

[control parameter (file control parameter or data object control parameter)] 

CP DO 

制御パラメタBER-TLVデータオブジェクト(control parameter BER-TLV data object) 

C-RP 

コマンドレスポンス対(command-response pair) 

DF 

専用ファイル(dedicated file) 

DIR 

ディレクトリ(directory) 

DO 

BER-TLVデータオブジェクト(BER-TLV data object) 

DO“...” 

引用符で囲まれた16進数の値のタグのBER-TLVデータオブジェクト 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

(BER-TLV data object the tag of which is an hexadecimal value given between simple quotes) 

DST 

ディジタル署名制御参照テンプレート(control reference template for digital signature) 

EF 

基礎ファイル(elementary file) 

EF.ARR 

アクセス規則参照ファイル(access rule reference file) 

EF.ATR/INFO リセット応答ファイル又は情報ファイル(Answer-to-Reset file, or Information file) 

EF.DIR 

ディレクトリファイル(directory file) 

FCI 

ファイル制御情報(file control information) 

FCP 

ファイル制御パラメタ(file control parameter)  

FMD 

ファイル管理データ(file management data) 

HT 

ハッシュコード制御参照テンプレート(control reference template for hash-code) 

ICC 

ICカード(integrated circuit card) 

INS 

コマンドバイト(instruction byte) 

KAT 

鍵共有制御参照テンプレート(control reference template for key agreement) 

Lc field 

長さの値Ncを符号化して設定するためのフィールド(length field for coding the number Nc) 

LCS 

ライフサイクル状態バイト(life cycle status byte) 

Le field 

長さの値Neを符号化して設定するためのフィールド(length field for coding the number Ne) 

MF 

主ファイル(master file) 

Nc 

コマンドデータフィールドのバイト数(number of bytes in the command data field) 

Ne 

レスポンスデータフィールドに期待されている最大バイト数 

(maximum number of bytes expected in the response data field) 

Nr 

レスポンスデータフィールドのバイト数(number of bytes in the response data field) 

OID 

ISO/IEC 8825-1によって定義されているオブジェクト識別子 

(object identifier, as defined by ISO/IEC 8825-1) 

PIX 

個別利用アプリケーション拡張識別子(proprietary application identifier extension) 

P1-P2 

パラメタバイト(ダッシュは,連結を示す。)(parameter bytes) 

RFU 

ISO/IEC JTC 1/SC 17が将来使用するために予約 

(reserved for future use by ISO/IEC JTC 1/SC 17) 

RID 

アプリケーション提供者登録識別子(registered application provider identifier) 

SC 

セキュリティ条件(security condition) 

SCB 

セキュリティ条件バイト(security condition byte) 

SCQL 

構造化カード照会言語(structured card query language) 

SE 

セキュリティ環境(security environment) 

SEID 

セキュリティ環境識別子(security environment identifier) 

SM 

セキュアメッセージング(secure messaging) 

SPT 

セキュリティパラメタテンプレート(security parameter template) 

SW1-SW2 

状態バイト(ダッシュは,連結を示す。)(status bytes) 

TLV 

タグ・長さ・値(tag, length, value) 

{T-L-V} 

データオブジェクト(ダッシュは,連結を示す。)(data object) 

VA 

有効領域(validity area) 

“XY” 

16進数の表記,“0”〜“9”又は“A”〜“F”を用いる。X及びYは,必ずしも同一文字で

10 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

はない。 

コマンドレスポンス対 

5.1 

処理の条件(コマンドレスポンス対実行前の物理インタフェースを有効にする手順) 

カードとカード外部との間の物理インタフェースは,コマンドレスポンス対の処理を行うことを可能な

状態にしておかなければならない。可能化の方法は,インタフェース側での固有の手順による。次に挙げ

る規格の二重引用符で挟んだ語彙が,各物理インタフェースに対応した可能化の方法を定義している。 

− JIS X 6320-3は,“端子の活性化”,“コールドリセット”又は“ウォームリセット”を定義するととも

に,可能ならば“プロトコル及びパラメタ選択”を定義する。 

− ISO/IEC 7816-12は,USB仕様への参照で端子の“電気的接続”,デバイスの“構成”及び“初期化”,

並びに“ATR”を定義する。 

− JIS X 6322 [18] (全ての部)は,近接型(非接触式)ICカードを“ACTIVE”状態に設定する方法を定

義する。 

また,これらの規格は,物理インタフェースを無効にする手順と状況とを定義する。無効にされた物理

インタフェースは,コマンドレスポンス対の処理を行ってはならない。 

5.2 

構文法 

表1は,コマンドレスポンス対(C-RP),すなわち,コマンドAPDUとその後に逆方向へ続くレスポン

スAPDUとを示す(JIS X 6320-3参照)。インタフェースで複数のC-RP同士を挟み込んではならない。す

なわち,別のC-RPを開始する前に,レスポンスAPDUを受け取らなければならない。 

Lc及びLeフィールド(JIS X 6320-3参照)を両方とももつ全てのコマンドAPDUにおいて,短縮長さフ

ィールド及び拡張長さフィールドを混在して使用してはならない。両方とも短縮又は両方とも拡張とする。 

管理情報バイト(12.1.1参照)又はEF.ATR/INFO(12.2.2参照)の内容として“拡張Lcフィールド及び

Leフィールド”(表119参照)を扱う能力を備えているということを明確に示すカードの場合には,短縮

及び拡張の長さフィールドを両方とも扱う。その他の場合(省略時値)は,カードは短縮長さフィールド

だけを扱う。5バイト超のコマンドAPDUでは,P2の後の最初のバイトが“00”であることによって,拡

張長さフィールドが使われていることを示す。 

Ncは,コマンドデータフィールドのバイト数を示す。Lcフィールドは,次の方法でNcを符号化する。 

− Lcフィールドが存在しない場合,Ncは0とする。 

− 短縮Lcフィールドは,1バイトとし“00”に設定しない。その1バイトが“01”〜“FF”の場合,Nc

は1〜255である。 

− 拡張Lcフィールドは,3バイトとする。先頭1バイトには“00”を設定し,続く2バイトは“0000”

には設定しない。その2バイトは,“0001”〜“FFFF”の場合,Ncは1〜65 535である。 

background image

11 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表1−コマンドレスポンス対(C-RP) 

フィールド 

説明 

バイト数 

方向 

コマンドヘッダ 

クラスバイト(CLA) 

カードへ 

コマンドバイト(INS) 

パラメタバイト(P1-P2) 

Lcフィールド 

Nc=0のとき存在しない。 
Nc>0のとき存在する。 

0,1又は3 

コマンドデータフ
ィールド 

Nc=0のとき存在しない。 
Nc>0のとき連続したNcバイトとして存在する。 

Nc 

Leフィールド 

Ne=0のとき存在しない。Ne>0のとき存在する。 

0,1,2又は3 

レスポンスデータ
フィールド 

Nr=0のとき存在しない。 
Nr>0のとき連続したNrバイトとして存在する。 

Nr 

(最大値はNe) 

カードから 

レスポンス終端 

状態バイト(SW1-SW2) 

Neは,レスポンスデータフィールドのデータ構造と関係なく,期待されているレスポンスデータフィー

ルドの最大バイト数を示す。Leフィールドは,次の方法でNeの値を符号化する。 

− Leフィールドが存在しない場合,Neは0とする。 

− 短縮Leフィールドは,1バイトの任意の値で構成する。 

− “01”〜“FF”の値で,1〜255のNeを符号化する。 

− “00”に設定される場合,Neは256とする。 

− 拡張Leフィールドは,Lcフィールドが存在しない場合3バイト(先頭1バイトを“00”に設定し,後

続する2バイトを任意の値に設定),又は拡張Lcフィールドが存在する場合2バイト(任意の値に設

定)で構成する。 

− “0001”〜“FFFF”の値で,1〜65 535のNeを符号化する。 

− “0000”に設定される場合,Neは65 536とする。 

Nrは,レスポンスデータフィールドのバイト数を示す。Nrは,Ne以下でなければならない。したがって,

任意のC-RPで,Leフィールドが存在しない場合には,レスポンスデータフィールドを受け取らない。Le

フィールドが全て“00”に設定された場合,Neは最大値とする。すなわち,短縮Leフィールドでは256

の範囲以内,又は拡張Leフィールドでは65 536の範囲で全ての送信可能なバイトを返すことが望ましい。 

プロセスが中断する場合,カードは無応答になってもよい。ただし,レスポンスAPDUを返す場合,レ

スポンスデータフィールドは存在してはならない。また,SW1-SW2は誤りを示さなればならない。 

P1-P2は,コマンドを処理するための制御及び任意選択機能を示す。“00”に設定されたパラメタバイト

P1又はP2は,詳細情報を提供しない。パラメタバイトを符号化するための他の規定はない。 

CLA(5.4参照)で示すクラスバイト,INS(5.5参照)で示すコマンドバイト,及びSW1-SW2(5.6参

照)で示す状態バイトの符号化は,次に規定する。それらのバイトで,RFUビットは,別段の定めがない

限り0に設定しなければならない。 

5.3 

連鎖手続き 

5.3.1 

一般 

連鎖手続きは,ペイロード分割の提供のため,又は複数の連続するC-RPを一括して処理するプロセス

のために用いる。 

12 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

5.3.2 

ペイロード分割 

コマンドペイロードは,一括して処理するために,カードへ送られる任意の長さのデータとする。レス

ポンスペイロードは,要求されたとおりカードから受け取る任意長のデータとする。ペイロードがオーバ

サイズペイロード,すなわち,ペイロードがデータフィールドの利用可能な長さよりも大きい場合(注記

を参照),ペイロードを伝送するのに連鎖することが必要となる。 

− コマンドの連鎖は,オーバサイズのコマンドペイロードをカードに伝送する機能を提供する。ペイロ

ードは,サイズ制限に従った複数のコマンドデータフィールドに分割される。 

− レスポンスの連鎖は,オーバサイズのレスポンスペイロードをカードから受け取る機能を提供する。

ペイロードは,サイズ制限に従った複数のレスポンスデータフィールドに分割される。 

受信側は,ペイロードを回復するために連続的に伝送される分割を連結しなければならない。 

注記 APDU構文は,データフィールドのサイズを制限する。より大きいサイズ制限を用いてもよい

(12.7.1参照)。Leフィールド(“0000”又は“000000”)がNe=“010000”を示す場合,全ての

要求情報は,65 536バイト以内で返すことが望ましい。コマンドペイロードが255バイトを超

える及び/又はレスポンスペイロードが256バイトを超える場合,短縮フォーマットの長さフ

ィールドでは,分割が発生する。ペイロードがサイズ制限に従う場合,拡張形式の長さフィー

ルドでは,分割が発生しないほうがよい(12.7.1参照)。 

5.3.3 

コマンド連鎖 

ここでは,連続したC-RPを連鎖できる産業間共通利用クラス(CLA<“80”,表2及び表3参照)にお

ける機構を規定する。カードがこの機構を提供する場合,カードは管理情報バイト(12.1.1参照)内,又

はEF.ATR/INFO(12.2.2参照)内にある機構(表119参照)で示さなければならない。 

注記 ここの内容は,伝送プロトコルとは独立している。JIS X 6320-3は,プロトコルT=0を用いる

ときの連鎖について説明している。 

産業間共通利用クラスで連鎖するために,CLAのビットb5が使用される。他の7ビットは一定とする。 

− ビットb5が0に設定される場合,コマンドは,連鎖の最後又は連鎖なしのコマンドとする。 

− ビットb5が1に設定される場合,コマンドは,連鎖の最後のコマンドではない。 

この機構は,次のとおり使用してもよい。 

− オーバサイズのコマンドペイロードを伝えるために, 

− ビットb5を除いて,コマンドの全てのCLAバイトが同じでなければならない(上述を参照)。 

− ビットb5が1に設定される場合,Leフィールドは存在しない。 

− ビットb5が0に設定される場合,Leフィールドは存在してもよい。 

− コマンドの全てのINS P1 P2バイトが同じでなければならない。 

− この規格の他のところで明記している方法に従う(附属書Cの例を参照)。 

− 数個の連続したC-RPを含む,アプリケーションで定義された処理のために, 

− CLAのビットb5は,上述で定義したとおり,使用されなければならない。 

− CLAによって示された論理チャネルは,同じでなければならない。 

− コマンドのINS P1 P2バイトの値の制約はない。 

この規格では,一度開始したC-RPの連鎖が,連鎖の一部ではないC-RPを開始する前に終了するカード

の動作を規定する。この条件が守られない場合,カードの動作は,この規格の範囲外とするが,カードの

仕様として記載してもよい。 

連鎖の最後のコマンドでないコマンドへのレスポンスで,“9000”を設定されたSW1-SW2は,プロセス

background image

13 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

がそこまで完了したことを意味する。警告表示は,5.6に規定する。さらに,次の特定の誤りが生じること

がある。 

− SW1-SW2が“6883”に設定される場合,連鎖の最後のコマンドが期待されている。 

− SW1-SW2が“6884”に設定される場合,コマンド連鎖を提供しない。 

5.3.4 

レスポンス連鎖 

SW1=“61”及びGET RESPONSEコマンドは,レスポンスペイロードのオーバサイズ伝送を提供する。 

− レスポンス連鎖に関係したコマンドのCLAバイトは,全て同じでなければならない。定義によって,

SW1が“61”に設定されている場合,レスポンス連鎖のC-RPを開始する。 

− 連鎖の最初のコマンドAPDUを除いて,全てのコマンドAPDUのINS P1-P2バイトは“C0 00 00”(GET 

RESPONSE)でなければならない。 

− コマンド連鎖と同じく,ペイロード伝送は,GET RESPONSEコマンドと異なるC-RP又は他の論理チ

ャネルのC-RPによっても中断されなければならない。 

− コマンド連鎖とは逆に,データの交換は,普通に任意のC-RPを続行することが望ましいが,カード

の外部世界が十分なデータを受け取ったと考えるとき,正常終了することができる。 

− この規格は,カードの外部世界がレスポンス連鎖を再開しようとする(例えば,別の論理チャネルに

おけるコマンドの実行後に再開する。)場合のカードの動作を定義しない。カードの動作は,アプリケ

ーションで定義してもよい。 

アプリケーションで定義される場合,レスポンス連鎖は,必須というわけではないが,データの有用性

をチェックするのに使用してもよい。カードは,レスポンスデータを送らずに,SW1 SW2=“61XY”によ

る有用性を示してもよい。カードの外部世界は,GET RESPONSEコマンドを送っても,送らなくてもよい。 

図1においてc=0及びc=1は,CLAのビットb5の値を示す。Lc maxは,ICCが提供する短縮又は拡張

Lcフィールドの最大値を示す。 

警告 これは,接続装置が,カードが提供する最も長いコマンドデータフィールドを送り,カードによって利用可能

にされた全てのデータを回復することを選択した例である。両方の選択のいずれも必須ではない。 

図1−コマンド連鎖を使用してオーバサイズのコマンドペイロードをカードへ伝送,それに続いて 

レスポンス連鎖を使用してオーバサイズのレスポンスペイロードをカードから伝送 

5.4 

クラスバイト 

5.4.1 

符号化 

CLAは,コマンドのクラスを示す。CLAのビットb8は,産業間共通利用クラス及び個別利用クラスを

区別する。 

− 0に設定されたビットb8は,産業間共通利用クラスを示す。 

background image

14 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− 1に設定されたビットb8は,JIS X 6320-3の規定で無効としている値“FF”を除いて,個別利用クラ

スを示す。個別利用クラスを用いるアプリケーションが,個別利用クラスCLAの他のビットを定義す

る。 

値000x xxxx及び01xx xxxxは,次で規定する。値001x xxxxは,ISO/IEC JTC 1/SC 17が将来使用する

ために予約している。 

表2は,第一の産業間共通利用値として000x xxxxを規定する。 

− ビットb8,b7及びb6は,000に設定する。 

− ビットb5は,コマンド連鎖を制御する(5.3.3参照)。 

− ビットb4及びb3は,セキュアメッセージングを示す(箇条10参照)。 

− ビットb2及びb1は,0〜3の論理チャネル番号を符号化する(5.4.2参照)。 

表2−第一のCLAの産業間共通利用値 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − コマンド連鎖制御(5.3.3参照) 

− − − − − コマンド連鎖の最後又は連鎖なしのコマンド 

− − − − − コマンド連鎖途中のコマンド 

− 

− − セキュアメッセージング指示 

− 

− − − 非セキュアメッセージング,又は指示なし。 

− 

− − − 個別利用セキュアメッセージング書式 

− 

− − − 箇条10に従ったセキュアメッセージング,10.2.3.1に

従ったコマンドヘッダの処理が行われない。 

− 

− − − 箇条10に従ったセキュアメッセージング,10.2.3.1に

従ってコマンドヘッダが認証される。 

− − − 

0〜3の論理チャネル番号(5.4.2参照) 

表3−第二のCLAの産業間共通利用値 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − セキュアメッセージング指示 

− − − − − − 非セキュアメッセージング又は指示なし。 

− − − − − − 箇条10に従ったセキュアメッセージング,10.2.3.1に

従ったコマンドヘッダの処理が行われない。 

− 

− − − − コマンド連鎖制御(5.3.3参照) 

− 

− − − − − コマンド連鎖の最後又は連鎖なしのコマンド 

− 

− − − − − コマンド連鎖途中のコマンド 

− − 

4〜19の論理チャネル番号(5.4.2参照) 

表3は,第二の産業間共通利用値として01xx xxxxを規定する。 

− ビットb8及びb7は,01に設定する。 

− ビットb6は,セキュアメッセージングを示す(箇条10参照)。 

− ビットb5は,コマンド連鎖を制御する(5.3.3参照)。 

ビットb4〜b1は,0〜15の数を符号化する。この数に4を加えた値は,4〜19の論理チャネル番号とす

る(5.4.2参照)。 

15 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

5.4.2 

論理チャネル 

ここでは,C-RPが,論理チャネルを参照することができる産業間共通利用クラスにおける機構を規定す

る。各論理チャネルは,自身のセキュリティステータス(9.3参照)及び自身の有効領域(7.2参照)をも

っている。セキュリティステータスを共有する方法は,この規格の範囲外とする。 

カードがこの機構を提供する場合,管理情報バイト(12.1.1参照)内,又はEF.ATR/INFO(12.2.2参照)

内で利用可能な論理チャネルの最大の数(表119参照)を示す。 

− 示された数が4以下の場合,表2だけを適用する。 

− 示された数が5以上の場合,表3も適用する。 

産業間共通利用クラスでの論理チャネルの参照に,次の規則を適用する。 

− CLAは,C-RPの論理チャネル番号を符号化する。 

− 物理インタフェース(5.1参照)を活性化すると,基本論理チャネルが開かれ,物理インタフェースを

無効にするまで開いた状態が維持される。チャネルは,後述する方法でリセットしてもよい。基本論

理チャネル番号は0とする。 

− 追加の論理チャネルを提供しない(省略時値)カードは,基本論理チャネルだけを使用する。 

− 基本論理チャネル以外の追加の論理チャネルを開くには,未使用の論理チャネル番号を符号化した

CLAで指定したSELECTコマンド若しくはSELECT DATAコマンド(11.1.1及び11.4.2参照),又は

チャネルを開く機能のMANAGE CHANNELコマンド(11.1.2参照)のいずれかの完了による。 

− チャネルを閉じる機能をもつMANAGE CHANNELコマンド(11.1.2参照)の完了によって基本論理

チャネル以外の追加の論理チャネルを閉じることができる。閉じた後,その論理チャネルは再使用可

能である。 

− 二つ以上の論理チャネルが開かれている場合において,C-RPの挟み込みはしてはならない(5.2参照)。 

− ファイル記述子バイト(表11のビットb7参照)によって共用を明示的に除外していない場合,同じ

構造(箇条7参照),すなわち,DF,場合によってアプリケーションDFに対して,さらに,場合に

よってはEFに対して,複数の論理チャネルを開いてもよい。 

− データ記述子バイト(表13のビットb7参照)によって共用を明示的に除外していない場合,複数の

論理チャネルで同じDOを開いてもよい。 

− 論理チャネルは,MANAGE CHANNELコマンドのリセット機能(11.1.2参照)の完了によってリセッ

トできる。 

5.5 

コマンドバイト 

INSは,処理されるコマンドを示す。JIS X 6320-3の規定によって,値“6X”及び“9X”は無効とする。 

表4は,この規格の発行時にJIS X 6320 [6] 規格群で規定する全てのコマンドの一覧を示す。 

− 表4.1は,一覧をコマンド名のアルファベット順に示す。 

− 表4.2は,一覧をINSコードの数値順にINSコードを示す。 

JIS X 6320 [6] 規格群は,産業間共通利用クラスでのコマンドの使用を規定する。 

− この規格は,交換のためのコマンド(箇条11参照)を規定する。 

− ISO/IEC 7816-7は,構造化カード照会言語(SCQL)のためのコマンドを規定する。 

− JIS X 6320-8は,セキュリティ処理のためのコマンドを規定する。 

− JIS X 6320-9は,カード管理のためのコマンドを規定する。 

− JIS X 6320-13は,マルチアプリケーション環境のアプリケーション管理のためのコマンドを規定す

る。 

background image

16 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

産業間共通利用クラスでは,INSのビットb1が,次のデータフィールドの書式を示す。 

− ビットb1が0(偶数INSコード)に設定される場合には,指定しない。 

− ビットb1が1(奇数INSコード)に設定される場合には,ペイロードは,BER-TLV符号化(8.1参照)

を適用しなければならない。 

表4.1−アルファベット順のコマンド一覧 

コマンド名 

INS 

参照先a) 

ACTIVATE FILE 

“44” 

第9部 

ACTIVATE RECORD(S) 

“08” 

11.3.9 

APPEND RECORD 

“E2” 

11.3.6 

APPLICATION MANAGEMENT REQUEST 

“40”,“41” 

第13部 

CHANGE REFERENCE DATA 

“24”,“25” 

11.5.7 

COMPARE 

“33” 

11.6.1 

CREATE FILE 

“E0” 

第9部 

DEACTIVATE FILE 

“04” 

第9部 

DEACTIVATE RECORD(S) 

“06” 

11.3.10 

DELETE DATA 

“EE” 

第9部 

DELETE FILE 

“E4” 

第9部 

DISABLE VERIFICATION REQUIREMENT 

“26” 

11.5.9 

ENABLE VERIFICATION REQUIREMENT 

“28” 

11.5.8 

ENVELOPE 

“C2”,“C3” 

11.7.2 

ERASE BINARY 

“0E”,“0F” 

11.2.7 

ERASE RECORD(S) 

“0C” 

11.3.8 

EXTERNAL (/MUTUAL) AUTHENTICATE 

“82” 

11.5.4 

GENERAL AUTHENTICATE 

“86”,“87” 

11.5.5 

GENERATE ASYMMETRIC KEY PAIR 

“46”,“47” 

第8部 

GET ATTRIBUTE 

“34”,“35” 

11.6.2 

GET CHALLENGE 

“84” 

11.5.3 

GET DATA/GET NEXT DATA 

“CA”/“CC” 

11.4.3 

GET DATA/GET NEXT DATA 

“CB”/“CD” 

11.4.4 

GET RESPONSE 

“C0” 

11.7.1 

INTERNAL AUTHENTICATE 

“88” 

11.5.2 

LOAD APPLICATION 

“EA”,“EB” 

第13部 

MANAGE CHANNEL 

“70” 

11.1.2 

MANAGE DATA 

“CF” 

第9部 

MANAGE SECURITY ENVIRONMENT 

“22” 

11.5.11 

PERFORM BIOMETRIC OPERATION 

“2E”,“2F” 

第8部 

PERFORM SCQL OPERATION 

“10” 

Part 7 

PERFORM SECURITY OPERATION 

“2A”,“2B” 

第8部 

PERFORM TRANSACTION OPERATION 

“12” 

Part 7 

PERFORM USER OPERATION 

“14” 

Part 7 

PUT DATA 

“DA”,“DB” 

11.4.6 

PUT NEXT DATA 

“D8”,“D9” 

11.4.7 

READ BINARY 

“B0”,“B1” 

11.2.3 

READ RECORD(S) 

“B2”,“B3” 

11.3.3 

REMOVE APPLICATION 

“EC”,“ED” 

第13部 

RESET RETRY COUNTER 

“2C”,“2D” 

11.5.10 

SEARCH BINARY 

“A0”,“A1” 

11.2.6 

background image

17 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表4.1−アルファベット順のコマンド一覧(続き) 

コマンド名 

INS 

参照先a) 

SEARCH RECORD 

“A2” 

11.3.7 

SELECT 

“A4” 

11.1.1 

SELECT DATA 

“A5” 

11.4.2 

TERMINATE CARD USAGE 

“FE” 

第9部 

TERMINATE DF 

“E6” 

第9部 

TERMINATE EF 

“E8” 

第9部 

UPDATE BINARY 

“D6”,“D7” 

11.2.5 

UPDATE DATA 

“DE”,“DF” 

11.4.8 

UPDATE RECORD 

“DC”,“DD” 

11.3.5 

VERIFY 

“20”,“21” 

11.5.6 

WRITE BINARY 

“D0”,“D1” 

11.2.4 

WRITE RECORD 

“D2” 

11.3.4 

− 産業間共通利用クラスで,JIS X 6320 [6] 規格群の対応国際規格であるISO/IEC 7816 [6] 

規格群に定義されなかった全ての有効なINSコードは,将来利用するためにRFUとす
る。ただし,ISO/IEC 7816-7は,現時点ではJIS X 6320規格群 [6] には含まれないので,
Part 7として記す。 

注a) “参照先”欄で記載する規格類は,次による。 

− “X.X.X”は,この規格の細分箇条を示す(例 11.3.9)。 
− “第…部”は,JIS X 6320規格群 [6] を示す(例 第9部)。 
− “Part…”は,ISO/IEC 7816規格群を示す(例 Part 7)。 

表4.2−コマンド符号順のコマンド一覧 

INS 

コマンド名 

参照先a) 

“04” 

DEACTIVATE FILE 

第9部 

“06” 

DEACTIVATE RECORD(S) 

11.3.10 

“08” 

ACTIVATE RECORD(S) 

11.3.9 

“0C” 

ERASE RECORD(S) 

11.3.8 

“0E”,“0F” 

ERASE BINARY 

11.2.7 

“10” 

PERFORM SCQL OPERATION 

Part 7 

“12” 

PERFORM TRANSACTION OPERATION 

Part 7 

“14” 

PERFORM USER OPERATION 

Part 7 

“20”,“21” 

VERIFY 

11.5.6 

“22” 

MANAGE SECURITY ENVIRONMENT 

11.5.11 

“24”,“25” 

CHANGE REFERENCE DATA 

11.5.7 

“26” 

DISABLE VERIFICATION REQUIREMENT 

11.5.9 

“28” 

ENABLE VERIFICATION REQUIREMENT 

11.5.8 

“2A”,“2B” 

PERFORM SECURITY OPERATION 

第8部 

“2C”,“2D” 

RESET RETRY COUNTER 

11.5.10 

“2E”,“2F” 

PERFORM BIOMETRIC OPERATION 

第8部 

“33” 

COMPARE 

11.6.1 

“34”,“35” 

GET ATTRIBUTE 

11.6.2 

“40”,“41” 

APPLICATION MANAGEMENT REQUEST 

第13部 

“44” 

ACTIVATE FILE 

第9部 

“46”,“47” 

GENERATE ASYMMETRIC KEY PAIR 

第8部 

“70” 

MANAGE CHANNEL 

11.1.2 

“82” 

EXTERNAL (/MUTUAL) AUTHENTICATE 

11.5.4 

background image

18 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表4.2−コマンド符号順のコマンド一覧(続き) 

INS 

コマンド名 

参照先a) 

“84” 

GET CHALLENGE 

11.5.3 

“86”,“87” 

GENERAL AUTHENTICATE 

11.5.5 

“88” 

INTERNAL AUTHENTICATE 

11.5.2 

“A0”,“A1” 

SEARCH BINARY 

11.2.6 

“A2” 

SEARCH RECORD 

11.3.7 

“A4” 

SELECT 

11.1.1 

“A5” 

SELECT DATA 

11.4.2 

“B0”,“B1” 

READ BINARY 

11.2.3 

“B2”,“B3” 

READ RECORD(S) 

11.3.3 

“C0” 

GET RESPONSE 

11.7.1 

“C2”,“C3” 

ENVELOPE 

11.7.2 

“CA”/“CC” 

GET DATA/GET NEXT DATA 

11.4.3 

“CB”/“CD” 

GET DATA/GET NEXT DATA 

11.4.4 

“CF” 

MANAGE DATA 

第9部 

“D0”,“D1” 

WRITE BINARY 

11.2.4 

“D2” 

WRITE RECORD 

11.3.4 

“D6”,“D7” 

UPDATE BINARY 

11.2.5 

“D8”,“D9” 

PUT NEXT DATA 

11.4.7 

“DA”,“DB” 

PUT DATA 

11.4.6 

“DC”,“DD” 

UPDATE RECORD 

11.3.5 

“DE”,“DF” 

UPDATE DATA 

11.4.8 

“E0” 

CREATE FILE 

第9部 

“E2” 

APPEND RECORD 

11.3.6 

“E4” 

DELETE FILE 

第9部 

“E6” 

TERMINATE DF 

第9部 

“E8” 

TERMINATE EF 

第9部 

“EA”,“EB” 

LOAD APPLICATION 

第13部 

“EE” 

DELETE DATA 

第9部 

“EC”,“ED” 

REMOVE APPLICATION 

第13部 

“FE” 

TERMINATE CARD USAGE 

第9部 

− 産業間共通利用クラスで,JIS X 6320 [6] 規格群の対応国際規格であるISO/IEC 7816 [6] 

規格群に定義されなかった全ての有効なINSコードは,将来利用するためにRFUとす
る。ただし,ISO/IEC 7816-7は,現時点ではJIS X 6320規格群 [6] には含まれないので,
Part 7として記す。 

注a) “参照先”欄で記載する規格類は,次による。 

− “X.X.X”は,この規格の細分箇条を示す(例 11.3.10)。 
− “第…部”は,JIS X 6320規格群 [6] を示す(例 第9部)。 
− “Part…”は,ISO/IEC 7816規格群を示す(例 Part 7)。 

5.6 

状態バイト 

SW1-SW2は処理状態を示す。JIS X 6320-3の規定によって,“6XXX”及び“9XXX”と異なる全ての値

は無効とする。同じく,“60XX”となる全ての値も無効とする。 

“61XX”,“62XX”,“63XX”,“64XX”,“65XX”,“66XX”,“68XX”,“69XX”,“6AXX”及び“6CXX”

の値は,共通に使用される。JIS X 6320-3の規定によって,“67XX”,“6BXX”,“6DXX”,“6EXX”,“6FXX”

及び“9XXX”の値は,“6700”,“6701”,“6702”,“6B00”,“6D00”,“6E00”,“6F00”及び“9000”の共

通に使用される値を除いて,個別に使用される。 

background image

19 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

図2は,SW1-SW2に対する値“9000”及び“61XX”〜“6FXX”の構造的体系を示す。 

図2−SW1-SW2の値の構造的体系 

SW1-SW2の全ての産業間共通利用値は,伝送プロトコルから独立している。表5は,SW1-SW2の全て

の産業間共通利用値を記載し,それらの一般的な意味を示す。ISO/IEC JTC 1/SC 17は,JIS X 6320 [6] 規

格群の中で定義されていないSW1-SW2の全ての産業間共通利用値を将来使用するために予約する。表6

は,この規格の発行時点でJIS X 6320 [6] 規格群で使用している特定の産業間共通利用の警告及び誤り条件

を全て示している。 

表5−SW1-SW2の産業間共通利用値の一般的な意味 

SW1-SW2 

意味 

正常処理 

“9000” 

詳細情報なし。 

“61XX” SW2が,有効な数のデータバイトを符号化する(この表の次の記載を参照)。 

警告処理 

“62XX” 不揮発性メモリの状態は変化していない(詳細情報は,SW2に示す。表6参照)。 

“63XX” 不揮発性メモリの状態は変化しているかもしれない(詳細情報は,SW2に示す。表6参照)。 

実行誤り 

“64XX” 不揮発性メモリの状態は変化していない(詳細情報は,SW2に示す。表6参照)。 

“65XX” 不揮発性メモリの状態は変化しているかもしれない(詳細情報は,SW2に示す。表6参照)。 

“66XX” セキュリティ関連の誤り(SW2の詳細情報は,RFU)。 

検査誤り 

“67XX” 長さ誤り(詳細情報はSW2に示す。表6参照)。 

“68XX” CLAで示される機能は提供しない(詳細情報は,SW2に示す。表6参照)。 

“69XX” 不許可のコマンド(詳細情報は,SW2に示す。表6参照)。 

“6AXX” パラメタP1-P2が,誤っている(詳細情報は,SW2に示す。表6参照)。 

“6B00” パラメタP1-P2が,誤っている(11.2.2参照)。 

“6CXX” Leフィールドが,誤っている。SW2は,実際の有効データバイト長さを符号化する(この

表の次の文章を参照)。 

“6D00” 命令コードを提供していないか又は不正。 

“6E00”  クラスを提供していない。 

“6F00” 

詳細な診断情報なし。 

SW1が“61”に設定される場合には,プロセスは完了している。他のコマンドを発行する前にGET 

RESPONSEコマンドを,残りの有効バイト数を示すSW2を短縮Leフィールドの値として用いて同じCLA

で発行してもよい。“61XY”を返したC-RPが拡張長さフィールドを使用した場合,GET RESPONSEコマ

ンドは,DO“7F66”(12.7.1参照)に明記されたバッファサイズに従った拡張Leフィールドの値を使用し

てもよい。この特徴は,レスポンス連鎖に使用される(5.3.4参照)。 

SW1が“6C”に設定される場合には,プロセスは中断している。他のコマンドを発行する前に同じコマ

ンドを,実際の有効データバイト数を示すSW2を短縮Leフィールドの値として用いて再発行してもよい。 

SW1-SW2 

正常処理 

“9000”及び“61XX” 

警告処理 

“62XX”及び“63XX”

実行誤り 

“64XX”〜“66XX” 

検査誤り 

“67XX”〜“6FXX” 

処理中断 

処理完了 

background image

20 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

プロセスが“64”〜“6F”のSW1の値で中断する場合には,レスポンスデータフィールドは存在しない。 

SW1が“63”又は“65”に設定される場合には,不揮発性メモリの状態は変化しているかもしれない。

SW1が“63”及び“65”を除いて“6X”に設定される場合には,不揮発性メモリの状態は変化していない。 

ペイロード分割によってコマンド連鎖が使用されるとき(5.3.3参照),連鎖の最終コマンド(5.3.3参照)

でないコマンドに対するレスポンスでは,産業間共通利用の警告を禁止する(JIS X 6320-3も参照)。すな

わち,SW1は“62”及び“63”のいずれにも設定してはならない。 

表6−産業間共通利用の警告及び誤り条件 

SW1 

SW2 

意味 

“62” 

(警告) 

“00” 

情報なし。 

“02”〜“80” カードによるトリガ(12.5.1参照) 

“81” 

出力データに異常がある。 

“82” 

Neバイトを読み出す前にファイル若しくはレコードの終端に達した,又
は検索に失敗した。 

“83” 

選択したファイルが,閉塞している。 

“84” 

ファイル又はデータ制御情報が,7.4に従った書式になっていない。 

“85” 

選択したファイルが,終了状態 

“86” 

カードのセンサから利用可能な入力データがない。 

“87” 

参照レコードのうち,少なくとも一つは非活性化されている。 

“63” 

(警告) 

“00” 

情報なし。 

“40” 

比較失敗(正確な意味は,コマンドによって異なる。)。 

“81” 

今回の書込みによって,ファイルが,一杯になった。 

“CX” 

カウンタ値が,“X”によって0〜15に符号化されている(正確な意味は,
コマンドによって異なる。)。 

“64” 

(誤り) 

“00” 

実行誤り,情報なし。 

“01” 

カードが,即時応答を要求。 

“02”〜“80” カードによるトリガ(12.5.1参照) 

“81” 

論理チャネル共用アクセスが否定された。 

“82” 

論理チャネル開始が否定された。 

“65” 

(誤り) 

“00” 

情報なし。 

“81” 

メモリ誤り 

“66” 

(誤り) 

“00” 

情報なし,他の値はRFU。 

“67” 

(誤り) 

“00” 

情報なし。 

“01” 

コマンドAPDU形式がこの規格に対応していない(5.1参照)。 

“02” 

Lcの値は期待されたものではない。 

“68” 

(誤り) 

“00” 

情報なし。 

“81” 

指定された論理チャネルを提供していない。 

“82” 

セキュアメッセージング機能を提供していない。 

“83” 

連鎖の最終コマンドが期待されている。 

“84” 

コマンド連鎖を提供していない。 

“69” 

(誤り) 

“00” 

情報なし。 

“81” 

ファイル構造と矛盾したコマンドが,使用された。 

“82” 

セキュリティ状態が,満足されていない。 

“83” 

認証方法を受け付けない。 

“84” 

参照データが,使用不可能。 

“85” 

使用条件が,満足されていない。 

“86” 

カレントEFが存在しないため,コマンドの実行は許されていない。 

background image

21 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表6−産業間共通利用の警告及び誤り条件(続き) 

SW1 

SW2 

意味 

“69” 

(誤り) 

“87” 

期待されたセキュアメッセージングDOがない。 

“88” 

セキュアメッセージングDOが正しくない。 

“6A” 

(誤り) 

“00” 

情報なし。 

“80” 

コマンドデータフィールドのパラメタが正しくない。 

“81” 

機能を提供していない。 

“82” 

ファイル又はアプリケーションが,見つからない。 

“83” 

レコードが,見つからない。 

“84” 

ファイル内のメモリ領域が,足りない。 

“85” 

NcとTLV構造とが,矛盾している。 

“86” 

パラメタP1-P2が,正しくない。 

“87” 

NcとパラメタP1-P2とが,矛盾している。 

“88” 

参照データが見つからない(正確な意味は,コマンドによって異なる。)。 

“89” 

ファイルは,既に存在している。 

“8A” 

DF名は,既に存在している。 

− SW2の他の値は,RFUとする。 

データオブジェクト 

ここでは,2種類のデータオブジェクトである簡易符号化TLVデータオブジェクト及びBER-TLVデー

タオブジェクトを規定する(以下,データオブジェクトをDOという。)。 

6.1 

簡易符号化TLVデータオブジェクト 

簡易符号化TLVデータオブジェクトは,二つ又は三つの連続するフィールド(必須のタグフィールド,

必須の長さフィールド及び条件付きの値フィールド)で構成する。レコード(11.3.1参照)は簡易符号化

TLVデータオブジェクトであってもよい。 

− タグフィールドは,1〜254のタグ番号を符号化する1バイトで構成する。値“00”及び“FF”は,タ

グフィールドでは無効とする。レコードが簡易符号化TLVデータオブジェクトの場合には,タグはレ

コード識別子として用いてもよい。 

− 長さフィールドは,1バイト又は連続する3バイトで構成する。 

− 先頭バイトが“FF”でない場合は,長さフィールドは,0〜254のNで示された数を符号化する1

バイトからなる。 

− 先頭バイトが“FF”に設定される場合には,長さフィールドは,0〜65 535のNで示された数を符

号化する任意の値をとる後続2バイトで構成される。 

− Nが0の場合には,値フィールドはない。すなわち,データオブジェクトは,空とする。その他の場

合(N>0)は,値フィールドは,連続するNバイトで構成する。 

注記 この規格は,簡易符号化TLVデータオブジェクトのタグ値も値フィールドも定義しない。した

がって,簡易符号化TLVデータオブジェクトアドレシングを交換に使うことができない。 

6.2 

BER-TLVデータオブジェクト 

BER-TLVデータオブジェクト(DO)は,二つ又は三つの連続するフィールド(必須のタグフィールド,

必須の長さフィールド及び条件付きの値フィールド)で構成する(ISO/IEC 8825-1のASN.1基本符号化規

則を参照)。空でないDOは,{T-L-V}と表記する。 

タグフィールドは,連続する1バイト以上で構成する。クラス及び符号化を示し,タグ番号を符号化す

22 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

る。タグフィールドの先頭バイトで値“00”は無効とする。JIS X 6320規格群 [6] は,1,2及び3バイトの

タグフィールドを提供する。これよりも長いタグは,RFUとする。 

長さフィールドは,ISO/IEC 8825-1に従って長さ(すなわち,Nで示された数)を符号化する。Nが0

の場合には,値フィールドはない。すなわち,DOは空とし,{T-“00”}と表記する。その他の場合(N>

0)は,値フィールドは,連続するNバイトで構成し,DOは{T-L-V}と表記する。 

JIS X 6320規格群 [6] は, 

a) DER符号化規則によって規定された“不定長(符号“80”)”を使用しない。 

b) DER符号化規則(ISO/IEC 8825-1参照)に従って,長さフィールドは可能な限り短い符号化を使用す

ることを推奨する。 

c) 1〜5バイトまでの長さフィールドを使用する。それ以上の長いフィールドは,RFUとする。 

注記1 長さフィールドの長さを確かめるために,規定は,推奨b)(すなわち,与えられた長さの符

号化で最も短い長さフィールドを使用する。)を必須としてもよい。 

注記2 この規格は,拡張ヘッダDO(8.4.5参照)の長さフィールドで特殊な意味で“80”を使用す

る。 

注記3 附属書Eにタグフィールド及び長さフィールドの詳細な符号化を示す。 

6.3 

構造化DO対基本DO 

構造化された空でないDOは,{T-L-{T1-L1-V1}…{Tn-Ln-Vn}}と表記する。このタグTは,値フィール

ドの構造を示す(附属書E参照)。この値フィールドは,テンプレートと呼ばれ,次のいずれかで構成さ

れる。 

− 一つのDOで構成(構造化DOで“入れ子”にされたといわれるDO) 

− 入れ子にされた数個のDO(上記の例のn個のDO)のパディング(8.1.1参照)なしの連結で構成 

別段の規定[例えば,ラッパ(8.4.8参照)又はタグ付ラッパ(8.4.9参照),JIS X 6320-15,ISO/IEC 24727 [23]]

がない限り,テンプレート内のDOの順序は,この規格では定義しない。 

タグの1バイト目で基本又は構造化データオブジェクトを識別する方法については,附属書Eを参照す

る。基本データオブジェクトの値フィールドの取り得る構造は,ほかのところで定義する。 

アプリケーション及びデータの構造 

7.1 

利用可能な構造 

ここでは,産業間共通利用クラスでコマンドを処理する場合にインタフェース上に現れるアプリケーシ

ョンとデータの構造とを規定する。ここに記載していないデータ及び構造に関する情報の実際の記憶位置

は,JIS X 6320規格群 [6] では規定しない。次に示す構造を,提供する。 

− 専用ファイル(DF) 

DFは,アプリケーション及び/又はファイルをまとめ,及び/又はDOを格納する。アプリケーショ

ンDFは,アプリケーションを格納するDFとする。DFは,構造のタイプが{DF,EF,DO}に属し

ている他の構造物の親であってもよい。これらの他の構造物は,DF直下に存在する。 

− 基礎ファイル(EF) 

EFは,データを格納する。EFは,構造のタイプが{DO,レコード,データ列}の組合せに属してい

る他の構造物の親であってもよい。これらの他の構造物は,EF直下に存在する。2種類のEFを規定

する。 

− 内部EFは,カードによって解釈されるデータ(すなわち,管理と制御との目的のためにカードに

background image

23 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

よって使用されるデータ)を格納する。 

− 作業用EFは,カードによって解釈されないデータ(すなわち,全て外部で使用されるデータ)を

格納する。 

− レコード 

レコードは,データを格納する。レコードは,構造のタイプがDOの組合せに属している他の構造物

の親であってもよい。これらの他の構造物は,レコード直下に存在する。 

− データ列 

データ列は,データを格納する。データ列は,透過構造EFのバイト連続とする。データ列は,構造

のタイプがDOの組合せに属している他の構造物の親であってもよい。これらの他の構造物は,デー

タ列直下に存在する。 

− データオブジェクト(DO) 

DOは,データを格納する。DOは,構造のタイプがDOの組合せに属している他の構造物の親であっ

てもよい。これらの他の構造物は,DO直下に存在する。 

2種類の論理的な構成が存在する。 

− 図3は,対応するセキュリティ機構をもつDFの階層を示す(箇条9参照)。そのようなカード構成で

は,ファイル構成の根幹となるDFが主ファイル(MF)と呼ばれる。全てのDFは,アプリケーショ

ンDFであってもよいが,その場合,自身の階層をもってもよいしもたなくてもよい。 

MF

EF

EF

EF

EF

EF

EF

DF

DF

DF

DF

アプリケーションファイル

アプリケーション DF

アプリケーションファイル

図3−DFの階層構造の例 

− 図4は,インタフェース上にMFが現れない並列のアプリケーションDF(すなわち,明白な階層のな

いDF)を示す。そのような構造は,カードの中で独立なアプリケーションを提供する。どのような

アプリケーションDFでも,対応するセキュリティ機構をもつアプリケーションDF自身の階層をも

っていてもよい。 

図4−独立しているアプリケーションDFの例 

7.2 

有効領域 

7.2.1 

定義及び属性 

論理チャネルの有効領域(VA)は,その論理チャネルで実行し成功した全ての選択の結果とする。VA

は,この規格の旧規格で既に定義されたカレントファイルの概念を広げている。VAは,DOタグ及びファ

アプリケーション 

DF 

アプリケーション 

DF 

アプリケーション 

ファイル 

アプリケーション 

DF 

24 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

イル識別子の問題を解決する。VAは,次によって構成する。 

− curAppDF:DF又はアプリケーションDFへの参照。いつも設定する。 

− curDF:DFへの参照。DFは,アプリケーションDFであってもよい。いつも設定する。 

− curtEF:カレントのDFに属すEFの参照。いつも設定するというわけではない。 

− curFile:ファイルへの参照。いつも設定する。その値は,curEFが設定されていない場合curDFと同

じとし,curEFが設定されている場合curEFと同じとする。 

− curRecord:レコードで構成されたカレントEFに属すレコードへの参照。いつも設定するというわけ

ではない。 

− curDataString:透過構造のカレントEFの一部をなすバイト連続への参照。いつも設定するというわけ

ではない。 

− curConstructedDO:DOの扱いのために設定しなければならない。設定されている場合,それは構造化

DOへの参照とする。いつも設定するというわけではない。 

− curPrimitiveDO:親がcurConstructedDOによって参照されている基本DOへの参照。いつも設定される

というわけではない。 

− curDO:DOの扱いのために設定しなければならない。設定されている場合,それはDOへの参照とす

る。その値は,curPrimitiveDOが設定されていない場合curConstructedDOと同じとし,curPrimitiveDO

が設定されている場合curPrimitiveDOと同じとする。 

注記1 curFileは,curDF及びcurEFから計算でき,逆もまた同様に計算できる。したがって,curFile

は重要でないか,又はcurDF及びcurEFは重要ではないかのいずれかである。冗長にしてい

る理由は,ある機能(例えば,ACTIVATE,DEACTIVATE)はcurFileと一緒にすると説明し

やすいし,他の機能はcurDF及びcurEFと一緒にすると説明しやすいためである。 

注記2 curDOは,curConstructedDO及びcurPrimitiveDOから計算でき,逆もまた同様に計算できる。

したがって,curDOは重要でないか,又はcurConstructedDO及びcurPrimitiveDOは重要では

ないかのいずれかである。冗長にしている理由は,ある機能はcurDOと一緒にすると説明し

やすいし,他の機能はcurConstructedDO及びcurPrimitiveDOと一緒にすると説明しやすいた

めである。 

注記3 カレントSEは,カレントVAに属していない。 

7.2.2 

VAの扱い及び使用のための基本規則 

次のa)〜k)は,VAの使用方法について規則の説明をしているが,完全な記載とはなっていない。コマ

ンドについて記載している箇条で,規則を追加する。 

a) 基本論理チャネルを開く物理インタフェースの活性化(5.1参照)は,curAppDF及びcurDFの値を同

じ値に設定する。すなわち,MF又は暗黙的選択によるアプリケーションのいずれかを参照する値。 

b) 論理チャネルのリセットは,論理チャネルを開いた時の値と同じ値にVAをリセットする。リセット

による他の結果については,11.1.2を参照。 

c) 論理チャネルを開くことは,curAppDF及びcurDFを同じ値に設定する(11.1.1及び11.1.2参照)。 

d) アプリケーションDF選択は,選択されたアプリケーションDFを参照するためにcurDF及びcurAppDF

を設定する。 

e) アプリケーションDFでないDFの選択は,選択されたDFを参照するためにcurDFを設定する。また,

この選択は,選択されたDFの先祖(親,親の親…)で最も近いアプリケーションDFが存在すれば

それを,又はアプリケーションDFが先祖に存在しない場合はMFのいずれかを参照するように,

25 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

curAppDFを設定するか,又は設定されていることを確認する。 

f) 

EF選択は,選択されたEFを参照するためにcurEFを設定し,選択されたEFの親を参照するために

curDFを設定する[規則e)参照]。短縮EF識別子によって参照するC-RPの副次効果としてEF選択が

生じるとき,curEFは変化してもよいが,curDFは変化しない。 

g) レコード選択は,選択されたレコードをカレントレコードとして参照するためにcurRecordを設定し,

選択されたレコードの親を参照するためにcurEFを設定する[規則f)参照]。 

h) 透過構造のEF内のデータ列選択は,選択されたデータ列を参照するためにcurDataStringを設定し,

選択されたデータ列の親を参照するためにcurEFを設定する[規則f)参照]。 

i) 

DOを含む構造の選択は,指定された構造に従って,選択されたDOを参照するためにcurConstructedDO

を設定する。選択した構造が構造化DOの場合,選択したDOを参照するためにcurConstructedDOを

設定する。指定した構造が{アプリケーションDF,DF,EF,レコード又はデータ列}の場合,構造

選択は,仮想根幹DO“7F70”をカレントの構造化DOとして参照するためにcurConstructedDOを設

定する。このDOは,上記のリスト{アプリケーションDF,DF,EF,レコード,又はデータ列}で

DOを提供する最後に遭遇した構造に関連しなければならない。 

j) 

基本DOの選択は,特定されたDOをカレントの基本DOとして参照するためにcurPrimitiveDOを設

定し,選択された基本DOの親を参照するためにcurConstructedDOを設定する。 

k) DOの扱いのために,カレントテンプレートはcurConstructedDOによって参照されるDOの値フィー

ルドとする[規則i)参照]。 

明示的な選択は,再帰によって明示的な選択を超えてVAの要素を修正してもよい。そのような暗黙の

選択には,明示的な選択と同じ結果が得られなければならない。 

例 レコード中の構造化DOの選択は,curConstructedDOを明示的に設定する[規則i)]。また,この

選択は,curRecord[規則g)],curEF[規則f)],curDF[規則e)]及びcurAppDF[規則d)]を暗

黙的に設定するか,又は設定されていることを確認する。 

7.3 

構造選択 

7.3.1 

構造選択方法 

構造選択によって,構造内のデータへのアクセス,及びその配下の構造(存在すれば)へのアクセスを

可能にする。構造は,物理インタフェースのリセット後,暗黙的に,すなわち,自動的に[7.2.2の規則

a)及びg)参照]選択されてもよい(5.1参照)。暗黙的に構造を選択することができない場合,次の四つの

方法の少なくとも一つによって明示的に選択される。 

DF名による選択 DF名によって全てのDFは,参照できる。DF名は16バイトまでのバイト列とする。

全てのアプリケーション識別子(AID,12.2.3参照)をDF名として使用してもよい。DF名によって明白

に選択するために,例えば,アプリケーション識別子によって選択する場合には,DF名はカード内で唯

一でなければならない。 

ファイル識別子による選択 ファイル識別子によって全てのファイルは,参照できる。ファイル識別子は,

2バイトで構成する。値“3F00”は,MFを参照するために使用する。値“FFFF”は,予約されている(11.4.1.2

参照)。値“3FFF”は,予約されている(次及び11.4.1参照)。値“0000”は,予約されている(11.2.2及

び11.4.1参照)。ファイル識別子によって全てのファイルを明白に選択するために,EF及びDFは,ある

DFの直下で全て異なるファイル識別子をもたなければならない。 

パスによる選択 パスによって全てのファイルは,参照できる。パスは,ファイル識別子の連結とし,DF

(絶対パスではMF,相対パスではカレントDF)の識別子から始まり,目的のファイル自身の識別子で終

26 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

了する。この二つの識別子間で,パスは,親DFが存在する場合,連続する上位のDFの識別子から構成

する。ファイル識別子の順序は,常に親から子の方向とする。カレントDFの識別子が分からない場合に

は,値“3FFF”(予約値)はパスの初めに使用することができる。値“3F002F00”及び“3F002F01”は,

予約される(12.2.1及び12.2.2参照)。パスは,MFからの,又はカレントDFからの任意のファイルの明

白な選択を許可する(12.3参照)。 

短縮EF識別子による選択 短縮EF識別子は全てのEFを参照できる。全てのビットが同一値のものを除

く5ビットで構成する。すなわち,1〜30の任意の数値である。短縮EF識別子として使用される場合,数

値0(すなわち,2進数00000)は,カレントEFを参照する。MF直下では,数値30(すなわち,2進数

11110)は,予約される(12.2.1参照)。短縮EF識別子は,パスの識別子又はEF識別子(例えば,SELECT

コマンドのEF識別子)として使用することができない。DF直下のEFの全ての短縮EF識別子は唯一で

なければならない。また,このDFに関連したFCP DO“A2”(表10参照)の中で示された全ての短縮EF

識別子は唯一でなければならない。 

短縮EF識別子が提供される場合には,短縮EF識別子による選択を次の方法で示されなければならない。 

− ソフトウェア機能バイト1(表117参照)が,管理情報バイト(12.1.1参照)又はEF.ATR/INFO(12.2.2

参照)に存在する場合には,短縮EF識別子はカード全体で有効とする。 

− 短縮EF識別子DO“88”(10.2.3及び表10参照)が,EFのCP(ファイル制御パラメタ)に存在する

場合には,短縮EF識別子はそのEFで有効とする。 

データの選択方法 構造内のデータの選択方法としては,次の三つがある。 

タグによる選択 DOは,カレントテンプレートの基礎テンプレート(すなわち,カレントの構造化DO

の値フィールド)に属す場合にだけ,VAの詳細な情報なしで,一つのタグによって選択できる。 

レコード番号による選択 curEFによって示されたEFがレコードを提供する場合,レコード番号でEF内

の特定のレコードを参照する。レコード番号は正の整数とする。 

オフセットによる選択 curEFによって示されたEFが透過構造の場合,オフセットでEF内の参照バイト

列の始まりを示す。オフセットは,0以上の整数とする。 

7.3.2 

ファイル参照データ要素及びDO 

この産業間共通利用DO“51”(表7参照)は,ファイルを参照する。ファイル参照データ要素は任意の

長さとする。 

− 空のDOは,MFを参照。 

− 長さが1の場合で,データ要素のビットb8〜b4が全て等しくなく,かつ,ビットb3〜b1が000のと

きには,ビットb8〜b4は,短縮EF識別子として1〜30の番号を符号化する。 

− 長さが2の場合,データ要素は,ファイル識別子とする。 

− 長さが2より大きい場合,データ要素は,パスとする。 

− 長さが偶数で最初の2バイトが“3F00”の場合には,パスは,絶対パスとする。データ要素は,MF

識別子で始まる二つ以上のファイル識別子の連結とする。 

− 長さが偶数で最初の2バイトが“3F00”でない場合には,パスは,相対パスとする。データ要素は,

カレントDFの識別子で始まる,二つ以上のファイル識別子の連結とする。 

− 長さが奇数の場合,条件付きパスとする。データ要素は,一つ以上のSELECTコマンドでP1とし

て使用する1バイトが続く,“3F00”のない絶対パス又はカレントDFの識別子のない相対パスのい

ずれかとする(11.1.1及び12.3参照)。 

background image

27 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表7にファイル参照DOを示す。 

表7−ファイル参照DO“51” 

タグ 

長さ 

値 

“51” 

MFを参照する空のデータオブジェクト 

短縮EF識別子(ビットb8〜b4は,1〜30の番号を符号化し,ビットb3〜b1は,000に設定) 

ファイル識別子 

偶数,>2 絶対パス(先頭2バイトが“3F00”) 

相対パス(先頭2バイトが“3F00”以外) 

奇数,>2 条件付きパス(最後のバイトは,一つ以上のSELECTコマンドでP1として使用する。) 

7.3.3 

データ要素及びDOの一般参照 

この産業間共通利用DO“60”(表86参照)及びDO“7F72”(表37参照)は,カードの全ての構造物を

参照する。DO“60”の値フィールドは,DOを扱う多くのCR-Pのコマンドデータフィールドで使用され

る(11.4.2参照)。これらのコマンドは,ある場合にはVAに一時的に一過性の影響を与えるし,また,他

の場合にはVAを変更する。 

7.3.4 

EFのデータ参照方法 

図5にEF構造を示す。 

2) 

3) 

4) 

1) 

•••••• 

•••••• 

5) 

 1) 透過構造 

2) 固定長レコード順編成構造 
3) 可変長レコード順編成構造 
4) 固定長レコード循環順編成構造(矢印は,最後に書いたレコードを参照) 
5) TLV構造 
 

図5−EFの構造 

データ参照方法は,EF依存とする。EFは,データを参照するために次の構造の少なくとも一つを提供

しなければならない。 

なお,TLV構造には,簡易符号化TLVとBER-TLVとの2種類がある。 

− 透過構造 このEFは,カードのインタフェース上で,データ単位を扱うためのコマンドによってア

クセス可能な一連の番号付けされたデータ単位の並びとみなす(11.2参照)。データ単位の大きさは,

EF依存とする。 

− レコード構造 このEFは,カードのインタフェース上で,レコードを扱うためのコマンドによって

アクセス可能な個々に識別可能なレコードの一連の並びとみなす(11.3参照)。レコード番号付け方法,

レコード構造が簡易符号化TLV,又はレコード構造がBER-TLVは,EF依存とする。次の三つの属性

(レコードの長さ,レコードの構成,及びレコードのLCS)を定義する。 

− レコードの長さは,固定又は可変のいずれかとする。 

− レコードの構成は,順編成構造又は循環順編成構造のいずれかとする。 

− レコードは,レコードライフサイクルをもっていてもよい。もっているときは,レコードLCSは,少

background image

28 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

なくともACTIVATED状態及びDEACTIVATED状態を区別する。レコードLCSの符号化は,このJIS 

X 6320規格群 [6] の範囲外とする。EFは,レコードライフサイクル状態を全てのレコードがもってい

るか又はもっていないかのいずれかとする。レコードライフサイクルの存在は,CP(表10参照)に

よって示される。 

− 簡易符号化TLV構造 このEFは,カードのインタフェース上で,データオブジェクトを扱うための

コマンドによってアクセス可能な簡易符号化TLVデータオブジェクトの集合とみなす(11.4参照)。

この構造は,BER-TLV構造を除外する。 

− BER-TLV構造 このEFは,カードのインタフェース上で,DOを扱うためのコマンドによってアク

セス可能なDOの集合として見える(11.4参照)。この構造は,簡易符号化TLV構造を除外する。 

DF又はアプリケーション中で,データはDOとして参照してもよく(6.2参照),同様にEF内でも参照

してもよい。EF,DF,又はアプリケーションがこの参照を提供する場合,その選択はcurConstructedDO

を設定する(7.2.2及び8.2.1参照)。 

7.4 

ファイル制御情報及びデータ制御情報 

7.4.1 

ファイル制御情報読出し 

ファイル制御情報は,SELECTコマンドに対するレスポンス内から得られるバイト列(11.1.1参照)で

あり,それは,全てのファイル構造(すなわち,全てのDF及びEF)に対して存在する。 

− 先頭バイトが“00”〜“BF”の場合には,バイト列はBER-TLVに符号化しなければならない。ISO/IEC 

JTC 1/SC 17は,“00”〜“BF”の範囲でこの規格で未定義の値を将来使用するために予約する。 

− 先頭バイトが“C0”〜“FF”の場合には,バイト列はこの規格の符号化方法ではない。 

表8は,ファイル制御情報DOを入れ子にするための3種類の産業間共通利用テンプレートを示す。 

− FCPテンプレートは,ファイルとしてのCP DOの集合とする。すなわち,表10に示し定義している

論理的属性,構造的属性,セキュリティ属性などのことである。FCPテンプレートの内部では,状況

依存クラスが,FCP用に予約され,タグ“85”及び“A5”は個別利用情報を参照。 

− FMDテンプレートは,ファイル管理データの集合とする。すなわち,12.2.3で定義するアプリケーシ

ョン識別子などの産業間共通利用DO,12.2.4で定義するアプリケーションラベル,及びJIS X 6320-6

で定義するアプリケーション有効期限のデータの集合であり,それらは,12.2.4で定義するとおり,

アプリケーションテンプレート内で入れ子になっていてもよい。FMDテンプレートの内部では,タグ

“53”及び“73”は,自由裁量データを参照する。 

− FCIテンプレートは,ファイルCP及びファイル管理データからなる集合とする。 

表8−ファイル制御情報用の産業間共通利用テンプレート 

タグ 

値 

“62” ファイル制御パラメタの集合(FCPテンプレート) 

“64” ファイル管理データの集合(FMDテンプレート) 

“6F” ファイル制御パラメタ及びファイル管理データの集合(FCIテンプレート) 

この3種類のテンプレートは,SELECTコマンドのP2符号化の選択肢で指定したときには読み出されて

もよい(表62参照)。 

− FCIが戻されるようにP2を符号化したときには,FCIタグは,レスポンスデータフィールド中のテン

プレートを導くためにあってもよい。 

− CP又はFMDが戻されるようにP2を符号化したときには,それぞれに対応するタグは,テンプレー

background image

29 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

トを導くために必須とする。 

DFに関する制御情報の一部は,アプリケーション管理下でEF(ファイルCP中のタグ“87”によって

参照されるEF)内に付加的に存在してもよい。DFに関する制御情報の一部がこのようなEF内に存在す

る場合,ファイル制御情報には,CPタグ又はFCIタグのうちいずれか適切なタグを適用しなければなら

ない。 

7.4.2 

データ制御情報の読出し 

定義によれば,データ制御情報は,P1を“10”若しくは“13”に設定したSELECTコマンド(11.1.1参

照),又はP2のビットb3を1に設定したSELECT DATAコマンド(11.4.2参照)に対するレスポンスの内

容として提供されるバイト列である。データ制御情報は,いかなるDOに対して存在してもよい。 

表9−データ制御パラメタに対する産業間共通利用テンプレート 

タグ 

値フィールド 

“62”  データ制御パラメタの集合(一つ以上のCP DO。一つのDO“62”を含む場合がある。) 

DO“62”は,CP DOを入れ子にする(表9参照)。 

− CP DOは,いかなる構造(ファイル又はアプリケーションに使用されるBER-TLV構造,構造化DO)

のデータ制御情報の中にあってもよい。構造を選ぶことで,CP DOは,DO“62”のカレントテンプ

レートに属し適用される。 

− CP DOは,カレント基礎テンプレート(8.2.2参照)内に存在しているとき,GET DATA又はGET NEXT 

DATAの適用対象であり,GET DATA又はGET NEXT DATAによって読み出されてもよい。 

− CP DOは,別のテンプレートに存在しているときには,タグ付ラッパ(8.4.9参照)によって間接的に

参照されてもよい。 

7.4.3 

制御パラメタ 

表10は,ファイル及びデータオブジェクトに対するCP DOを示し,全て状況依存クラスである。CPが

存在する場合には,表は,それが一度だけ起こることか(適用欄に“*”の表示がある。),又はそれが繰り

返される(適用欄に“*”の表示がない。)かもしれないことを示す。 

表10−ファイル制御パラメタデータオブジェクト 

タグ 

(Tag) 

長さ 

(Length) 

データ要素 

(Value) 

適用 

“80” 

可変長 

構造情報を除く,ファイル内のデータバイト数 

全てのEF* 

“81” 

可変長 

構造情報が存在する場合,それを含むファイル又はDO内のデータバ
イト数 

ファイル*又はDO* 

“82” 

ファイル記述子バイト(7.4.5及び表11参照) 

ファイル* 

ファイル記述子バイト及びデータ符号化バイト(表118参照) 

3又は4 

ファイル記述子バイト,データ符号化バイト,及び1又は2バイトの
最大レコード長 

レコード型EF* 

5又は6 

ファイル記述子バイト,データ符号化バイト,2バイトの最大レコー
ド長及び1又は2バイトのレコード数 

“83” 

ファイル識別子 

ファイル* 

“84” 

16以下 

DF名 

DF 

“85” 

可変長 

BER-TLVで符号化されない個別利用情報 

ファイル 

“86” 

可変長 

個別利用書式のセキュリティ属性 

ファイル 

“87” 

ファイル制御情報の拡張を含むEFの識別子 

DF* 

background image

30 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表10−ファイル制御パラメタデータオブジェクト(続き) 

タグ 

(Tag) 

長さ 

(Length) 

データ要素 

(Value) 

適用 

“88” 

0又は1 

短縮EF識別子(7.4.4参照) 

EF* 

“8A” 

ライフサイクル状態バイト(LCS,7.4.10及び表14参照) 

EF*,又はDO* 

“8B” 

可変長 

拡張形式を参照するセキュリティ属性(9.3.3及び表38参照) 

ファイル* 

“8C” 

可変長 

コンパクト形式のセキュリティ属性,SE関連付け(表30参照) 

ファイル* 

“8D” 

セキュリティ環境テンプレートを含むEF識別子(10.3.3参照) 

DF 

“8E” 

論理チャネルセキュリティ属性(9.3.7及び表47参照) 

ファイル*又はDO* 

“8F” 

プロファイル指標子(表12参照) 

レコード型EF* 

“92” 

データ記述子バイト(7.4.7参照) 

DO*又はBER-TLV

構造提供EF* 

“96” 

可変長 

JIS X 6320-11で定義 

JIS X 6320-11参照 

“97” 

可変長 

DFリスト(7.4.8参照) 

DF* 

“98” 

可変長 

インスタンス番号(2進符号化) 

DO* 

“99” 

可変長 

ファイル又はDO選択後のカレントテンプレート中のDOの番号[2
進符号化,7.2.2の規則i)参照] 

ファイル*又はDO* 

“9A” 

可変長 

DF内のEFの番号(2進符号化) 

DF* 

“9B” 

可変長 

EFリスト(7.4.8参照) 

DF* 

“9C” 

可変長 

コンパクト形式のセキュリティ属性,SPT関連付け(表30参照)。 
注記 主としてDOの扱い向け。 

ファイル*又はDO* 

“9D” 

可変長 

DO“62”が適用するDOのタグ 

DO 

“A0” 

可変長 

DOのセキュリティ属性テンプレート(9.3.5参照) 

ファイル*又はDO* 

“A1” 

可変長 

個別利用書式のセキュリティ属性テンプレート 

ファイル 

“A2” 

可変長 

一つ以上のDO対からなるテンプレート。 
短縮EF識別子(DO“88”)及びファイル参照(DO“51”及びL>2,
7.3.2参照)の組合せ。 

ファイル又はDO 

“A3” 

可変長 

セキュリティ属性テンプレートに依存するインタフェース及びLCS
(7.4.12参照) 

ファイル又はDO 

“A5” 

可変長 

BER-TLVで符号化した個別利用情報 

ファイル 

“A6” 

可変長 

JIS X 6320-11で定義する 

JIS X 6320-11参照 

“AB” 

可変長 

拡張形式のセキュリティ属性テンプレート(9.3.3参照) 

ファイル* 

“AC” 

可変長 

暗号機構識別子テンプレート(9.2参照) 

DF 

“AD” 

可変長 

セキュリティパラメタテンプレート(9.3.6.1参照) 

DO 

“AF” 

可変長 

アプリケーションに関連している一つ以上のDO“06”(OID)をカプ
セル化するテンプレート 

DF* 

表中の“*”は,DO“62”配下で,最大1回まで出現することを示す。 
SELECTコマンドのレスポンス,並びにタグ“62”及び“6F”の配下において,状況依存クラスの上記以外のDO

は,ISO/IEC JTC 1/SC 17が予約している。 

7.4.4 

短縮EF識別子 

いかなるEFのCPにあっても,タグ“88”の使用に際して次の規則を適用する。 

− カードが短縮EF識別子による選択機能(7.3.1参照)を備え,タグ“88”が存在しない場合,ファイ

ル識別子(タグ“83”)の2バイト目のビットb5〜b1を短縮EF識別子として符号化する。 

− タグ“88”が存在し,長さが0に設定されている場合,そのEFは短縮識別子をもっていない。 

− タグ“88”が存在し,長さが1に設定され,データ要素のビットb8〜b4が全て等しくなく,ビット

b3〜b1が000に設定されている場合,ビットb8〜b4を短縮EF識別子として符号化する(1〜30の番

background image

31 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

号)。 

7.4.5 

ファイル記述子バイト 

DO“82”は,いかなるEFのCP内に存在してもよい(表10参照)。 

− データ要素(Value,表10参照)の先頭バイトは,ファイル記述子バイトとする(表11参照)。 

− データ要素が2バイト以上で構成されている場合,2バイト目はデータ符号化バイト(表118参照)

とする。 

− データ符号化バイトがカードの中に複数ある場合,次の起点から当該ファイルまでのパス上にあって

最も当該ファイルに近い位置に存在する。 

1) MFがあるときはMF。 

2) MFがないときはcurAppDFで参照されるDF。 

3) パス上にデータ符号化バイトがないとき,データ単位サイズを省略時値とする(表118参照)。 

表11−ファイル記述子バイト 

b8 

b7 

b6 

b5 

b4 

b3 

b2 

b1 

意味 

− 

− 

− 

− 

− 

− 

ファイル共有情報 

− 

− 

− 

− 

− 

− 

− 共有しないファイル 

− 

− 

− 

− 

− 

− 

− 共有可能なファイル 

− 

DF 

− 

全てが1でない。  − 

− 

− 

EFの種類 

− 

− 

− 

− 

− カードによって解釈されないデータを保存するためのEF(作

業用EF) 

− 

− 

− 

− 

− カードによって解釈されるデータを保存するためのEF(内部

EF) 

− 

他の値 

− 

− 

− 

− 個別利用EF 

− 

EF構造 

− 

全てが1でない。 

− 情報なし。 

− 

全てが1でない。 

− 透過構造 

− 

全てが1でない。 

− 固定長順編成構造,追加情報なし。 

− 

全てが1でない。 

− 固定長順編成構造,TLV構造 

− 

全てが1でない。 

− 可変長順編成構造,追加情報なし。 

− 

全てが1でない。 

− 可変長順編成構造,TLV構造 

− 

全てが1でない。 

− 固定長循環順編成構造,追加情報なし。 

− 

全てが1でない。 

− 固定長循環順編成構造,TLV構造 

− 

− BER-TLV構造 

− 

− 簡易符号化TLV構造 

− 他の値は,RFUとする。 
− “共有可能”とは,そのファイルが,異なる論理チャネルでの同時アクセスを提供するという意味である。 

7.4.6 

プロファイル指標子 

次の規則は,レコードを提供する全てのEFのファイルCP中でDO“8F”を使用するために適用する。 

− DO“8F”が存在する場合,値フィールドは,表12によるプロファイル指標子を含む。 

− DO“8F”が存在しない場合,暗黙的にEFの全てのレコードは,変更できないACTIVATED状態にあ

る。 

background image

32 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表12−プロファイル指標子の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

ISO/IEC JTC 1/SC 17によるプロファイル指標子の符号化 

− − − − − − 

レコードLCS 

− − − − − − 

このファイルの全てのレコードは変更できないACTIVATED状態 

− − − − − − 

このEFの各レコードは,自身のレコードLCSをもつ。ACTIVATE RECORD,
DEACTIVATE RECORD及びACTIVATE FILEコマンドによって変更可能で
ある。 

プロファイル指標子の個別利用符号化 

− 他の値は,RFUとする。 

7.4.7 

データ記述子バイト 

この産業間共通利用データ要素は,タグ“92”で参照され,DOの扱いをするために関連する情報(表

13参照)が入っているCP DOとする。この情報は,関連テンプレートのDOの全てのインスタンスに(二

つ以上の場合にも)有効とする。DOが共有不可能を宣言している場合,このDOの一つのインスタンス

だけが一つの論理チャネルでアクセス可能とする。 

表13−データ記述子バイトの符号化 

b8 

b7 

b6 

b5 

b4 

b3 

b2 

b1 

意味 

− 

− 

− 

− 

− 

− データへのアクセシビリティ 

− 

− 

− 

− 

− 

− − 共有不可能DO 

− 

− 

− 

− 

− 

− − 共有可能DO 

− 

− 

− 

− 

− テンプレート中のDOの構造 

− 

− 

− 

− 

− − 情報なし(省略時値) 

− 

− 

− 

− 

− − 順編成管理(11.4.7参照) 

− 

− 

− 

− 

− − インスタンスの周期的管理(11.4.7参照) 

− 

− 

− 

− 

− − RFU 

− 

− 

− 

− 

− 

− インスタンス 

− 

− 

− 

− 

− 

− − タグは,テンプレート中に最大一つ存在する。 

− 

− 

− 

− 

− 

− − タグは,テンプレート中に二つ以上存在してもよい(省略時値)。 

− 

− 

− 

− 

DOの特性 

− 

− 

− 

− 

− 情報なし。 

− 

− 

− 

− 

− 

− 

− タグリストが存在(構造化DO),又はタグリスト中に存在(基本DO) 

− 

− 

− 

− 

− 

− − ラッパによって拡張可能な基礎テンプレート(構造化DO),又はテ

ンプレート拡張部分(基本DO) 

− 

− 

− 

− 

− − ラッパの自動的な解決 

− 他の値は,RFUとする。 
− “共有可能”は,DOが異なった論理チャネルでの同時アクセスを提供することを意味する。 

7.4.8 

DF及びEFリストデータ要素 

DFリスト産業間共通利用データ要素は,タグ“97”で参照され,DF又はアプリケーションDFに入っ

ているDFを示すファイルCPである。それは,2バイトのファイル識別子の連結とする。 

EFリスト産業間共通利用データ要素は,タグ“9B”で参照され,DF又はアプリケーションDFに入っ

ている基礎ファイルの識別子,及びそれらの短縮EF識別子が入っているファイルCPである。各ファイル

の情報は,3バイトで符号化される。最初の2バイトは,EF識別子が入る。3バイト目は,7.4.4に従って

符号化されたEFの短縮EF識別子,又は,その基礎ファイルに短縮EF識別子がない場合,“00”と符号化

background image

33 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

された1バイトのいずれかとする。 

7.4.9 

インスタンス番号データ要素 

この産業間共通利用データ要素は,タグ“98”で参照され,テンプレート中にDOのインスタンスが複

数個存在する場合にだけ,存在してもよいDO CPとする。値フィールドは,INTEGER型に対するISO/IEC 

8825-1による定義によって,2進数で符号化された正の順序番号でなければならない。インスタンスの周

期的管理の付番方法は,レコード番号の管理と同じとする(11.3.6参照)。付番方法の他の情報については,

11.4.7を参照。 

7.4.10 ライフサイクル状態 

カード,ファイル及び他のオブジェクトは,それぞれのライフサイクルをもっている。ライフサイクル

状態(LCS)は,カード及び接続装置が,カード,カードの中のファイル及び他のオブジェクトを使用す

るための異なる論理的なセキュリティ状態を識別可能にする。 

属性(JIS X 6320-9参照)としてファイル,レコード又はDOのライフサイクルの柔軟な管理を提供す

るために,ここでは,次の順でライフサイクルの主要な状態を規定する。 

1) 創生状態 

2) 初期化状態 

3) 利用可能状態:活性化又は非活性化 

4) 終了状態 

LCSバイト(1バイト)は,表14によって意味付ける。 

− 値“00”〜“0F”は,産業間共通利用とする。 

− 値“10”〜“FF”は,個別利用とする。 

省略時の状態は,利用可能状態(活性化)でなければならない。 

表14−ファイル又はデータのLCSバイトの符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

情報なし。 

創生状態 

初期化状態 

− 

利用可能状態(活性化) 

− 

利用可能状態(非活性化) 

− − 終了状態 

全てが0でない。 

個別利用 

− 他の値は,RFUとする。 

LCSバイトは,タグ“8A”によって参照され,全てのファイル又はDOのCPに存在してもよい(表10

参照)。カードのLCSバイトは,管理情報バイトに存在してもよい(12.1.1.11参照)。タグ“48”によって

参照されるカードLCSバイトは,EF.ATR/INFOに存在してもよい(12.2.2参照)。MFが存在する場合には,

カードは創生状態以降である。 

注記 別段の定めがない限り,セキュリティ属性は,ファイル利用可能状態及びDOのACTIVATED

状態に対し有効とする。 

7.4.11 DO“A2”を用いた短縮EF識別子による間接参照 

DFのFCP中のDO“A2”配下のDO“88”は,DFがカレントの場合,入れ子になっている短縮EF識

別子が有効であることを示す。それ(DO“88”)を使用するコマンドは,そのDO“88”の後のDO“51”

background image

34 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

の中で入れ子にされたパスによって参照するEFを一時的に選択しなければならない。このコマンドによ

る選択は,curDF及びcurAppDFに影響を及ぼさない[7.2.2の規則f)参照]。curEFへの影響は,短縮EF

識別子を使用したコマンドを扱うセクションに記述する(例えば,11.2.2又は11.3.2参照)。 

7.4.12 セキュリティ属性テンプレートに依存するインタフェース及びライフサイクル状態 

DO“A3”は,ファイル又はDOのCP中に存在してもよい。また,二つ以上のDO“A3”がそのテンプ

レートの中に存在していてもよい(表10参照)。 

DO“A3”は,最大一つのDO“91”を含んでいなければならない(7.4.12.1参照)。DO“91”が存在し

ない場合,DO“A3”に入っているセキュリティ属性は,全てのインタフェースに適用する。DO“A3”に

DO“91”が存在する場合,テンプレート中の最初のDOでなければならない。 

DO“A3”は,最大一つのDO“8A”を含んでいなければならない(7.4.12.2参照)。DO“8A”が存在し

ない場合,DO“A3”に入っているセキュリティ属性は,全てのライフサイクル状態に適用する。DO“A3”

にDO“8A”が存在する場合,それは次のいずれかとする。 

− DO“91”が存在しない場合,テンプレート中の最初のDO 

− DO“91”が存在する場合,テンプレート中の2番目のDO 

DO“A3”は,DO“8B”,DO“8C”,DO“9C”,DO“A0”,DO“AB”を表10に定義する意味及び符号

化で,任意の順序で複数含んでいてもよい。 

7.4.12.1 トランスポートタイプ記述子 

DO“A3”配下のタグ“91”によって参照されるこのデータ要素は,同じDO“A3”に入っているセキ

ュリティ属性を適用するインタフェースを示す。表15にその符号化を示す。 

表15−トランスポートタイプ記述子(DO“A3”配下のDO“91”)の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − − 0,他の値はRFU a) 

− 

− − − − − 00,他の値はRFU 

− − − 

− − − − C6端子を使用した通信(JIS X 6320-3参照) 

− − − − 

− − − 近距離通信(JIS X 5211 [22] 参照) 

− − − − − 

− − USBインタフェース(ISO/IEC 7816-12参照) 

− − − − − − 

− 近接型ICカードの非接触インタフェース(JIS X 6322規格群 [18] 参照) 

− − − − − − − 

接触インタフェース(JIS X 6320-3参照) 

注a) この版は,1バイトが個々のインタフェースを参照するのに十分な場合を定義する。今後,2バイト以上

が必要になってもよい。 

このデータ要素のビットの設定によって,次の二つの場合がある。 

− 1のとき,対応するインタフェースに対しセキュリティ属性を適用しなければならない。 

− 0のとき,対応するインタフェースに対しDO“A3”は無関係とする。 

7.4.12.2 ライフサイクル状態の表示 

このデータ要素は,DO“A3”配下でタグ“8A”で参照され,どのライフサイクルに対し,同じDO“A3”

に含まれたセキュリティ属性を適用するかを示す。このデータ要素は1バイト以上を含み,各バイトは各々

7.4.10及び表14によって符号化し,解釈しなければならない。すなわち,各バイトは,各々,ライフサイ

クル状態を符号化し,データ要素の全てのバイトは,ライフサイクル状態の組合せを構築する。 

制御パラメタテンプレート(すなわち,タグ“62”のテンプレート)中のDO“8A”で与えられるファ

イル又はDOのライフサイクルは, 

35 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− この組合せの要素のとき,セキュリティ属性はファイル又はDOに適用しなければならない。 

− この組合せの要素でないとき,DO“A3”はファイル又はDOに無関係とする。 

DO特有の使用法及び関連する概念 

8.1 

BER-TLVペイロード及びパディング 

BER-TLV-符号化データフィールド又はペイロードは,BER-TLV DOを連結したもので,これらのDOの

前又は後にパディングを伴うことがある。 

コマンド又はレスポンスのデータフィールド又はペイロードのBER-TLV-符号化を示すには,次の二つ

の標準の方法がある。 

− CLAがセキュアメッセージングを示している(箇条10参照)。 

− INSのビットb1が1に設定されている(奇数INSコード)。 

偶数INSコードのコマンドは,データフィールド及びペイロードのBER-TLV-符号化を規定してもよい。 

この規格は,コマンドペイロード中のDOの順序を定義していることがある(例えば,表87参照)。レ

スポンスペイロードでは,DOの順序は定義されないか,又はカード中に存在するDOの順序を継承する

かのいずれかとする。 

BER-TLV長さフィールド(E.2参照)の符号化の制約から,nバイトのタグをもつDOは,例えば,全

体で(n+1+128)バイト,(n+2+256)バイト,(n+3+65 536)バイトなどの長さをもつことができな

い。また,複数のDOが送信され,最後のDOが同じ問題を引き起こす場合,全体の長さが無効となる状

況が生じるかもしれない。 

これら全ての場合に,全体の長さが無効となるNeに設定したコマンドを受け取る場合,カードは,DO

を含んでいるレスポンスデータフィールド中に,コマンドによって要求された先頭のNeバイトを送り

“61XY”(“XY”は残りのバイト数を符号化)に設定されたSW1-SW2を返してもよい。その後は,レス

ポンス連鎖(5.3.4参照)を適用する。 

8.1.1 

パディング条件 

データフィールドでパディングを行う可能性は,コマンドによって異なる。“DOの連結”は,パディン

グを除外する。パディングを行うことは,次のときに許される。 

− データ単位でデータ構造を扱うとき。例えば,パディングは,データ単位を提供しているEFで,DO

の消去及び変更に対しデータ単位での提供を維持するために,READ BINARYコマンドのレスポンス

データフィールドに存在していてもよい。 

− レコードでデータ構造を扱うとき。例えば,パディングは,レコードを提供しているEFで,レコー

ドの固定フォーマットを維持するために,READ RECORDコマンドのレスポンスデータフィールドに

存在していてもよい。 

− 標準のC-RP(CLA<“80”)によって明示的に許容されているとき。 

− C-RP(CLA>“7F”)の仕様で明示的に許容されているとき。 

BER-TLV-符号化が明示的に示されている場合,データペイロードはパディングなしでBER-TLVに符号

化されなければならない。BER-TLV-符号化は,ペイロードが分割されるコマンドの個々のデータフィール

ド(通称,ペイロード分割)に適用してはならない,ペイロード分割がDOを分割するためである。パデ

ィングは,ペイロード分割では除外する。 

注記 セキュアメッセージングは,ペイロード分割のBER-TLV-符号化を要求してもよい(10.1参照)。 

36 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

8.1.2 

パディング手続き 

パディングがBER-TLVペイロードに許されているとき,“00”に設定されたバイトはDOの前,DOと

DOとの間,又はDOの後に存在してもよい。 

データ符号化バイト(表118参照)は,管理情報バイト(12.1.1参照),EF.ATR/INFO(12.2.2参照)又

はファイルの制御情報(表10のタグ“82”参照)に存在しているとき,その値“FF”が次のいずれかで

あることを示す。 

− 私的クラスの長いタグフィールドの先頭バイトに有効,構造化符号化(明示的な宣言)。 

− タグフィールドの先頭バイトに対し無効(省略時値),すなわち,値“00”と同じ目的(パディング)

及び同じ条件として使用される。 

8.2 

カレントテンプレート及びデータオブジェクトの世代 

8.2.1 

カレントテンプレート及びカレントDO 

curConstructedDOは,設定されている場合,値フィールドがDOの連続である構造化DOを参照する。

7.2.2の規則k)で定義しているとおり,この値フィールドは,カレントテンプレートと呼ばれる。 

カレントテンプレート中のDOは,このDOのタグと一緒にVAの情報を提供しない交換用コマンドが

用いるこのDO単独のタグで直接参照できる。 

この参照するDOが構造化されている場合,カレントテンプレートは,この構造化DO内に入れ子にさ

れたDOは含まない。 

仮想根幹DO“7F70”は,第0世代に属し,この世代でただ一つのDOとする。curConstructedDOが第n

世代の構造化DO“XY”を参照する場合,カレントテンプレートは,DO“XY”に入れ子になっている第

(n+1)世代のDOを連結する。カレントテンプレートは,第(n+1)世代のDOに入れ子にされたDO

が存在してもそのDOは含まない。附属書Fに例を示す。 

curDO(7.2.1,9番目のダッシュ参照)は,SELECTコマンド(11.1.1参照)又はSELECT DATAコマン

ド(11.4.2参照)によって設定される。DOの選択は,DOを扱うコマンドの副次効果としても発生し,関

連する箇条に(例えば,GET DATAコマンドに対しては,11.4.3及び11.4.4に)記載する。 

カードは,この規格のこの版で定義した参照手法を提供するために,タグ“7F70”を解釈できることが

望ましい。 

インタフェースを活性化(5.1参照)した直後,したがって,あらゆる選択の前の時点では,カレントテ

ンプレートは,暗黙的に選択されたアプリケーション又はDF(VA中のcurAppDF)による。例えば,ISO/IEC 

24727-2 [24]で定義したディスカバリーメカニズムを提供する特定のDOが含まれていてもよい。 

DOを扱う多くのコマンドが,一つ以上の内部の選択を行う。これらの選択は,“一時的”といわれ,“一

時的カレントファイル”又は“一時的カレントテンプレート”を設定する,同様に“一時的VA”も設定

する。複数のケースで,コマンド成功の副次効果は,それらの内部の選択を有効にし,カレントVAとし

て一時的カレントVAを設定する。 

8.2.2 

テンプレート拡張 

テンプレート拡張は,タグ付ラッパの自動的な解決で,基礎テンプレートを拡張(附属書G又は例を参

照)することによってだけアクセス可能になるテンプレートの部分である。全てのラッパDO“63”は,

基礎テンプレートの一部である。 

タグ付ラッパの自動的な解決が提供されない場合には,テンプレート拡張は空とする。間接的参照は,

ただの情報だけとする。必要な場合には,カードの外部世界は,次の二段階の手続きを実行してもよい。 

− 対象の構造がカレントの構造と異なっているとき,DOが格納されている対象の構造を選択する。 

37 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− 次に,選択された構造の中でDOを取り扱う。 

8.2.3 

データオブジェクトサブツリー 

構造化DOは,ツリー構造をしている。このツリー構造のサブツリーは,ツリーから入れ子にされたDO

を取り外すことによって得られる。構造化DOに関係付けられた拡張ヘッダは,DOのサブツリーを参照

する(8.4.6及び8.4.7参照)。 

例 第n世代DOは,{T-L- {T1-L1-{T2-L2-V2}-{T3-L3-V3}}-{T4-L4-V4}-{T5-L5-V5}}と示されるとす

る。第(n+2)世代DO T2及び第(n+1)世代DO T4を取り除くとすると,サブツリー{T-L'- 

{T1-L1'-{T3-L3-V3}}-{T5-L5-V5}}が得られる。テンプレートから取り除いたDOがサブツリーの

長さに影響を与えるので,L及びL1をL'及びL1'に変更する。 

8.2.4 

データオブジェクトライフサイクル 

カードに格納された全てのDOは,DOライフサイクルをもっていてもよい。もっているとき,LCSは,

少なくとも二つの状態(ACTIVATED及びDEACTIVATED)を区別しなければならない。DOのLCSの符

号化及びファイルのLCSの符号化は,類似している(表14参照)。DO自身のLCS存在については,CP

テンプレートDO“62”(表10参照)に示す。 

8.3 

データ要素及びデータオブジェクトの識別 

8.3.1 

原則 

カードと接続装置とのインタフェース上では,データ要素は一般にDOの値フィールド中に存在する。

データ要素は,DOのタグ配下にあるといわれる。 

データ要素を表すビット数が8の倍数でない場合には,例えば,JIS X 6320-15のように,BITSTRING 

universal DOを用いてもよい。そうでない場合,1バイト又はバイト列への変換方法は,各々のデータ要素

の関連で定義することが望ましい。別段の定めがない場合,最終バイトのデータを左詰にし,残りのビッ

トを1に設定する。 

注記 アプリケーションは,データの長さを知っているので,実際のデータを扱う場合には,この1

を無視できる。 

交換における読出し及び参照の目的のために,データ要素は,BER-TLVデータ対象のタグに関連付けら

れる。また,データ要素はこのデータオブジェクトにカプセル化されてもよい。 

データ要素は,その関連するBER-TLVタグによって直接参照してもよい。そのタグが属する状況で使

用される別のデータ要素に関連付けられていてもよい。 

一つ以上の実行コマンドのデータオブジェクトが,間接的にデータ要素を参照してもよい。 

産業間共通利用コマンドは,テンプレート内で,したがって,アプリケーション内及びカード内でも,

同じDOの多重インスタンスを提供する。 

標準又はアプリケーションは,テンプレート内,構造内,又はアプリケーション内での同じDOの多重

インスタンスを制限してもよいし,又は禁止してもよい。 

8.3.2 

コマンド及びレスポンスデータフィールド又はペイロードにおけるタグ解釈 

普遍的クラス(先頭バイトが“01”〜“3F”,附属書E参照)のDOは,一般的な解釈が常に存在する。 

アプリケーションクラス(先頭バイトが“40”〜“7F”,附属書E参照)のDOの解釈は,規格によって

定義する。省略時は,JIS X 6320規格群 [6] 及びISO/IEC JTC 1/SC 17の規格とする(8.3.3参照)。また,

このクラスのDOの解釈は常に同じであるが,DOの機能は使用されているコマンドで定義される。 

状況依存クラス(先頭バイトが“80”〜“BF”,附属書E参照)のDOを解釈する方法は,次による。 

− 一般に,規格によって定義された構造化DOの入れ子のDO(例えば,DO“62”に入れ子にされた

background image

38 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

DO,表10参照)による。この規則は,再帰的であり,例えば,DO“62”の入れ子のDO“A0”に入

れ子にされたDOに適用される。 

− CLAによる。セキュアメッセージング指示(5.4及び10.1参照) 

− INSによる。コマンドは,特定の用法のために状況依存クラスのDOを定義してもよい。 

− 他の場合では,これらDOの解釈はアプリケーションで定義される。 

8.3.3 

タグ割付け 

この規格は,多くの産業間共通利用DOを規定し,そのDOのBER-TLV-符号化のためにタグを割り付

ける。将来の産業間共通利用DOの定義に加え,JIS X 6320-6は,出版時にJIS X 6320規格群 [6] で指定さ

れた組(産業間共通利用DOの名前,割り付けたタグ)に関する包括的なリストを保持する。ISO/IEC JTC 

1/SC 17の規格において割り付けたタグは,次のどちらかに属する。 

− アプリケーションクラス。 

− 状況依存クラス。対応するDOが,規格によって割り付けたタグの構造化DOに入れ子にされてもよ

いタグのとき。 

タグが別の規格によって定義されるとき,規格に責任をもつ国の機関は,タグ又は必要なタグのために

ISO/IEC JTC 1/SC 17/WG 4に助言を求めなければならないし,また,JIS X 6320-6にこれらのタグを追加

するために適切な時間内にコメントしなければならない。 

以降では,附属書Aによって例示しているように,データフィールドでの産業間共通利用DOを識別す

るタグ割付け体系を規定する。必要な場合,それらのタグ割付け体系は,タグ割付けに責任を負う機関を

識別するために,表16で示される産業間共通利用DOを使用する。 

表16−タグ割付け機関の産業間共通利用データオブジェクト 

タグ 

内容 

“06”  オブジェクト識別子(OID,ISO/IEC 8825-1で規定した符号化),附属書Aの例参照 

“41”  国名コード(JIS X 0304 [3] で規定した符号化)及び任意選択の国データ 

“42”  発行者識別番号(ISO/IEC 7812-1 [5] で規定した符号化及び登録)及び任意選択の発行者データ 

“4F” アプリケーション識別子(AID,12.2.3で規定した符号化) 

“5F29” 交換プロファイル 

8.3.4 

標準タグ割付け体系 

アプリケーションクラスでは,ISO/IEC JTC 1/SC 17は,範囲0〜127及び512(10進数)以上の全ての

アプリケーションクラスタグ番号の使用を割り付けるか又は予約する(“00”〜“7F”又は“0200”以上)。 

範囲128〜511(10進数)のアプリケーションクラスタグ番号は,OIDによって参照する規格若しくは仕

様によって,又はAIDで参照するアプリケーションによって割り付けてもよい。 

この範囲でタグ割付け機関を識別するために,構造化DO(“78”)は使用しなければならない。このDO

は,DO“06”又はDO“4F”が後続する空のDO“80”を入れ子にしなければならない。DO“78”が, 

− 初期データ列(12.1.2参照)又はEF.ATR/INFO(12.2.2参照)中に存在する場合,タグ割付け機関は,

ファイル又は構造化DO中の別のDO“78”によって無効にされる場合を除き,カード全体に有効と

する。 

− EF又はDF(アプリケーションを提供する可能性もある。7.4参照)の管理データ中に,又はファイル

の選択によって処理の対象にされたテンプレート中に存在する場合,タグ割付け機関は,構造化DO

中の別のDO“78”によって無効にされる場合を除き,そのファイル及びアプリケーションで有効と

39 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

する。 

− テンプレート中に存在する場合,タグ割付け機関は,テンプレート中の別DO“78”によって無効に

される場合を除き,テンプレートの全DO及びに構造化DOに含まれている全ての(世代にかかわり

ない)データオブジェクトに対し有効とする。 

8.3.5 

互換性をもつタグ割付け体系 

ここでのタグ割付け体系は,産業間共通利用DO及び産業間共通利用以外のDOを使用する。 

産業間共通利用以外のDOは,タグ“70”〜“72”又はタグ“74”〜“77”によって参照される産業間共通

利用DOに入れ子にしなければならない。タグ割付け機関(表16参照)を識別するためのタグ“41”,“42”

及び“4F”を除き,アプリケーションクラスタグの意味は,JIS X 6320規格群 [6] では規定しない。 

産業間共通利用以外のDOが状況依存クラスのタグを使用し,上記で定義された産業間共通利用テンプ

レートに属するとき,それらの意味は,タグ割付け機関によって定義される。 

タグ“65”(カード所持者に関連するデータ),“66”(カードデータ),“67”(認証データ)及び“6E”(ア

プリケーションに関連するデータ)をもつ産業間共通利用テンプレートは,状況依存クラスの使用を避け

る。 

互換性をもつタグ割付け体系及び体系に責任を負うタグ割付け機関を識別するために,産業間共通利用

DO“78”は使用されてもよい。DO“78”の可能な発生及び支配は8.3.4に従う。存在する場合,その値は,

タグ割付け機関の識別のために,表16で示される産業間共通利用DOのうちの一つを含まなければならな

い。 

8.3.6 

共存タグ割付け体系 

ここでのタグ割付け体系では,全ての産業間共通利用DOは,産業間共通利用DO“7E”の入れ子にし

なければならない。さらに,タグ“79”及び“7E”は,タグ“62”,“64”,“6F”(CP,FMD及びFCIテン

プレート。7.4参照)及び“7D”(SMテンプレート。10.1参照)と同様に別の意味を与えられてはならな

い。 

そのようなタグ割付け体系は,JIS X 6320規格群 [6] で意味を定義していないタグを使用してもよい。共

存するタグ割付け体系,及び体系に責任を負うタグ割付け機関を識別するために,産業間共通利用DO“79”

は使用されなければならない。このDOは,表16に示す産業間共通利用DOの一つを入れ子にしなければ

ならない。 

− タグ割付け機関がカード全体に有効な場合には,DO“79”は,初期データ列(12.1.2参照)に,又は

EF.ATR/INFO(12.2.2参照)に存在しなければならない。 

− タグ割付け機関がファイル又はアプリケーションに有効な場合には,DO“79”は,EF,DF若しくは

アプリケーションDF管理データ(7.4参照),又はファイル選択によるカレントテンプレートの集合

になければならない。 

8.3.7 

独立しているタグ割付け体系の回避 

独立しているタグ割付け体系は,JIS X 6320規格群 [6] とは別の意味のタグを用いてもよいが,8.3.6には

適合しない。そのようなタグ割付け体系はこの規格に適合せず,交換を許さない。 

互換性及び共存する割付け体系の一貫した使用以外に,アプリケーションが,この規格に従わない状況

を避け,この規格への適合性を維持するためには,次の三つの方法がある。 

− 自由裁量のDOを示す産業間共通利用DO“53”,及び自由裁量テンプレートの中に個別利用のDOを

入れ子にするためのDO“73”の使用 

− この目的で予約されている3バイトタグの使用(8.3.4参照) 

40 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− 状況依存クラスDOの使用(8.3.2参照) 

8.4 

DO及びデータ要素の参照及び読出し 

8.4.1 

共通事項 

タグ“XY”は,DO“XY”の値フィールドのデータ要素を直接参照する。アプリケーションの選択前に

行うDOの読出しに関しては,12.4を参照。 

制御パラメタ及びファイル管理データは,SELECT又はSELECT DATAコマンドの応答情報で読み出し

てもよい(11.1.1,11.4.2.1,及び表87参照)。 

一度,アプリケーションが選択されると,DOは,次の中で直接又は間接に読み出されることが望まし

い。 

− アプリケーションDFのファイル管理データ(7.4参照),及びカレントDF中の特定のEF 

− アプリケーション選択後にGET DATA又はGET NEXT DATAコマンド(11.4.3,11.4.4参照)を使用

して得たカレントテンプレート(8.2参照)。ファイル管理データ及び/又は(CPを入れ子にしている)

DO“62”は,これらがアプリケーションに適切であることを保証するため,このテンプレートに含ま

れていることが望ましい。 

要素リスト,タグリスト,ヘッダリスト,拡張ヘッダ,及び拡張ヘッダリストは,データ要素を間接参

照する産業間共通利用DOであり,結果としてテンプレート中のDOを参照する。そのデータ要素は,コ

マンドデータフィールドを解釈する方法,又はレスポンスデータフィールドを構成する方法をカードに指

示する。間接参照によるデータ要素の連結又はDOの連結を求めることを,間接参照を解決する(又は,

間接参照解決)と呼ぶ。 

タグリスト,ヘッダリスト,拡張ヘッダ又は拡張ヘッダリストの解釈は,各々が定義されているテンプ

レートによる。(このテンプレートを定義する)ラッパ中でこれらDOの一つを入れ子にすることは,カー

ド中のあらゆるところを参照することを可能とする。ラッパ中の任意のタグは,このタグによる間接参照

解決の結果を参照することを可能とする。 

SELECT DATA,GET DATA,GET NEXT DATAコマンドのコマンドデータフィールドの構文は,ラッパ

の構文に近似していてもよい,間接的にデータ要素を参照するDOの使用を示す。 

8.4.2 

要素リスト 

この産業間共通利用データ要素は,タグ“5F41”によって参照され,読み出すための情報がDOとして

存在せず,アプリケーション管理下にあることを示す。この産業間共通利用データ要素は,ラッパテンプ

レート内でだけ使用する。その構造及び返される情報は,JIS X 6320規格群 [6] では規定しない。 

8.4.3 

タグリスト 

この産業間共通利用データ要素は,タグ“5C”によって参照され,タグフィールドを区切りなく連結す

る。タグリストのタグの並びと同じ順に,各タグに対応したDOの連結が参照できる。 

8.4.4 

ヘッダリスト 

この産業間共通利用データ要素は,タグ“5D”によって参照され,区切りのない組合せ(タグフィール

ドT,長さフィールドL)の連結とする。バイト列は,値フィールドの短縮が行われる可能性がある以外,

タグリストと同じく定義される(すなわち,タグリストと同じく各タグに対応した値フィールドの並びと

する。)。L=“00”のとき,短縮は発生しない。L>“00”のとき,値フィールドは,Lバイト以下の場合

を除き,Lバイトに短縮されなければならない。Lの符号化はBERの長さとする。 

警告 ヘッダリスト中では,短縮された構造化DOはDOでないとの理由から,参照する短縮された

DOは,基本DOであることが望ましい。構造化DOの一部分を抽出するためには,拡張ヘッ

41 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

ダを使用することが望ましい。 

8.4.5 

拡張ヘッダ及び拡張ヘッダリスト 

この産業間共通利用データ要素は,タグ“4D”,“5F60”又は“5F61”(タグの意味の違いについては,

8.4.8参照)配下の拡張ヘッダリストとする。 

拡張ヘッダリストは,次のいずれかとする。 

− 拡張ヘッダ 

− 拡張ヘッダの連結 

拡張ヘッダは,区切りのない組合せ(タグフィールドT,長さフィールドL)の連結とする。拡張ヘッ

ダは,対象DO内の情報を参照する。完全な拡張ヘッダは,対象DOから次の手順によって導き出されな

ければならない(附属書H参照)。 

a) 参照されていない基本DO 

1) 拡張ヘッダが“4D”のタグの場合,タグ,長さ及び値フィールドを削除する。 

2) 拡張ヘッダが“5F60”又は“5F61”のタグの場合,値フィールドを削除し,長さフィールドを“00”

で置換する。 

b) 短縮なしで参照されている基本DO 

値フィールドを削除。 

1) 拡張ヘッダが“4D”のタグの場合,長さフィールドを“00”で置換する。 

2) 拡張ヘッダが“5F60”又は“5F61”のタグの場合,長さフィールドを“80”で置換する。 

c) 短縮で参照されている基本DO 

値フィールドを削除し,長さフィールドを短縮表示で置換する(8.4.6参照)。 

d) 参照されていない構造化DO 

値フィールドを削除し,長さフィールドを“00”で置換する。 

e) 完全に参照されている構造化DO 

値フィールドを削除し,長さフィールドを“80”で置換する。 

f) 

情報の一部が参照されている構造化DO 

上記の手続きを適用した結果による長さフィールドの値を調整。 

F.2に示すとおり,何も参照されていないDOの明白な参照は,このようなDOが与えられたテンプレー

ト内に存在するときでも,いつも必要というわけではない。使用していない参照箇所を取り除くことを,

この規格では認めている。 

8.4.6 

拡張ヘッダの解決 

拡張ヘッダを解決するために,次のとおり参照するバイト列を構成しなければならない。 

− タグが基本符号化を示す場合,タグフィールド及び長さフィールドの組は,タグによって参照された

データと置換する。拡張ヘッダが“4D”のタグの場合,長さ“00”は,DO全体又は要素全体がバイ

ト列に含まれることを意味する。拡張ヘッダが“5F60”又は“5F61”のタグの場合,長さ“80”は,

DO全体又は要素全体がバイト列に含まれることを意味する。“4D”のタグの拡張ヘッダ中で“00”で

ない長さ,“5F60”又は“5F61”のタグの拡張ヘッダ中で“80”でない長さのいずれもが,データバ

イトの最大数が読み出されることを意味し,したがって,8.4.4で定義するとおり短縮を要求してもよ

い。短縮指示がDOで利用可能なバイト数よりも多くを示す場合,動作は次による。 

− タグ“4D”配下では,この規格の適用範囲外とする。 

− タグ“5F60”及び“5F61”配下では,拡張ヘッダは無効とする。コマンドAPDUで使用する場合,

42 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

コマンドは,SW1-SW2=“6985”によって拒絶されなければならない。 

− ゼロでない(“80”を除く。)長さをもつ構造化符号化を示すタグは,拡張ヘッダリストである値フィ

ールドをもつ。長さ“00”の構造化符号化を示すタグは,無視される。長さ“80”をもつ構造化符号

化を示すタグは,構造化DO全体又はテンプレート全体がバイト列に含まれることを意味する。 

− カードは,対象となる構造に一致しない拡張ヘッダの要素を無視しなければならない。 

セキュリティの観点から,コマンドデータフィールドで使用した構造とカードの中身とで矛盾がある場

合,カードはSW1-SW2=“6985”でコマンドを拒絶してもよい。これは,セキュリティ属性を無効にして

もよい。 

バイト列は,次のいずれかで構成する。 

− ケース1 基本DOの値フィールド。示された長さに従って短縮することがある。又は, 

− ケース2 基本DO。示された長さに従って短縮することがある。各々のテンプレート内に入れ子にす

ることがある。各々のテンプレートの長さは,BER-TLVの規則に従う。 

− 長さが“80”の場合,実際の長さと置換しなければならない。構造化DO全体又はテンプレート全体

は,バイト列に含まれる。 

参照されたバイト列,言い換えると(短縮されている可能性がある)データ要素の連結又は(構造化さ

れている可能性がある)DO群,の符号化は,次のいずれかの方法で示される。 

− 適切なINSコード(奇数又は偶数)による。 

− コマンドの適切なパラメタ,例えば,データフィールドの適切な符号化(DOを含むための構造化符

号化,又はデータ要素を含むための基本符号化のいずれか)による。 

− 8.4.8及びPERFORM SECURITY OPERATIONコマンド(JIS X 6320-8参照)で示すとおり,“4D”以

外のタグの拡張ヘッダリストによる。 

8.4.7 

拡張ヘッダリストの解決 

拡張ヘッダリストによって参照されるバイト列は,拡張ヘッダリスト中の拡張ヘッダの順序に従って参

照されるバイト列の連結とする。拡張ヘッダを解析するとき, 

− 一つの拡張ヘッダの解決後には,次に続く拡張ヘッダがある場合,続いてこの拡張ヘッダの解決が行

われなければならない。 

− したがって,バイト列中の順序は,拡張ヘッダリスト中の拡張ヘッダの順序によって定義され,次に

示す問題を回避するために,対象(テンプレート)内の順序に一致していることが望ましい。ここで

問題とは,拡張ヘッダの解決において,カードは,対象(テンプレート)の構造に一致していない拡

張ヘッダリストの要素(拡張ヘッダ)を無視しなければならないことをいう。 

8.4.8 

ラッパ 

この共通テンプレートは,タグ“63”によって参照され,二つ以上のDOと入れ子にしなければならな

い。 

a) 最初のDOは,必須の間接参照とする。ただ一つだけの間接参照がラッパで与えられなければならな

い。それは次のいずれかとする。 

1) 要素リスト(タグ“5F41”又は“53”) 

2) DOを入れ子にする要素リスト(タグ“73”) 

3) タグリスト(タグ“5C”) 

4) ヘッダリスト(タグ“5D”) 

5) 拡張ヘッダリスト(タグ“4D”) 

43 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

6) 明示されていない構造のバイト列を参照する拡張ヘッダリスト(タグ“5F60”) 

7) 一つのDO又はDOの連結を参照する拡張ヘッダリスト(タグ“5F61”) 

8) 実行する最後のコマンドのレスポンスデータを示すバイト列(タグ“80”,空のDO) 

タグリスト又は拡張ヘッダリストのケースでは,フィルタDO“7F71”(11.4.2.3参照)が続く可能

性がある。DO“5F60”又はDO“5F61”の使用は,8.4.5に従って,基本DOの割愛指示ができる。 

b) ラッパの値フィールドの残りは,次のいずれかのとおりにしなければならない。 

1) アプリケーション識別子DO“4F”(12.2.3参照)。間接参照は,アプリケーション選択後のカレント

テンプレートで有効としなければならない。 

2) ファイル参照DO“51”(7.3.2及び表7参照)。間接参照は,選択されたファイルで有効としなけれ

ばならない。選択されたファイルが空の場合には,カレントテンプレートで有効としなければなら

ない。 

3) アプリケーション中に存在するファイルを参照する空でないDO“51”が続くDO“4F”。間接参照

は,参照されるファイルで有効としなければならない。 

4) 一つのDO“52”(実行のためのコマンド)。間接参照は,このコマンドのレスポンスペイロードで

有効としなければならない。 

5) 数個のDO“52”。実行のためのコマンドは,提示された順番で処理しなければならない。間接参照

は,最終コマンドのレスポンスペイロードの中又はこのコマンドで設定する一時的VA中で有効と

しなければならない。 

ラッパの解決は, 

− ラッパの第2の部分の解決から始める。標準構造又はレスポンスAPDUのいずれかである。間接参照

がDO“80”の場合,そこで終了する。 

− 間接参照がDO“80”でない場合,8.4.3,8.4.4,8.4.5で定義している間接参照の解決で終わる。 

例 次のラッパDOは,タグリスト及び一つの実行するコマンドで構成している。 

{“63”-L-{“5C”-L-(タグ1-タグ2-タグ3)}-{“52”-L-コマンドAPDU}} 

8.4.9 

タグ付ラッパ 

このDOは,タグ“63”配下で,ラッパの自動解決を提供するカード中のテンプレートを拡張する。 

タグ付ラッパDO“63”の値フィールド中の最初のDOは,空のDO“XY”でなければならない。タグ

“XY”は,拡張テンプレートがカレントテンプレートのとき(“XY”は,カレントのタグ割付け体系に関

係しなければならない。)GET DATA又はGET NEXT DATA C-RPの中で有効でなければならない。値フィ

ールドの残りは,ラッパDOの値フィールドでなければならない(8.4.8参照)。間接参照を解決した結果

は,拡張したテンプレートを指定した場合,DO“XY”の値フィールドでなければならない(8.2.2参照)。 

− ラッパがDO“ZT”を参照している場合,DO“XY”の値フィールドは,このDO“ZT”の値フィー

ルドでなければならない(例として附属書G参照)。ラッパは,ただ一つのDO(構造化DOの可能性

が高い。)を参照しなければならない。 

− ラッパがバイト列を参照している場合,DO“XY”の値フィールドは,そのバイト列でなければなら

ない。 

注記1 記法“XY”及び“ZT”は,2バイト以上のタグであってもよい。 

注記2 タグ付ラッパを自動的に解決することによって,カレントテンプレート中に仮想DOが作成

される。この仮想DOのタグは,タグ付ラッパ中の最初のDOから得られる。このDOの長

さフィールドは,間接参照解決から得られる内容の長さを符号化する。DOの値フィールド

44 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

は,内容そのものである(附属書Gの例を参照)。 

セキュリティ機構 

9.1 

共通事項 

ここでは,セキュリティステータス,セキュリティ属性及びセキュリティ機構について規定する。 

セキュリティステータス セキュリティステータスは,物理インタフェースを活性化(5.1参照)した後,

論理チャネルのリセット後及び/又はこの論理チャネル上の認証手続き実行可能な一つ以上のC-RPの実

行した後に,達成された現在の状態を表す。セキュリティステータスは,関連エンティティが存在する場

合には,エンティティの識別と関係するセキュリティ手続きの完了に起因してもよい。セキュリティ手続

きには,パスワードの確認(例えば,VERIFYコマンド),鍵の認証(例えば,GET CHALLENGEコマン

ドに続くEXTERNAL AUTHENTICATEコマンド,又はGENERAL AUTHENTICATEコマンドのコマンド列),

又はセキュアメッセージング(例えば,メッセージ認証)がある。セキュリティステータスは,次の5種

類とする。 

− カード全体のセキュリティステータス これは,DFの階層をもったカードにおいて,MFに関連する

認証手続き(例えば,MFに関連付けられたパスワード又は鍵によるエンティティ認証)の完了によ

って更新されてもよい。 

− アプリケーション固有のセキュリティステータス これは,アプリケーションに関連する認証手続き

(例えば,アプリケーションに関連付けられたパスワード又は鍵によるエンティティ認証)の完了に

よって更新されてもよく,アプリケーション選択によって保持される場合,回復される場合,又は失

われる場合がある。この更新は,認証手続きが属するアプリケーションだけに適用されてもよい。論

理チャネルを適用する場合には,このセキュリティステータスは,論理チャネルに依存してもよい。 

− ファイル固有のセキュリティステータス これは,DFに関連する認証手続き(例えば,特定のDFに

関連付けられたパスワード又は鍵によるエンティティ認証)の完了によって更新されてもよく,ファ

イル選択によって保持される場合,回復される場合,又は失われる場合があってもよい。この更新は,

認証手続きが属するアプリケーションだけに適用されてもよい。論理チャネルを適用する場合には,

このセキュリティステータスは,論理チャネルに依存してもよい。 

− DO固有のセキュリティステータス これは,DOに関連する認証手続きの完了によって更新されても

よく,選択によって保持される場合,回復される場合,又は失われる場合があってもよい。この更新

は,認証手続きが属するアプリケーションのDOだけに適用されてもよい。論理チャネルを適用する

場合には,DO特有のセキュリティステータスは,論理チャネルに依存してもよい。 

− コマンド固有のセキュリティステータス これは,認証を伴うセキュアメッセージングを使用したコ

マンドを処理する間だけ存在する。そのようなコマンドは,別のセキュリティステータスを変更しな

くてもよい。 

セキュリティ属性 セキュリティ属性は,存在する場合,どのような条件下で,どのような動作が許可さ

れるかを定義する。セキュリティ属性は,次に依存する。 

− その種別(DF,EF又はDO) 

− CPテンプレートDO“62”(FCP)の任意選択CP,及び/又はその親の構造の任意選択CP 

セキュリティ属性は,コマンド,DO及び“表及びビュー”(ISO/IEC 7816-7で規定されている表及びビ

ュー)に関係していてもよい。特にセキュリティ属性は,次のとおり規定してもよい。 

− データにアクセスする前に満足しているカードのセキュリティステータスを規定してもよい。 

45 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− カードが特別の状態をもっている場合には,データへのアクセスを特定の機能(例えば,読出し専用)

に制限してもよい。 

− 特定のセキュリティステータスを得るために,どのセキュリティ機能を実行しなければならないかを

規定してもよい。 

セキュリティ機構 ここでは,次のセキュリティ機構を規定する。 

− パスワードによるエンティティ認証 カードは,秘密の内部データと外部から受け取ったデータとを

比較する。この機構はカード利用者の権利保護のために用いてもよい。 

− 鍵によるエンティティ認証 認証するためのエンティティは,認証手続き(例えば,GET CHALLENGE

コマンドに続くEXTERNAL AUTHENTICATEコマンド,GENERAL AUTHENTICATEコマンドのコマ

ンド列)によって,適切な共通鍵又はプライベート鍵について認証しなければならない。 

− データ認証 カードは,秘密鍵又は公開鍵のいずれかの内部データを用いて外部から受け取った暗号

化チェックサム,電子署名などが付加されたデータを検査する。反対に,秘密鍵又はプライベート鍵

のいずれかの秘密の内部データを用いて,カードは,データ要素(暗号化チェックサム又は電子署名)

を計算し,外部へ送るデータに挿入する。この機構は,アプリケーション提供者の権利保護のために

用いてもよい。 

− データ暗号 カードは,秘密鍵又はプライベート鍵のいずれかの秘密の内部データを用いて,受け取

ったデータフィールドの中の暗号文を復号する。反対に,秘密鍵又は公開鍵のいずれかの内部データ

を用いて,カードは,暗号文を計算し,もし他のデータがあれば一緒にデータフィールドに挿入する。

この機構は,機密的なサービス(例えば,鍵管理及び条件付きアクセス)を提供するために使用でき

る。暗号機構のほかに,データ秘匿によってもデータ機密性は実現される。この場合,カードは,秘

密のバイト列を生成し,受信又は送信されるバイトとの排他的論理和を計算する。この機構は,プラ

イバシの保護及びメッセージをフィルタで取り出されないようにするために用いてもよい。 

認証の結果は,アプリケーションの要求に応じて内部EFに記録してもよい。 

9.2 

暗号機構識別子テンプレート 

一つ以上の暗号機構識別子DO“AC”は,任意のDFのCPに存在してもよい(表10参照)。各々は,

そのDF及び配下のDFの暗号機構参照の意味を明示的に示す。テンプレートは,二つ以上のDOで構成し

なければならない。 

− 先頭のDOは,DO“80”の暗号機構参照でなければならない(表55参照)。 

− 第2のDOは,ISO/IEC 8825-1で定義されるオブジェクト識別子であるDO“06”でなければならな

い。識別されたオブジェクトは,例えば,ISO規格等の標準規格に規定又は登録された暗号機構でな

ければならない。暗号機構の例は,暗号化アルゴリズム(例えば,ISO/IEC 18033規格群 [21]),メッ

セージ認証符号(例えば,ISO/IEC 9797規格群 [9]),認証プロトコル(例えば,ISO/IEC 9798規格群 [10]),

電子署名(例えば,ISO/IEC 9796 [8] 又はISO/IEC 14888規格群 [19]),登録暗号アルゴリズム(例えば,

ISO/IEC 9979 [11])などとする。 

− 存在する場合,一つ以上の後続するDO(DO“06”又はDO“13”)は,次のいずれかでなければなら

ない。 

− 前記の機構で使用される機構,すなわち,利用モード(例えば,JIS X 5053 [13]),又はハッシュ関数

(例えば,ISO/IEC 10118規格群 [14])の識別 

− パラメタの指定(タグの値は,前記の機構に依存) 

DO“13”は,ISO/IEC 8825-1で定義するとおり,最も近い前の位置のDO“06”を根幹とした関連OID

46 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

を与える。 

例 (附属書A及び附属書Bの説明参照) 

{“AC”-“0B”- {“80”-“01”-“01”} - {“06”-“06”-“28818C710201”}} 

テンプレートは,参照値“01”をISO/IEC 18033-2 [21] の先頭の暗号化アルゴリズムに関連付けて

いる。 

{“AC”-“11”- {“80”-“01”-“02”} - {“06”-“05”-“28CC460502”} - {“06”-“05”-

“28CF060303”}} 

1番目のオブジェクト識別子(中央)は,ISO/IEC 9798-5 [10] の第2の認証機構を参照する。2番

目のオブジェクト識別子(最右)は,ISO/IEC 18033-3 [21] の第3の専用ハッシュ関数を参照する。

したがって,このテンプレートは,SHA-1を使用したGQ2に,参照値“02”を関連付けている。 

9.3 

セキュリティ属性 

ここでは,セキュリティ属性に関連しているデータの符号化,及びオブジェクトとセキュリティ属性と

を一体化するための二つの形式(ビットマップに基づくコンパクト形式及びTLVリスト管理によってコン

パクト形式を拡張した拡張形式)を定義する。拡張形式は,異なるカプセル化でコンパクト形式のために

定義された符号化を使用してもよい。 

9.3.1 

セキュリティ属性の対象 

タグ“86”,“8B”,“8C”,“8E”,“9C”,“A0”,“A1”,“A3”,“AB”によって参照されるセキュリティ

属性は,任意のファイルの又はDOのCPに存在してもよい(表10参照)。カードの全てのオブジェクト

[例えば,コマンド,ファイル,DO,“表及びビュー”(ISO/IEC 7816-7参照)]は,二つ以上のセキュリ

ティ属性及び/又はセキュリティ属性に含まれている参照に関連付けてよい。 

SCQL環境(ISO/IEC 7816-7参照)では,セキュリティ属性はSCQL処理(例えば,CREATE TABLE及

びCREATE VIEWコマンド)で指定することができる。この箇条に基づいたセキュリティ属性が使用され

る場合,それらは,SCQL処理のセキュリティ属性パラメタ中のタグ“8B”,“8C”,又は“AB”を備えた

DOの中で伝えられなければならない。 

BER-TLV DO用セキュリティ属性は,9.3.5で定義する。論理チャネル用セキュリティ属性は,9.3.7で

定義する。 

9.3.2 

コンパクト形式 

コンパクト形式では,アクセス規則は,アクセスモードフィールドとそれに続く1バイト以上のセキュ

リティ条件バイトとで構成する。セキュリティ属性は,一つ以上の結合されたアクセス規則を含む。 

複数のアクセス規則がDO“8C”又は“9C”(表10参照)の値フィールドに存在する場合にはOR条件

を表す。 

アクセスモードフィールド アクセスモードフィールドは,1バイト又は2バイト以上から構成される。 

− アクセスモードフィールドが1バイトのAMBのとき,ビットb7〜b1の各ビットが,0に設定された

場合にはそのビットに対応したセキュリティ条件バイトが存在しないことを示し,1に設定された場

合にはそのビットに対応したセキュリティ条件バイトが存在することを示す。ビットb8が1の場合に

は,ビットb7〜b4は,追加のコマンド(例えば,アプリケーション特有のコマンド)のために用いて

もよい。 

− アクセスモードフィールドが2バイト以上のとき,アクセスモードフィールドの先頭バイトは“00”

に設定しなければならない。アクセスモードフィールドの2番目以後のバイト(次の注記を参照)は,

AMBとする。各AMBは,ビットb8で最終AMBか否かを示す。最終AMBは,ビットb8を0に設

background image

47 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

定しなければならない。他の全てのAMBは,ビットb8を1に設定しなければならない。各AMBに

おいてビットb6〜b1の各ビットは,0に設定されたときはそのビットに対応したセキュリティ条件バ

イトが存在しないことを示し,1に設定されたときはそのビットに対応したセキュリティ条件バイト

が存在することを示す。ビットb7が1に設定されているとき,ビットb6〜b1は,追加のコマンド(例

えば,アプリケーション特有のコマンド)のために使用してもよい。 

注記 その他のAMBは,この規格のこの版に定義されておらず,将来の版又はこの規格の他の部分

に定義してもよい。 

表17〜表29は,それぞれDF,EF,DO,及び“表及びビュー”(ISO/IEC 7816-7参照)のアクセスモー

ドバイトを定義する。 

表17−DFのアクセスモードフィールドの単独バイトの符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − − ビットb7〜b1の意味は,この表による。 

− − − − − − − ビットb3〜b1の意味は,この表による(ビットb7〜b4は,個別利用)。 

− − − − − − DELETE FILE(DF自身) 

− 

− − − − − TERMINATE CARD USAGE(MF),TERMINATE DF 

− − 

− − − − ACTIVATE FILE 

− − − 

− − − DEACTIVATE FILE 

− − − − − 

− − CREATE FILE(DF創生) 

− − − − − − 

− CREATE FILE(EF創生) 

− − − − − − − 

DELETE FILE(子供) 

表18−EFのアクセスモードフィールドの単独バイトの符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − − ビットb7〜b1の意味は,この表による。 

− − − − − − − ビットb3〜b1の意味は,この表による(ビットb7〜b4は,個別利用)。 

− − − − − − DELETE FILE 

− 

− − − − − TERMINATE EF 

− − 

− − − − ACTIVATE FILE,ACTIVATE RECORD(S) 

− − − 

− − − DEACTIVATE FILE,DEACTIVATE RECORD(S) 

− − − − − 

− − WRITE BINARY,WRITE RECORD,APPEND RECORD 

− − − − − − 

− UPDATE BINARY,UPDATE RECORD,ERASE BINARY,ERASE RECORD 

(S) 

− − − − − − − 

READ BINARY/RECORD (S),SEARCH BINARY/RECORD,COMPARE 
BINARY/RECORD 

background image

48 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表19−DOのアクセスモードフィールドの単独バイトの符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − − ビットb7〜b1の意味は,この表による。 

− − − − − − − ビットb3〜b1の意味は,この表による(ビットb7〜b4は,個別利用)。 

− − − − − − DELETE DATA 

− 

− − − − − MANAGE DATA Terminate 

− − 

− − − − MANAGE DATA Activate 

− − − 

− − − MANAGE DATA Deactivate 

− − − − − 

− − MANAGE SECURITY ENVIRONMENT 

− − − − − − 

− PUT DATA/PUT NEXT DATA/UPDATE DATA 

− − − − − − − 

GET DATA/GET NEXT DATA/COMPARE DATA 

表20−セキュリティオブジェクトに対するアクセスモードフィールドの単独バイトの符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − − ビットb7〜b1の意味は,この表による。 

− − − − − − − ビットb3〜b1の意味は,この表による(ビットb7〜b4は,個別利用)。 

− − − − − − 0(他の値は,RFU) 

− 

− − − − − TERMINATE a) 

− − 

− − − − ACTIVATE a) 

− − − 

− − − DEACTIVATE a) 

− − − − − 

− − 0(他の値は,RFU) 

− − − − − − 

− PUT/UPDATE a) 

− − − − − − − 

GET a) 

注a) イタリック体での記述は,コマンドではなく処理を意味する。 

表21−表及びビューのアクセスモードフィールドの単独バイトの符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − − ビットb7〜b1の意味は,この表による。 

− − − − − − − ビットb3〜b1の意味は,この表による(ビットb7〜b4は,個別利用)。 

− − − − − − CREATE USER,DELETE USER 

− 

− − − − − GRANT,REVOKE 

− − 

− − − − CREATE TABLE,CREATE VIEW,CREATE DICTIONARY 

− − − 

− − − DROP TABLE,DROP VIEW 

− − − − − 

− − INSERT 

− − − − − − 

− UPDATE,DELETE 

− − − − − − − 

FETCH 

background image

49 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表22−DFに対するアクセスモードフィールドの第2バイト目(第1のAMB)の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − − アクセスモードフィールドの最終バイト 

− − − − − − − アクセスモードフィールド内に継続バイトが存在する。 

− 

− − − − − − ビットb6〜b1の意味は,この表による。 

− 

− − − − − − ビットb6〜b1は,個別利用とする。 

− 

− − − − − TERMINATE CARD USAGE(MF),TERMINATE DF 

− 

− 

− − − − ACTIVATE FILE 

− 

− − 

− − − DEACTIVATE FILE 

− 

− − − 

− − CREATE FILE(DF創生) 

− 

− − − − 

− CREATE FILE(EF創生) 

− 

− − − − − 

DELETE FILE(子供) 

表23−DFに対するアクセスモードフィールドの第3バイト目(第2のAMB)の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − 表22と同じ符号化及び意味 

− 

− − − − − DELETE FILE(self) 

− 

− 

− − − − APPLICATION MANAGEMENT REQUEST 

− 

− − 

− − − REMOVE APPLICATION 

− 

− − − 

000(他の値は,RFU) 

表24−DFに対するアクセスモードフィールドの第4バイト目(第3のAMB)の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − 表22と同じ符号化及び意味 

− 

− − 0000(他の値は,RFU) 

− 

− − − − 

− データオブジェクトを作成するコマンド(JIS X 6320-9参照)。 

− 

− − − − − 

DELETE DATA 

表25−EFに対するアクセスモードフィールドの第2バイト目(第1のAMB)の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − 表22と同じ符号化及び意味 

− 

− − − − − TERMINATE EF 

− 

− 

− − − − ACTIVATE FILE,ACTIVATE RECORD(S) 

− 

− − 

− − − DEACTIVATE FILE,DEACTIVATE RECORD(S) 

− 

− − − 

− − APPEND RECORD 

− 

− − − − 

− UPDATE BINARY,UPDATE RECORD 

− 

− − − − − 

READ BINARY/RECORD(S),SEARCH BINARY/RECORD 

background image

50 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表26−EFに対するアクセスモードフィールドの第3バイト目(第2のAMB)の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − 表22と同じ符号化及び意味 

− 

− − − − − DELETE EF 

− 

− 

− − − 00(他の値は,RFU) 

− 

− − − 

− − WRITE BINARY,WRITE RECORD 

− 

− − − − 

− ERASE BINARY,ERASE RECORD(S) 

− 

− − − − − 

COMPARE BINARY/RECORD 

表27−EFに対するアクセスモードフィールドの第4バイト目(第3のAMB)の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − 表22と同じ符号化及び意味 

− 

− − 0000(他の値は,RFU) 

− 

− − − − 

− データオブジェクトを作成するコマンド(JIS X 6320-9参照)。 

− 

− − − − − 

DELETE DATA 

表28−DOに対するアクセスモードフィールドの第2バイト目(第1のAMB)の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − 表22と同じ符号化及び意味 

− 

− − − − − MANAGE DATA Terminate 

− 

− 

− − − − MANAGE DATA Activate 

− 

− − 

− − − MANAGE DATA Deactivate 

− 

− − − 

− − MANAGE SECURITY ENVIRONMENT 

− 

− − − − 

− PUT DATA/UPDATE DATA 

− 

− − − − − 

GET DATA/GET NEXT DATA 

表29−DOに対するアクセスモードフィールドの第3バイト目(第2のAMB)の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − 表22と同じ符号化及び意味 

− 

− − − − − DELETE DATA 

− 

− 

− − − − データオブジェクトを作成するコマンド(JIS X 6320-9参照) 

− 

− − 

− − 00(他の値は,RFU) 

− 

− − − − 

− PUT NEXT DATA 

− 

− − − − − 

COMPARE DATA 

セキュリティ条件バイト セキュリティ条件バイトは,アクセス規則に従うためにどのセキュリティ機構

が必要かを規定する。表30は,セキュリティ条件バイトを示す。 

ビットb8〜b5は,必要なセキュリティ条件を示す。ビットb4〜b1は,全てのビットが等しくない場合,

次のいずれかを識別する。 

− セキュリティ環境(10.3.3参照,“01”〜“0E”までのSEID)。 

− 又は,“01”〜“0E”の順序番号のDO“AD”(9.3.6参照)。DO“AD”は,セキュリティ属性と同じ

DO“62”配下のCPとする。 

background image

51 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表30−セキュリティ条件バイトの符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

無条件 

アクセス禁止 

− − − − 

セキュリティ環境及びDO“AD”への参照なし。 

− − − − 全ては等しくない。タグ“8C”a) 又は“9E”b) 配下で。 SEID(10.3.3参照) 

タグ“9C”a) 又は“9D”b) 配下で。 SPTDO“AD”の順序番号(9.3.6.3参照) 

− − − − − − − 少なくとも一つの条件 

− − − − − − − 全条件 

− 

− − − − − − セキュアメッセージング 

− − 

− − − − − 外部認証 

− − − 

− − − − 利用者認証(例えば,パスワード) 

注a) コンパクト形式で使用するため(タグ“62”配下で,表10参照)。 

b) 拡張形式で使用するため(表33参照)。 

セキュリティ環境又はDO“AD”中で定義された機能は,ビットb7〜b5の指示に応じて,コマンド保

護,及び/又は外部認証,及び/又は利用者認証のために使用しなければならない。 

− ビットb8が1の場合には,ビットb7〜b5に設定された条件は,全て満足されなければならない。 

− ビットb8が0の場合には,ビットb7〜b5に設定された条件は,少なくとも一つは満足されなければ

ならない。 

− セキュリティ環境を参照するセキュリティ条件で,ビットb7が1の場合には,セキュリティ環境の制

御参照テンプレート(10.3.1参照)は,セキュアメッセージングをコマンドデータフィールド及び/

又はレスポンスデータフィールドに適用しなければならないことを示す(表57“用途限定バイト”参

照)。セキュリティ条件がDO“AD”の順序番号を示す場合,適切なSEIDは,DO“AD”で又はDO

“AD”に入れ子にされたセキュリティ属性拡張で利用可能でなければならない。 

− ビットb8=b7=b6=b5=0で,ビットb4〜b1が有効なDO“AD”の順序番号を示す場合,ブール演

算式DOは,DO“AD”に存在しなければならない(9.3.6.11参照)。 

9.3.3 

拡張形式 

9.3.3.1 

共通事項 

拡張形式では,アクセス規則は,アクセスモードDOとそれに続く一つ以上のセキュリティ条件DOと

で構成する。オブジェクトへのアクセス制御は,関連するオブジェクトからのアクセス規則を参照するこ

とよって管理する。DO“AB”は,これらのアクセス規則のために,任意のファイルのCP(表10参照)

に存在してもよい。 

アクセスモードDO アクセスモードDOは,アクセスモードフィールド(表17〜表29及び表41〜表44

参照),コマンド記述の一覧,又は個別利用のステートマシン記述のいずれかを含んでいる。後続するセキ

ュリティ条件DOは,明示された全てのコマンドに関連する。表31は,アクセスモードDOを示す。 

表31−アクセスモードDOの符号化 

タグ 

長さ 

値 

意味 

“80” 

可変長  アクセスモードフィールド 

表17〜表29及び表41〜表44参照 

“81”〜“8F”  可変長  コマンドヘッダ記述子 

コマンドヘッダ(の一部分)の一覧(表32参照) 

“9C” 

可変長   

個別利用のステートマシン記述 

background image

52 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

タグが“81”〜“8F”の場合には,アクセスモードデータ要素は,コマンドヘッダのCLA,INS,P1及び

P2の4バイトの値の可能な組合せの一覧を表す。表32に記載するとおり,一覧は,タグのビットb4〜b1

によって指定される値だけを含む。複数のコマンドを定義するために,複数のグループを記述してもよい。

例えば,タグ“87”に対して,INS P1 P2, INS P1 P2…のように記述することができる。 

表32−アクセスモードDOのタグ“81”〜“8F”の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

コマンドヘッダ記述子が含む値 

− − − − (CLA),すなわち,CLAの値 

− 

− − − (INS),すなわち,INSの値 

− − 

− − (P1),すなわち,P1の値 

− − − 

− (P2),すなわち,P2の値 

− CLAの値には,論理チャネル番号として0を設定する。これは,論理チャネルに依存しないこと

を意味する。 

セキュリティ条件データオブジェクト 表33では,個々のアクセスモードDOを通して,セキュリティ条

件DOは,保護されたオブジェクトへのアクセスに必要なセキュリティ動作を定義する。セキュリティ条

件として使用される場合には,タグ“A4”(AT),“B4”(CCT),“B6”(DST)又は“B8”(CT)によって

参照される制御参照テンプレート(10.3.1参照)は,セキュリティ動作を示す用途限定DO(表57参照)

を含まなければならない。 

表33−セキュリティ条件DOの符号化 

タグ 

長さ 

値 

意味 

“90” 

− 

常時アクセス可能 

“97” 

− 

アクセス禁止 

“9D”,“9E” 

セキュリティ条件バイト 

表30参照 

“A4” 

可変長  制御参照テンプレート 

用途限定バイトによる外部認証又は利用者認証 

“AB” 

可変長  オブジェクト状態条件テンプレ

ート 

9.3.3.2参照 

“B4”,“B6”,

“B8” 

可変長  制御参照テンプレート 

用途限定バイトによるコマンド及び/又はレスポ
ンスのSM 

“A0” 

可変長  セキュリティ条件DO 

少なくとも一つのセキュリティ条件が満足される
(ORテンプレート)。 

“A7” 

可変長  セキュリティ条件DO 

セキュリティ条件の反転(NOTテンプレート) 

“AF” 

可変長  セキュリティ条件DO 

全セキュリティ条件が満足される(ANDテンプレ
ート)。 

“BE” 

可変長  セキュリティ条件テンプレート 

ブール代数。カードに存在する項目の値を参照。 

複数のセキュリティ条件DOは,同じ処理に関連付けることができる。 

− セキュリティ条件DOが,ORテンプレート(タグ“A0”)で入れ子にされる場合には,動作する前に

少なくとも一つのセキュリティ条件は,満足されなければならない。 

− セキュリティ条件DOが,ORテンプレート(タグ“A0”)で入れ子にされない場合又はANDテンプ

レート(タグ“AF”)で入れ子にされる場合には,動作する前に全てのセキュリティ条件を,満足し

なければならない。 

− セキュリティ条件DOが,NOTテンプレート(タグ“A7”)で入れ子にされる場合,セキュリティ条

background image

53 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

件は,満足しないことを真とする。 

9.3.3.2 

オブジェクト状態条件テンプレート 

このテンプレートは,次に示すものに依存するセキュリティ条件を作成する可能性を提供する。 

− オブジェクト状態条件テンプレートで参照されたオブジェクト(EF,DO)のカレント値 

− オブジェクト状態条件テンプレートで参照されたオブジェクト(EF,DF,DO,鍵,又はパスワード)

に関連する属性のカレント値 

− OS内部のデータ(例えば,システムクロック)のカレント値 

− コマンドメッセージ(の一部)のカレント値 

このテンプレートは,次の四つの異なった部分によって構成される。 

− テンプレートで与えられる比較データと参照値とを比較するために実行する処理を定義する必須の条

件データオブジェクト 

− 比較に使用されるデータを明白に識別する必須のオブジェクトロケータDO 

− 参照したオブジェクトの値,又は参照したオブジェクトに関連した属性の値と比較されるべき必須の

比較データ 

− 比較の前に比較(論理積)されるためにデータに適用される任意の2進フィルタ 

表34は,オブジェクト状態条件テンプレートを示す。 

表35は,表36とともに用いて条件データオブジェクトを示す。 

表34−オブジェクト属性に依存するアクセス状態の記述のためのSC-DO 

タグ 

長さ 

値 

意味 

“AB” 

可変長  条件DO“9E” 

表37に従ったオブジェクトロケータ(タグ“7F72”) 
2進フィルタDO“5F71”(任意) 
比較データ(タグ“53”) 

オブジェクト状態条件 

表35−状態データオブジェクトの符号化 

タグ 

長さ 

値 

“9E” 

“01”  オブジェクト属性を確認するための規則(表36参照) 

表36−状態を符号化するための値 

値 

遂行した条件 

“01” 

< *,参照したオブジェクト又はオブジェクトの属性の値は,与えられた比較データより小さい。 

“02” 

≦ *,参照したオブジェクト又はオブジェクトの属性の値は,与えられた比較データ以下である。 

“03” 

= *,参照したオブジェクト又はオブジェクトの属性の値は,与えられた比較データに等しい。 

“04” 

≧ *,参照したオブジェクト又はオブジェクトの属性の値は,与えられた比較データ以上である。 

“05” 

> *,参照したオブジェクト又はオブジェクトの属性の値は,与えられた比較データより大きい。 

“06” 

≠ *,参照したオブジェクト又はオブジェクトの属性の値は,与えられた比較データと等しくない。 

表中の“*”は,“オブジェクトの長さに等しい長さに対して”を意味する。 

参照したオブジェクト又は属性の値が条件DOによって定義された条件を満たさない場合,オブジェク

ト状態条件テンプレートに記述されたセキュリティ条件は満たされない。 

9.3.3.3 

オブジェクトロケータ 

オブジェクトロケータは,カードに格納されたオブジェクトの参照を提供する。次のオブジェクトタイ

54 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

プは,参照することができる。 

− MF又はDF固有の鍵 

− MF又はDF固有のパスワード 

− アプリケーション固有のデータオブジェクト 

− EF又はDF 

− カードによって管理された特別なシステムデータ 

− コマンドメッセージのデータ要素 

オブジェクトロケータは,テンプレート“7F72”によって表される。このテンプレートは,属性参照

DO(条件付き)が後に続くオブジェクト参照DO(必須)で構成される。オブジェクト参照DOのタイプ

は,参照されるオブジェクト(EF,DF,鍵,及びパスワード)に依存する。表37は,参照したオブジェ

クトタイプに依存するオブジェクト参照DOの一覧を示す。 

10.3.1に従った制御参照テンプレート(CRT)は,鍵又はパスワードを参照するのに用いる。CRTは,

少なくとも鍵参照データオブジェクト(DO“83”又は“84”)を含まなければならない。表51からの詳し

いデータオブジェクトは,必要ならば,更なる参照条件(例えば,用途限定)に使用してもよい。続く必

須のDO(空)は,意図している鍵属性のタグ(表40参照)で参照する。 

表37に従ってオブジェクトロケータは,次のどれかを参照するために用いる。 

− DF,EF又はDOに関する制御パラメタ 

− 透過構造EFのデータの内容(の一部分) 

− 構造化EFのレコードのデータの内容(の一部分) 

− DOの値フィールド 

DFへの参照が与えられる場合,表10の制御パラメタオブジェクトを示す2番目のデータオブジェクト

が,続かなければならない。EF又はDOが参照される場合,2番目のDOは,任意選択とする。2番目の

DOが存在する場合,それは,DFに対するのと同じ方法でEF又はDOの制御パラメタを示さなければな

らない。2番目のDOが存在しない場合,オブジェクトロケータは,EF(透過構造EF)のデータの内容,

EF内のレコードのデータの内容,又はDOの値フィールドを参照する。 

OSの内部のシステムデータを参照するために,空のDO“80”は,使用されなければならない。続く属

性参照DOは,そのタグで関連システム情報を示す。関連タグの定義は,この規格の適用範囲外とする。 

コマンドメッセージの部分を参照するために,空のDO“81”は,使用されなければならない。続く必

須DOは,コマンドAPDUのどの部分が指定されるかを示す。DO“A1”は,次のいずれかを指定するの

に用いる。 

− オフセット及び長さによって定義されたデータフィールド(の一部分) 

− データフィールドに格納されているデータオブジェクトの値フィールド(の一部分) 

データフィールドの意図しているデータオブジェクトは,タグリストによって定義される。タグリスト

が与えられない場合,コマンドデータフィールドがオブジェクトロケータの適合範囲にある。オフセット

DO及び/又は長さDOを使用して,コマンドデータフィールド又はDO値フィールドの関連領域は,制

限される場合がある。オフセットDOがオフセット値を逃している場合,ゼロは,暗黙のうちに使用され

る。長さDOがない場合,オブジェクトロケータは,オフセットで示された位置から開始して,コマンド

APDUのデータフィールド又はデータオブジェクトの値フィールドの端まで,全範囲を参照する。 

background image

55 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表37−オブジェクトロケータDO“7F72”の符号化 

オブジェクト

タイプ 

オブジェクト参照DO 

属性参照DO 

鍵 

少なくとも,鍵参照DO(“83”又は“84”)
を含むCRT 

空のDO(必須),タグは関連鍵属性を参照(表40参
照)。 

パスワード 

少なくとも,パスワード参照DO“83”及
び用途限定DO“95”を含むCRT 

空のDO(必須),タグは関連鍵属性を参照(表40参
照)。 

DF 

DFを示す一般参照テンプレート“60”(表
86参照) 

空のDO(必須),タグは関連制御パラメタオブジェ
クトを参照(表10参照)。 

EF又はDOの

CP 

EF又はDOを示す一般参照テンプレート
“60”(表86参照) 

空のDO(必須),タグは関連制御パラメタオブジェ
クトを参照(表10参照)。 

レコード,デー

タ列又はデー

タ要素 

EF内又は(EF内に位置した可能性のある)
データオブジェクトの値フィールドの,レ
コード又はデータ列を示す一般参照テン
プレート“60”(表86参照) 

なし 

システム 

データ 

内部のシステムデータ領域を示すDO“80”
(空) 

意図しているシステムデータ要素(個別利用)を示
すデータオブジェクト(空) 

コマンド 

メッセージ 

コマンドAPDUを示すDO“81”(空) 

次のデータオブジェクトの一つ(必須)。 
“89”:コマンドヘッダ(空のDO)を参照。 
“96”:コマンドAPDU(空のDO)のNe値を参照。 
“A1”:コマンドデータDO。与えられた順序の次の
DOを含んでもよい。 

− コマンドデータフィールドのDOを示すタグ

リスト 
(任意選択) 

− オフセットDO“54” 

(任意選択) 

− 長さDO“02” 

(任意選択) 

空のDO“A1”は,コマンドAPDUの完全なデータ
フィールドを参照。 

9.3.3.4 

2進フィルタ値(任意選択) 

2進フィルタDO“5F71”は,論理積処理で,比較前に比較されるデータに使用する2進のマスクを提供

する。 

9.3.3.5 

比較データ 

比較データDO“53”は,オブジェクトロケータによって指定されるデータと比較される値の2進法表

示を提供する。 

9.3.4 

アクセス規則参照 

拡張形式のアクセス規則は,可変長順編成構造のEFに格納してもよい。そのようなEFをEF.ARRと呼

ぶ。一つ以上のアクセス規則を,レコード番号によって参照される各レコードに格納してもよい。このレ

コード番号をARRバイトと呼ぶ。表38は,EF.ARRの構成を示す。 

background image

56 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表38−EF.ARRの構成 

レコード番号 

(ARRバイト) 

レコード内容(一つ以上のアクセス規則) 

アクセスモードDO,一つ以上のセキュリティ条件DO,以降
これら二つのデータオブジェクトを繰り返す場合がある。 

上記に同じ。 

… 

… 

上記に同じ。 

拡張形式(表39参照)を参照するセキュリティ属性DO“8B”は,任意のファイルのCP又はDOのCP

に存在してもよい(表10参照)。 

− 長さが1の場合には,値フィールドは暗黙的に知られているEF.ARRのレコードを参照するARRバイ

トとする。 

− 長さが3の場合には,値フィールドはファイル識別子と,それに続くARRバイトとする。ファイル

識別子はEF.ARRを参照し,ARRバイトはEF.ARRのレコード番号とする。 

− 長さが4以上の偶数の場合には,値フィールドはファイル識別子と,それに続く一つ以上のバイトと

の対とする。各バイト対は,SEIDと,それに続くARRバイトとで構成する。SEIDは,ARRバイト

によって参照されるアクセス規則が適用されるセキュリティ環境を識別する。 

表39−拡張形式を参照するセキュリティ属性DO 

タグ 

長さ 

値 

“8B” 

ARR バイト(1バイト) 

ファイル識別子(2バイト)- ARRバイト(1バイト) 

4以上

の偶数 

ファイル識別子(2バイト)- SEID(1バイト)- ARRバイト(1バイト)-  
以降,SEIDバイトと,それに続くARRバイトとを繰り返す場合がある。 

カレントSEのARRバイトは,そのアプリケーションDFへの現在のアクセスに対して有効なアクセス

規則を示す。 

注記 SEが以前のMANAGE SECURITY ENVIRONMENTコマンドで設定されていない場合には,省

略時SEをカレントSEとする。 

9.3.5 

データオブジェクトに対するセキュリティ属性 

セキュリティ関連の特性の適用範囲は,VAに関係しているカレントテンプレート内のタグによって特

定されたDOとする。全てのDOは,カードインタフェースで見られる制御パラメタ(そのDOに対する

セキュリティ属性を入れ子にするDO“62”)をもっていてもよい。DOが制御パラメタをもっていない場

合,親テンプレートのセキュリティ属性が継承される。 

テンプレート拡張に属する場合,DOのセキュリティ属性は,タグ付ラッパの親から引き継いではなら

ない。そのセキュリティ属性は,間接参照が指すところで定義されたものである。 

タグ“A0”配下のDOのセキュリティ属性テンプレートは,任意のファイル又はDOのCPに存在して

いてもよい(表10参照)。このテンプレートは,次のとおり開始され終了する。 

− セキュリティ属性DO(タグ“86”,“8B”,“8C”,“8E”,“9C”,“A0”,“A1”,“AB”)で開始する。 

− 空の可能性があるタグリストDO“5C”で終了する。 

タグリストは,DO“A0”を入れ子にするDO“62”が属する基礎テンプレートに属すタグ,又はこのテ

ンプレートに追加されるべきDOのタグだけを含んでいるのが望ましい。タグリストが空であるとき,セ

57 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

キュリティ属性テンプレートは,DO“62”が属する全体のテンプレートに有効とする。 

9.3.6 

セキュリティパラメタテンプレート 

9.3.6.1 

一般特性 

セキュリティパラメタテンプレート(DO“62”配下のDO“AD”)は,セキュリティオブジェクト(例

えば,鍵,パスワードなど)又はセキュリティの扱いを是認するDOに関連しているセキュリティ属性の

拡張を提供する(9.3.6.2参照)。この機能を提供する全てのDO“AD”は,セキュリティオブジェクト又

はDOへの間接参照を行う,ラッパ又はタグ付ラッパDO“63”(8.4.9及び9.3.6.2参照)のどちらかを含

まなければならない。それは,このDO使用の特性及び条件について説明するデータ用法パラメタを与え

てもよい。 

DO“AD”の中で入れ子にされたDO“AD”は,DO“62”の中で入れ子にされたDO“AD”と同じ符

号化とする。 

任意のテンプレートとして,セキュリティパラメタテンプレートは,DO“62”を入れ子にしてもよい。

このDO内では,DOに対するセキュリティ属性は,9.3.5に従う。他の全てのセキュリティ属性は,セキ

ュリティオブジェクトに適用する(アクセスモードバイトの符号化のために表20を参照)。 

例 DO“AD”配下のDO“62”のうちに,次のDOが両方とも存在してもよい。 

− DO {A0 06 {8CXYZT}{5C01B3}} は,その通常の意味(すなわち,OIDによって指定された

DOを含むDO“B3”へのアクセス用のセキュリティ属性)をもっている。 

− DO {8CXYZT} 又は {ABXY…}は,セキュリティオブジェクトを入れ子にするDOへのアク

セス用のセキュリティ属性を符号化する(表20参照)。 

DO“AD”は,さらに,このDOを使用する任意のコマンド又はDO“AD”に付随したセキュリティオ

ブジェクトで参照してもよい。 

ブール演算式をC-RPの実行を許可するためにTRUEとして評価する場合,このブール演算式を定義す

るDOはDO“AD”中に存在しなければならない(9.3.6.11参照)。 

9.3.6.2 

セキュリティ属性の拡張 

タグの値が“A0”〜“A5”の全てのDOは,セキュリティオブジェクトのタイプを特定する。各タイプ

は,特定のアクセスモードバイトをもっている(表41〜表44参照)。ディフィーヘルマン(Diffie-Hellman)

鍵のためのセキュリティ属性は無関係であるので,DO“A5”はいつも空とする。 

タグの値が“A0”〜“A4”の任意のDOは,次のいずれかを入れ子としなければならない。 

− SEを参照し,コンパクト形式(9.3.2参照)でセキュリティ属性を入れ子にするDO“8C”。 

− SPTを参照し,コンパクト形式(9.3.2参照)でセキュリティ属性を入れ子にするDO“90”。 

− セキュリティ条件バイトDO“9D”が,参照SPTを参照するために使用してもよい拡張形式(9.3.3参

照)でセキュリティ属性を入れ子にするDO“AB”。 

background image

58 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表40−セキュリティパラメタテンプレートのデータ用法パラメタ(タグ“62”配下のタグ“AD”) 

タグ 

長さ 

値 

発生頻度 

“06” 

可変長  ドキュメント記述(例えば,アルゴリズム及び/又はDO“B3”)のOID 

最大1回 

“63” 

可変長  ラッパ 

最大1回 

“7B” 

可変長  セキュリティ環境DO(表59参照) 

1回 

“80” 

順序番号(必須) 

1回 

“82” 

可変長  パスワード及び参照データタイプのセキュリティオブジェクト数(2進符号化) 

最大1回 

“83” 

可変長  鍵及び証明書タイプのセキュリティオブジェクト数(2進符号化) 

最大1回 

“84” 

SEID 

幾つでも 

“86” 

鍵使用法制約指標(9.3.6.4参照) 

最大1回 

“8A” 

セキュリティオブジェクトのLCSバイト 

最大1回 

“90” 

可変長  認証手続き試行の最大回数(2進符号化) 

揮発 

最大1回 

“91” 

不揮発 

“92” 

可変長  認証手続き試行の残存回数(2進符号化) 

揮発 

最大1回 

“93” 

不揮発 

“94” 

可変長  最大用途カウンタ(2進符号化) 

揮発 

最大1回 

“95” 

不揮発 

“96” 

可変長  残存用途カウンタ(2進符号化) 

揮発 

最大1回 

“97” 

不揮発 

“98” 

可変長  署名作成の最大数(2進符号化) 

揮発 

最大1回 

“99” 

不揮発 

“9A” 

可変長  署名作成の残存数(2進符号化) 

揮発 

最大1回 

“9B” 

不揮発 

“9C” 

非拒否フラグ(値が“00”の場合,是認されない。) 

最大1回 

“9D” 

可変長  鍵生成の最大数(2進符号化) 

最大1回 

“9E” 

可変長  鍵生成の残存数(2進符号化) 

最大1回 

 “A0”  可変長  認証オブジェクトのためのセキュリティ属性拡張 

この中から
どれか一つ
だけを選択
する。 

最大1回 

“A1” 

可変長  プライベート鍵のためのセキュリティ属性拡張 

“A2” 

可変長  公開鍵のためのセキュリティ属性拡張 

“A3” 

可変長  証明書のためのセキュリティ属性拡張 

“A4” 

可変長  秘密鍵のためのセキュリティ属性拡張 

“A5” 

ディフィーヘルマン鍵a) のためのセキュリティ属性拡張 

“AD”  可変長  セキュリティパラメタテンプレート 

幾つでも 

“AF” 

可変長  パスワード特性テンプレート(9.3.6.12参照) 

幾つでも 

“B3” 

可変長  DO“06”で規定されたDO 

幾つでも 

“BE” 

可変長  ブール演算式 

最大1回 

− 状況依存クラスの他のタグは,RFUとする。 
− 不揮発のカウンタ値は,物理的なチャネルの活性化及び非活性化と関係しない。 
− 揮発のカウンタ値は,物理的なチャネルの活性化及び非活性化によって影響を受ける。 
注a) この鍵の使用は,鍵がパブリックドメインパラメタに属するので,使用条件に従わない。 

DO“AD”がDO“90”又はDO“9D”内で参照されるとき,このDO“AD”又はそれを参照するタグ

付ラッパは,セキュリティ属性拡張と同じテンプレートに属さなければならない。 

セキュリティ属性拡張内のアクセスモードバイトは,セキュリティオブジェクトによってどの機能又は

コマンドが提供されているかを示す。DO“AD”内で使用されないとき,アクセスモードバイトは,どの

処理がセキュリティオブジェクトで実行されるのかを示してもよい。 

DO“AD”を参照するセキュリティ属性内でSEIDが提供されない場合,必要ならば,セキュリティ属

background image

59 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

性のこの拡張は,SEIDを提供してもよい。 

表41−認証オブジェクトのためのアクセスモードバイトの符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − − ビットb7〜b1の意味は,この表による。 

− − − − − − − ビットb3〜b1の意味は,この表による(ビットb7〜b4は,個

別利用)。 

− − − − − − ENABLE VERIFICATION REQUIREMENT 

− 

− − − − − DISABLE VERIFICATION REQUIREMENT 

− − 

− − − − 個別利用で使用 

− − − 

− − − 個別利用で使用 

− − − − − 

− − RESET RETRY COUNTER 

− − − − − − 

− CHANGE REFERENCE DATA 

− − − − − − − 

VERIFY 

表42−秘密非対称鍵のためのアクセスモードバイトの符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − − ビットb7〜b1の意味は,この表による。 

− − − − − − − ビットb5は個別利用,他のビットの意味は,この表による。 

− 

− − − − − − PSO ディジタル署名を計算 

− − 

− − − − − PSO 解読 

− − 

− − − − 0(他の値は,RFU) 

− − − − 

− − − GENERAL AUTHENTICATE 

− − − − − 

− − INTERNAL AUTHENTICATE 

− − − − − − 

− GENERATE ASYMMETRIC KEY PAIR 

− − − − − − − 

SPT内で使用されるときは個別利用,他のところで使用される
ときはGET ATTRIBUTE。 

表43−公開非対称鍵及び証明書のためのアクセスモードバイトの符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − − ビットb7〜b1の意味は,この表による。 

− − − − − − − ビットb5は個別利用,他のビットの意味は,この表による。 

− 

− − − − − − PSO ディジタル署名を確認する,証明書を確認する。 

− − 

− − − − − PSO 暗号化する。 

− − 

− − − − 0(他の値は,RFU) 

− − − − 

− − − GENERAL AUTHENTICATE 

− − − − − 

− − EXTERNAL AUTHENTICATE 

− − − − − − 

− GENERATE ASYMMETRIC KEY PAIR 

− − − − − − − 

SPT内で使用されるときは個別利用,他のところで使用される
ときはGET ATTRIBUTE。 

background image

60 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表44−秘密鍵のためのアクセスモードバイトの符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − − ビットb7〜b1の意味は,この表による。 

− − − − − − − ビットb4は個別利用,他のビットの意味は,この表による。 

− 

− − − − − − PSO暗号化し,暗号のチェックサムを計算する。 

− − 

− − − − − PSO解読し,暗号のチェックサムを確認する。 

− − − 

− − − − MUTUAL AUTHENTICATE,又はGENERAL AUTHENTICATE 

− − − 

− − − 0(他の値は,RFU) 

− − − − − 

− − EXTERNAL AUTHENTICATE,又はMUTUAL AUTHENTICATE 

− − − − − − 

− INTERNAL AUTHENTICATE 

− − − − − − − 

SPT内で使用されるときは個別利用,他のところで使用される
ときはGET ATTRIBUTE。 

9.3.6.3 

順序番号 

DO“AD”の連続したインスタンスは,順序番号の増加する値に対応しなければならない。DO“80”の

値は,1バイトで2進符号化される。セキュリティ条件バイト(表30参照)で参照されるDO“AD”は,

“01”〜“0E”の範囲の番号でなければならない。 

9.3.6.4 

鍵使用法制約指標 

DO“86”内のデータ要素は,鍵使用に制約を与える(表45参照)。ここでは,次の定義を使用する。 

− 準備段階:準備段階は,一つ以上のC-RPで構成する。準備段階の中で送られたコマンドの性質は,

この規格の適用範囲外とする。 

− 使用段階:使用段階は,一つ以上のC-RPで構成する。使用段階の中で送られたコマンドの性質は,

この規格の適用範囲外とする。 

表45−鍵使用法制約の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − − 最大1回の使用 

− 

− − − − − − 即時の使用 

− − 

− − − − − 詳細はOID参照で提供する。 

− − − 

00000(他の値は,RFU) 

ビットb8に次の値が設定されている場合, 

− 1 これは,個々の鍵使用については,準備段階を実行しなければならないことを示す。 

− 0 これは,鍵が準備段階ごとに2回以上使用可能であることを示す。 

ビットb7に次の値が設定されている場合, 

− 1 これは,鍵使用で使用した論理チャネルで準備段階と使用段階との間にC-RPを送るのを接続装置

が許されていないことを示す。 

− 0 これは,任意の論理チャネル上で,準備段階と使用段階との間に接続装置が一つ以上のC-RPを送

ってもよいことを示す。 

ビットb6に次の値が設定されている場合, 

− 1 DO“86”を含んでいるSPTは,DO“06”を含まなければならない。また,OID参照は鍵使用法

61 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

制約の詳細を供給しなければならない。 

− 0 DO“86”を含んでいるSPTは,DO“06”を含んでいてもよいし含んでいなくてもよい。 

鍵使用法制約指標のビットb5〜b1は,RFUとする。 

例1 非否認を与える署名鍵については,準備段階は,通常は,ユーザ認証(例えば,VERIFYコマ

ンド)を含み,そして,使用段階は,通常は,例えば,PSO HASHコマンドがないか,一つか,

又は複数のPSO HASHコマンドに後続する,例えば,PSO COMPUTE DIGITAL SIGNATUREコ

マンドを含む。 

例2 外部実体の真実性を証明する認証手続きの中で使用される鍵については,準備段階はカードか

らの乱数の読出し(例えば,GET CHALLENGEコマンド)を含み,使用段階は認証手続き(例

えば,EXTERNAL AUTHENTICATEコマンド)を含む。 

9.3.6.5 

試行回数 

セキュリティオブジェクトを認証に使用するとき,試行回数は,DO“AD”に入れ子にされたデータ用

法パラメタのDO“90”又は“91”の値に制限される。許容される残試行回数は,DO“92”又は“93”の

値によって与えられる。DO“90”,“91”,“92”及び“93”の値は,2進符号化される。 

9.3.6.6 

用途の数 

セキュリティオブジェクトの用途の数は,DO“AD”に入れ子にされたデータ用法パラメタのDO“94”

又は“95”の値に制限される。許容される残用途数は,DO“96”又は“97”の値によって与えられる。

DO“94”,“95”,“96”及び“97”の値は,2進符号化される。 

9.3.6.7 

否認防止 

否認防止を承諾するとき,機能は,DO“9C”に設定されたこのフラグ(すなわち,値>0)でセキュリ

ティオブジェクトDOを信頼することができる。この値が“00”の場合,DO(“9C 01 00”)は,否認防止

を是認することができない。 

9.3.6.8 

セキュリティオブジェクト付番 

必要な場合,(データ若しくはパスワード又は鍵若しくは証明書を参照する)セキュリティオブジェクト

は,DO“82”(又は“83”)に含まれる番号をもっていてもよい。DO“82”及び“83”の値は,1バイト

以上で2進符号化される。値の先頭バイトは,基本セキュリティ(11.5及び表94参照)を扱うコマンドの

オブジェクト参照として使用してもよい。値フィールドは,同じく,CRT(表55のDO“83”,“84”参照)

によってセキュリティデータオブジェクトを参照しているときに使用してもよい。 

注記 値フィールドの先頭バイトが,基本セキュリティを扱うコマンドでオブジェクト参照として使

用されることを意図する場合,表94からの制約は,値フィールドの先頭バイトに対する可能な

値の範囲を制限する。 

9.3.6.9 

署名作成 

必要な場合,セキュリティオブジェクトがある署名作成の数は,DO“AD”に入れ子にしたデータ用法

パラメタのDO“98”又は“99”の値に制限される。許容される残作成数は,DO“9A”又は“9B”の値

によって与えられる。DO“98”,“99”,“9A”及び“9B”の値は,2バイトで2進符号化される。 

9.3.6.10 鍵生成 

必要な場合,セキュリティオブジェクトがある鍵生成の数は,DO“AD”で入れ子にしたデータ用法パ

ラメタのDO“9D”の値に制限される。許容される残作成数は,DO“9E”の値によって与えられる。DO

“9D”及び“9E”の値は,2進符号化される。 

background image

62 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

9.3.6.11 ブール演算式 

DO“AD”配下のブール演算式DO“BE”は,次を含んでいる。 

− 必須のオブジェクト識別子DO“06”。オブジェクト識別子は,ブール演算式を組み込むために続く

DOを使用する方法を定義する。 

− 一つ又はそれ以上の状況依存クラスのDO。このDOは,一般参照DO“60”(11.4.2.1参照)又はオブ

ジェクトロケータDO“7F72”(9.3.3.3参照)と同じ構文があるDO又はデータを参照する。 

注記 9.3.2で,最後のダッシュは,DO“BE”の存在に対する要求を含む。 

9.3.6.12 パスワード特性テンプレート 

DO“AD”配下のパスワード特性テンプレートDO“AF”は,パスワード特性を含む。DO“06”は,パ

スワード特性テンプレートの中に存在してもよい。 

パスワードテンプレートが, 

− DO“06”内のOIDを含む場合,DO“06”が,パスワードテンプレート中の最初のDOでなければな

らない。このOIDによって参照された標準又は仕様は,パスワード特性テンプレートで囲まれた更な

るデータオブジェクトを規定しなければならない。 

− DO“06”を含まない場合,JIS X 6320-15に適合しているテンプレートは,表46に規定された意味及

び符号化を備えたDOを表46から任意に任意の順で含んでいてもよい。 

表46−パスワード特性テンプレート(タグ“AD”配下のDO“AF”) 

タグ 

長さ 

説明 

“81” 

検証データの経歴の長さ:記録維持されなければならない検証データ値の最大数。検証データ
が設定されるとき,それは検証データの経歴の全ての値とは異なっていなければならない。 
検証データ経歴の長さの値は,閉区間[0,8]になければならない。 

“82” 

検証データ及び新しい参照データのための輸送フォーマット。 
− “00”,直接:ICCへ移されたデータは,そのまま(2進符号化)利用する。 
− “01”,数値:各文字は,JIS X 0221 [16](UTF-8)に従って符号化され,閉区間[“30”,“39”]

の要素でなければならない。ICCへ移されたデータは,最大の長さ文字列が利用可能とな
るまで,“FF”をパディングしなければならない。 

− “03”,英数字(すなわち,数字,大文字・小文字ASCII):各文字は,JIS X 0221 [16](UTF-8)

に従って符号化され,閉区間[“30”,“39”],[“41”,“5A”]又は[“61”,“7A”]の要素
でなければならない。ICCへ移されたデータは,最大の長さ文字列が利用可能となるまで,
“FF”をパディングしなければならない。 

− 他の値はRFUとする。 

“83” 

最小の長さ:検証データ中の文字の最小数 

“84” 

最大の長さ:検証データ中の文字の最大数 

− 他の状況依存クラスのタグは,RFUとする。 

9.3.7 

論理チャネルのセキュリティ属性 

論理チャネルセキュリティ属性DO“8E”(最大一つ)は,任意のファイル又はDO(表10参照)のCP

及び任意の適切なセキュリティ環境(SE,10.3.3参照)に存在してもよい。論理チャネルセキュリティ属

性は,次の場合,表47のとおりでなければならない。 

− “非共有状態”は,一つの論理チャネルだけを有効とすることを意味する。論理チャネルの物理的技

術によって制限してもよい。 

− “セキュアな状態”は,SM鍵(箇条10参照)を有効とすることを意味する(例えば,前の認証によ

って確立されている状態)。 

background image

63 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− “利用者認証済み”は,利用者を認証済みであることを意味する(例えば,パスワード検証の成功済

みの状態)。 

表47−論理チャネルセキュリティ属性の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − 

非共有状態 

− 

− セキュアな状態 

− − 利用者認証済み 

− 他の値は,RFUとする。 

9.4 

セキュリティ支援データ要素 

ここでは,それらの値を扱う方法を管理する規則と合わせ,セキュリティ支援データ要素をまとめて規

定する。セキュリティ支援データ要素は,制御参照DOを拡張し洗練する。カードは,アプリケーション

によって実行されるセキュリティ機構への一般的な支援としてそれらを提供できる。アプリケーションは,

セキュアメッセージング及びセキュリティ処理(JIS X 6320-8参照)のためにセキュリティ支援データ要

素を参照してもよい。ここでは,セキュリティ支援データ要素(例えば,長さ)及びそれらの値を変更す

るためのアルゴリズムのいかなる特性についても規定しない。 

表48−セキュリティ支援DO 

タグ 

値 

“7A” 

次のタグが存在するセキュリティ支援データオブジェクトの集合 

“80” 

カードセションカウンタ 

“81” 

カードセション個別値 

 “82”〜“8E” ファイル選択カウンタ 
 

“93” 

ディジタル署名カウンタ 

“9F2X” 

内部進行値(“X”は,特定の値,例えば,ファイル選択カウンタ参照値とする。) 

“9F3Y” 

外部進行値(“Y”は,特定の値,例えば,外部タイムスタンプ参照値とする。) 

− タグ“7A”配下,状況依存クラスで,上記以外のDOは,ISO/IEC JTC 1/SC 17が予約する。 

原則 カードは,セキュリティ支援データ要素の値を次のとおり保持し,使用しなければならない。 

− 更新は,セキュリティ支援データ要素の個別の種類に対する個別の規則に従って,カード内で計算さ

れた値,又は外部から提供された値のいずれかの新しい値で行う。 

− コマンド処理の全ての出力よりも前に,更新を実行する。更新はそのコマンドの完了状態に依存しな

い。更新を行う処理において,アプリケーションによってその値が使用される場合には,その値が使

用される前に更新を行う。 

− アプリケーション特有のセキュリティ利用データ要素へのアクセスは,特定のアプリケーションによ

って実行される機能に制限される。 

注記 C-RPで達成される実際のセキュリティは,最終的にアプリケーションによって指定されるアル

ゴリズム及びプロトコルに依存する。カードは,これらのデータ要素及び関連する使用規則を

単に提供するだけである。 

データ要素 カードは,進行値と呼ばれるデータ要素によってC-RPのセキュリティを支援してもよい。

データ要素は,カードのライフサイクル全体にわたって,特定の事象によって進行値が増加することによ

って,カードが活性化するごとに異なった値となる。カードセションカウンタ及びセション個別値の二つ

の進行値を規定する。 

64 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− カードセションカウンタは,カード活性化の間に一度だけ増加する。 

− セション個別値は,カードセションカウンタ及び外部から提供されるデータから計算する。 

2種類の進行値が規定される。 

− 内部進行値は,アプリケーションにおいて指定された場合には,特定の事象が実行された回数を保持

する。データ要素は,事象の後に増加される。アプリケーションにおいて指定された場合には,カー

ドは回数の値を0に設定するリセット機能を提供してもよい。外部からは内部進行値を制御できず,

カード内の安全な実時間の近似表現として使用するのに適している。内部進行値は,暗号計算で使用

することができる。 

− 外部進行値は,アプリケーションにおいて指定された場合には,外部からのデータ値によってだけ更

新される。新しい値は,更新前にカードに格納されていた値よりも大きな数値でなければならない。 

参照 カードは,セキュリティ支援データ要素の値へのアクセスを,次のとおり提供してもよい。 

− EFは,例えば,カードセションカウンタとしてMFに存在してもよいし,又は,例えば,アプリケー

ション特有の進行値としてアプリケーションDFに存在してもよい。 

− タグ“88”,“92”及び“93”(表55参照)を含む補助DOは,制御参照テンプレートに存在してもよ

い。SEが,これらのデータ要素の明白な使用を提供する場合には,これらのDOを使用することがで

きる。 

− 産業間共通利用DO“7A”では,状況依存クラスは,表48に記載しているセキュリティ支援DOのた

めに予約される。 

10 セキュアメッセージング 

セキュアメッセージング(SM)は,二つの基本的なセキュリティ機能(データ機密性及びデータ認証)

によって,C-RPの,又は連続するデータフィールドの連結(ペイロード分割,5.3参照)の全て又は一部

を保護する。セキュアメッセージングは,一つ以上のセキュリティ機構を適用することによって実現され

る。例えば,任意のDFのファイルCP(7.4参照)内の暗号機構識別子テンプレート(9.2参照)によって

明示的に識別されるように,各セキュリティ機構は,暗号アルゴリズム,利用モード,鍵,引き数(入力

データ)及び初期データを含むことがある。 

− データフィールドの送信及び受信の合間に,セキュリティ機構の処理が入る場合がある。この規定は,

データフィールドの残りの部分の処理に使用しなければならない機構及びセキュリティ要素を,逐次

的な解析によって決定することを排除しない。 

− 二つ以上のセキュリティ機構が,異なる利用モードで同じ暗号アルゴリズムを用いてもよい。これ以

降で規定するパディング規則は,そのような特徴を排除しない。 

10.1 SMフィールド及びSM DO 

10.1.1 コマンドペイロードのSM保護 

SMペイロードは,長さのいかんにかかわらず,SMコマンド又はレスポンスSMフィールドとする。セ

キュアメッセージングによってペイロードの保護が分割の前に行われる場合,オーバサイズSMペイロー

ドは,オーバサイズBER-TLV符号化ペイロードの特別のケースとする,5.3の規則が適用される。 

ペイロードのフォーマットは,連鎖(5.3参照)を必須とする制約及び長さフォーマットによってその長

さが制限されないことを除き,次(10.4参照)で定義するとおりでなければならない。 

10.1.2 連鎖コマンド及びレスポンスのSM保護 

連鎖SMコマンド又はレスポンスデータフィールドを個々に保護する必要がある場合,5.3に従った分割

background image

65 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

は,C-RP保護の前に行われなければならない。各々のC-RPは,セキュリティ環境の要件に従って,保護

されなければならない(10.4参照)。 

分割は,確定した構造ではないコマンド又はレスポンスデータフィールドの連続を引き起こす。CLA INS 

P1 P2バイトは,分割に用いられる連鎖規則(5.3参照)に適合しなければならない。 

10.1.3 SM DO 

表49は,この規格で規定するSM DOを示す。全てのデータオブジェクトが,状況依存クラスである。

幾つかのSM DO(SMタグ“82”,“83”,“B0”及び“B1”)は再帰的である。すなわち,元の平文フィー

ルドがSMフィールドとなっている。 

各SMフィールドにおいて,各SM DO(状況依存クラス)のタグフィールドの最終バイトのビットb1

(タグパリティ)は,認証用のデータ要素[暗号化チェックサム(10.2.3.1参照)又はディジタル署名(10.2.3.2

参照)]の計算に,そのSM DOを含む(ビットb1に1を設定,すなわち,奇数タグ番号)か,含まない

(ビットb1に0を設定,すなわち,偶数タグ番号)か,を示す。その他のクラスのデータオブジェクト(例

えば,産業間共通利用データオブジェクト)が存在する場合,そのデータオブジェクトを,計算に含まな

ければならない。そのような計算を行う場合,データ要素(その計算結果)は,SMフィールドの最後に

置かれる認証用のSM DO(SMタグ“8E”,“9E”)の値フィールドとならなければならない。 

SMデータオブジェクトは,次の2種類がある。 

− 各基本SM DO(10.2参照)は,平文,セキュリティ機構の入力又は結果を伝える。 

− 各補助SM DO(10.3参照)は,制御参照テンプレート,セキュリティ環境識別子,又はレスポンス記

述子テンプレートを伝える。 

注記 基本SM DOは,セキュリティ処理を制御するためにも使用される(JIS X 6320-8参照)。また,

補助SM DOは,セキュリティ環境を管理するためにも使用される(11.5.11参照)。セキュアメ

ッセージによるセキュリティへの包括的な実現方法は,セキュリティ処理(すなわち,セキュ

リティへの個別の実現方法)と,様々なセキュリティ上の問題とを共有する。附属書Bは,二

つの実現方法間の相互作用について例示している。 

表49−SMデータオブジェクト 

タグ 

値 

“80”,“81” BER-TLV構造で符号化していない平文 

“82”,“83” 暗号文[元の平文をBER-TLV構造で符号化し,SM DO(すなわち,元の平文がSMフィールド)を

含む。] 

“84”,“85” 暗号文(元の平文をBER-TLV構造で符号化しているが,SM DOを含まない。) 

“86”,“87” パディング内容指標バイト及びそれに続く暗号文(元の平文をBER-TLV構造で符号化していない。) 

“89” 

コマンドヘッダ(CLA INS P1 P2の4バイト) 

“8E” 

暗号化チェックサム(4バイト以上) 

“90”,“91” ハッシュコード 

“92”,“93” 証明書(データを,BER-TLV構造で符号化していない。) 

“94”,“95” セキュリティ環境識別子(SEID) 

“96”,“97” SM化する前のコマンドレスポンス対のNeを符号化する1又は2バイト(値フィールドが存在しな

い場合もある。) 

“99” 

処理状態(SW1-SW2の2バイト,値フィールドが存在しない場合もある。) 

“9A”,“9B” ディジタル署名の計算のための入力データ要素(値フィールドに署名している。) 

 “9C”,“9D” 公開鍵 

“9E” 

ディジタル署名 

background image

66 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表49−SMデータオブジェクト(続き) 

タグ 

値 

“A0”,“A1” ハッシュコードの計算のための入力テンプレート(テンプレートが,ハッシュ計算の対象となる。) 

“A2” 

暗号化チェックサムの検証のための入力テンプレート(テンプレートが,計算の対象となる。) 

“A4”,“A5” 認証用の制御参照テンプレート(AT) 

“A6”,“A7” 鍵共有用の制御参照テンプレート(KAT) 

“A8” 

ディジタル署名の検証のための入力テンプレート(テンプレートを署名している。) 

“AA”,“AB” ハッシュコード用の制御参照テンプレート(HT) 

“AC”,“AD” ディジタル署名の計算のための入力テンプレート(値フィールドを連結したものが,署名の対象とな

る。) 

“AE”,“AF” 証明書の検証のための入力テンプレート(値フィールドを連結したものを,認証している。) 

“B0”,“B1” BER-TLV構造で符号化した平文であり,SM DO(すなわち,SMフィールド)を含む。 

“B2”,“B3” BER-TLV構造で符号化した平文であるが,SM DOを含まない。 

“B4”,“B5” 暗号化チェックサム用の制御参照テンプレート(CCT) 

“B6”,“B7” ディジタル署名用の制御参照テンプレート(DST) 

“B8”,“B9” 機密性用の制御参照テンプレート(CT) 

“BA”,“BB” レスポンス記述子テンプレート 

“BC”,“BD” ディジタル署名の計算のための入力テンプレート(テンプレートが,署名の対象となる。) 

“BE” 

証明書の検証のための入力テンプレート(テンプレートを認証している。) 

− SMフィールドで,上記以外の状況依存クラスのDOは,ISO/IEC JTC 1/SC 17が予約する。 
− SM C-RPの外でこれらのSM DOを使用するために,DO“7D”にカプセル化しなければならない。 

10.2 基本SM DO 

10.2.1 平文をカプセル化するSM DO 

カプセル化は,SMフィールド,及びBER-TLVで符号化されないデータに対し必須とする。SM DOを

含まないBER-TLVデータオブジェクトには任意選択とする。表50は,平文をカプセル化するためのSM DO

を示す。 

表50−平文をカプセル化するSM DO 

タグ 

内容 

“B0”,“B1” BER-TLV構造で符号化した平文であり,SM DO(すなわち,SMフィールド)を含む。 

“B2”,“B3” BER-TLV構造で符号化した平文であるが,SM DOを含まない。 

“80”,“81” BER-TLV構造で符号化していない平文 

“89” 

コマンドヘッダ(CLA INS P1 P2の4バイト) 

“96”,“97” SM化する前のコマンドレスポンス対のNeを符号化する1又は2バイト(値フィールドが存在しな

い場合もある。) 

“99” 

処理状態(SW1-SW2の2バイト,値フィールドが存在しない場合もある。) 

10.2.2 機密性のためのSM DO 

表51に,機密性のためのSM DOを示す。機密性用のセキュリティ機構は,適切な利用モードにおける

適切な暗号アルゴリズムからなる。明示的な指定がなく,かつ,機密性に関するセキュリティ機能が暗黙

的に選択されていない場合,省略時のセキュリティ機構を適用する。 

− パディング内容指標バイトが指定される暗号文の計算においては,省略時のセキュリティ機構は,“電

子コードブック”モードによるブロック暗号とする(パディングを含む場合もある。)。機密性用のパ

ディングは,送信に影響する場合もある。すなわち,暗号文(一つ以上のブロック)が元の平文より

も長くなる場合がある。 

background image

67 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− パディング内容指標バイトを指定しない暗号文の計算においては,省略時のセキュリティ機構は,ス

トリーム暗号とする。この場合,暗号文は,秘密にするデータ列と,それと同じ長さの秘密のデータ

列との排他的論理和とする。このようにストリーム暗号は,パディングを必要としない。また,デー

タ列は同じ処理によって復元される。 

平文をBER-TLVで符号化していない場合,パディング及び/又は平文の内容を明示しなければならな

い。パディングを適用するが,その方法を明示しない場合,10.2.3.1で規定する規則を適用する。 

表52は,パディング内容指標バイトを示す。 

表51−機密性用のSMデータオブジェクト 

タグ 

内容 

“82”,“83” 暗号文[元の平文をBER-TLV構造で符号化していて,SM DO(すなわち,元の平文がSMフィール

ド)を含む。] 

“84”,“85” 暗号文(元の平文をBER-TLV構造で符号化しているが,SM DOを含まない。) 

“86”,“87” パディング内容指標バイト(表52参照)と,それに続く暗号文(元の平文をBER-TLV構造で符号

化していない。) 

表52−パディング内容指標バイト 

値 

内容 

“00” 

詳細情報なし。 

“01” 

10.2.3.1で規定するパディング 

“02” 

パディングなし。 

“1X” 

データ(鍵ではない)を暗号化するための1〜4個の秘密鍵(“X”はビット対応で,“0”〜“F”の値
とする。) 
具体例を,次に示す。 
“11”は,1番目の鍵を示す(例えば,有料テレビシステムの偶数スクランブル鍵)。 
“12”は,2番目の鍵を示す(例えば,有料テレビシステムの奇数スクランブル鍵)。 
“13”は,1番目の鍵及びそれに続く2番目の鍵を示す(例えば,有料テレビシステムのスクランブ
ル鍵対)。 

“2X” 

鍵(データではない。)を暗号化するための秘密鍵(“X”は参照値で,“0”〜“F”の値とする。) 
[例えば,有料テレビシステムでのスクランブル鍵を暗号化するためのワーク鍵,又はワーク鍵を
暗号化するための主(マスタ)鍵] 

“3X” 

非対称鍵対のプライベート鍵(“X”は参照値で,“0”〜“F”の値とする。) 

“4X” 

パスワード(“X”は参照値で,“0”〜“F”の値とする。) 

“80”〜“8E” 個別利用 

− 他の値は,ISO/IEC JTC 1/SC 17が将来使用のために予約する。 
注記 スクランブル鍵(control word),ワーク鍵(operational key)及び主(マスタ)鍵(management key)の用語は,

ディジタル放送におけるアクセス制御方式の標準規格(ARIB STD-B25)で使用している。 

10.2.3 認証のためのSM DO 

表53に,認証のためのSM DOを示す。 

background image

68 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表53−認証のためのSM DO 

タグ 

内容 

“8E” 

暗号化チェックサム(4バイト以上) 

“90”,“91” ハッシュコード 

“92”,“93” 証明書(データを,BER-TLV構造で符号化していない。) 

“9C”,“9D” 公開鍵 

“9E” 

ディジタル署名 

入力DO(JIS X 6320-8参照) 

“9A”,“9B” ディジタル署名の計算のための入力データ要素(値フィールドを署名する。) 

“A0”,“A1” ハッシュコードの計算のための入力テンプレート(テンプレートがハッシュ計算の対象となる。) 

“A2” 

暗号文チェックサムの検証のための入力テンプレート(テンプレートが計算の対象となる。) 

“A8” 

ディジタル署名の検証のための入力テンプレート(テンプレートを署名している。) 

“AC”,“AD” ディジタル署名の計算のための入力テンプレート(値フィールドを連結したものが署名の対象とな

る。) 

“AE”,“AF” 証明書の検証のための入力テンプレート(値フィールドを連結したものを,認証している。) 

“BC”,“BD” ディジタル署名の計算のための入力テンプレート(テンプレートが署名の対象となる。) 

“BE” 

証明書の検証のための入力テンプレート(テンプレートを認証している。) 

10.2.3.1 暗号化チェックサムデータ要素 

暗号化チェックサムの計算は,初期値ブロック,秘密鍵,及びブロック暗号アルゴリズム(ISO/IEC 18033

規格群 [21] 参照)又はハッシュ関数(ISO/IEC 10118規格群 [14] を参照)のいずれかを用いる。 

計算方法は,システム仕様の一部であってもよい。又は,暗号機構識別子テンプレート(9.2参照)によ

って,標準規格(例えば,ISO/IEC 9797-1 [9])で計算方法を特定してもよい。 

別段の定めがない限り,次の計算方法を使用する。この計算方法で使用されるパラメタは,適切なCRT

中で定義してもよい(表55参照)。この規格は,省略時CRTを定義しない。 

使用されるアルゴリズムは,鍵の制御下で,基本的にkバイト(通常は8,16又は20バイト)の入力ブ

ロックを同じ長さの出力ブロックに変換する。計算は次の手順で実行する。 

初期段階 初期段階では,初期検査ブロックとして次のブロックのいずれかを設定しなければならない。 

− “ゼロ”ブロック。すなわち,kバイト分の“00”。 

− 連鎖ブロック。すなわち,前の計算結果(コマンドに関しては,前のコマンドの最終出力ブロックで

あり,レスポンスに関しては,前のレスポンスの最終出力ブロック)。 

− 提供された初期値ブロック。例えば,外部装置によって提供されたデータ。 

− 鍵の制御下で補助データを変換した結果の補助ブロック。補助データがkバイト未満の場合,ブロッ

クサイズまで残りのビットに0を設定する。 

途中段階 コマンドヘッダ(CLA INS P1 P2)は,保護のためにカプセル化してもよい(SMタグ“89”)。

しかし,(コマンドヘッダを保護するための他の方法として,)CLAのビットb8〜b6を000に設定し,か

つ,ビットb4及びb3を11に設定した場合(5.4参照)には,コマンドヘッダ(CLA INS P1 P2)と,それ

に続く“80”に設定した1バイトと“00”に設定したk-5バイトとで先頭のデータブロックを構成する。 

暗号化チェックサムの計算において,奇数タグ番号の全てのセキュアメッセージングDO,及び先頭バ

イトが“80”〜“BF”以外の全てのDOを入力に含めなければならない。それらのDOは,データブロック

単位で入力しなければならない。データブロックへの分割は次のとおり行う。 

− ブロック化は,入力に含めるべき隣接したDOを,切れ目なく連続的としなければならない。 

− パディングについては,入力に含めるべきデータオブジェクトのうち,入力に含めないDOが後続す

background image

69 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

るもの,又は後続するDOが存在しないものに対して,各DOの最後にパディングを適用しなければ

ならない。パディングは,必ず最初に“80”を設定し,各々のデータブロックがkバイトになるまで

必要なだけ0〜k-1バイトの“00”を設定する。認証のためのパディングは,パディングバイトが送信

されないので,送信に無関係である。 

このセキュリティ機構では,利用モードは“暗号ブロック連鎖”とする(JIS X 5053 [13] 参照)。すなわ

ち,先頭の入力は,初期値ブロックと先頭のデータブロックとの排他的論理和とする。先頭の出力は,先

頭の入力から生成される。以降は,前の出力と次のデータブロックとの排他的論理和とし,その結果から

次の入力が生成される。 

最終段階 最終出力ブロックは,最後の出力である。最終段階では,暗号化チェックサム(先頭のmバイ

トで,少なくとも4バイト)は,最終出力ブロックから取り出される。 

10.2.3.2 ディジタル署名データ要素 

ディジタル署名体系は,非対称暗号技術(ISO/IEC 9796規格群 [8],ISO/IEC 14888規格群 [19] を参照)

に依存する。計算にはハッシュ機能(ISO/IEC 10118規格群 [14] 参照)の使用が想定される。データ入力は,

ディジタル署名入力DOの値フィールド,又はディジタル署名入力テンプレートを形成するDOの値フィ

ールドの連結で構成する。10.2.3.1に規定する機構によってデータ入力を決定してもよい。 

10.3 補助SM DO 

表54に,補助SM DOを示す。 

表54−補助SM DO 

タグ 

内容 

“94”,“95” セキュリティ環境識別子(SEID バイト) 

“A4”,“A5” 認証用の制御参照テンプレート(AT) 

“A6”,“A7” 鍵共有用の制御参照テンプレート(KAT) 

“AA”,“AB” ハッシュコード用の制御参照テンプレート(HT) 

“B4”,“B5” 暗号化チェックサム用の制御参照テンプレート(CCT) 

“B6”,“B7” ディジタル署名用の制御参照テンプレート(DST) 

“B8”,“B9” 機密性用の制御参照テンプレート(CT) 

“BA”,“BB” レスポンス記述子テンプレート 

10.3.1 制御参照テンプレート 

対称又は非対称の暗号技術(CT-sym及びCT-asym)を使用した,認証(AT),鍵共有(KAT),ハッシュ

コード(HT),暗号化チェックサム(CCT),ディジタル署名(DST)及び機密性(CT)に有効な六つの制

御参照テンプレートを定義する。 

各セキュリティ機構は,利用モードにおける暗号アルゴリズムを含み,鍵及び場合によっては,初期デ

ータを使用する。そのような要素は,暗黙的に(すなわち,コマンドを発行する前に既知),又は明示的に

(すなわち,制御参照テンプレート内で入れ子にされた制御参照データオブジェクトによって)選択され

る。制御参照テンプレート内では,状況依存クラス(先頭バイトが“80”〜“BF”)を,制御参照DOのた

めに予約する。 

SMフィールドでは,制御参照テンプレートの位置は,参照される機構が適用される先頭のDOの前と

する。例えば,暗号化チェックサム(CCT)用の制御参照テンプレートの位置は,計算に含まれる最初の

DOの前になる。 

background image

70 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

各制御参照は,同じセキュリティ機能に対して新しい制御参照が提供されるまで有効とする。例えば,

あるコマンドが次のコマンド用に制御参照を提供してもよい。 

10.3.2 制御参照テンプレート中の制御参照DO 

各制御参照テンプレート(CRT)は,制御参照DOの集合とする。制御参照DOには,暗号機構参照,

ファイル及び鍵参照,初期データ参照,用途限定情報,並びに暗号内容参照(これは,機密性制御参照テ

ンプレート内にだけある。)がある。 

− 暗号機構参照は,利用モードにおける暗号アルゴリズムを示す。任意のDFのCP(表10のタグ“AC”

参照)は,暗号機構識別子テンプレートを含んでもよい(9.2参照)。各暗号機構識別子テンプレート

は,暗号機構参照の意味を示す。 

− ファイル参照(7.3.2と同じ符号化)は,鍵参照が有効となるファイルを示す。ファイル参照が存在し

ない場合,鍵参照は,カレントDF(アプリケーションDFの場合もある。)において有効とする。鍵

参照は,使用する鍵を明確に識別する。 

− 初期データ参照は,暗号化チェックサムに適用する場合,初期値ブロックを示す。初期データ参照が

存在せず,初期値ブロックが暗黙的に選択されていない場合には,“ゼロ”ブロックが適用される。さ

らに,ストリーム暗号を使用した機密性のための最初のDOを送信する前に,機密性用のテンプレー

トは,秘密のデータ列の計算を初期化するための補助データを提供しなければならない。 

表55は,制御参照DOの一覧を示し,それらがどの制御参照テンプレートに関連するかを示す。全ての

制御参照DOが状況依存クラスである。 

CRTは,産業間共通利用DO,例えば,AT中の証明書所持者許可書(タグ“5F4C”,10.3.3参照),HT

又はDST中のヘッダリスト又は拡張ヘッダリスト(タグ“5D”及び“4D”,8.4.4〜8.4.7参照)を含んで

いてもよい。任意の制御参照テンプレートにおいて,タグ“A3”配下の鍵使用テンプレートによって,鍵

使用カウンタ及び/又は鍵再試行カウンタをファイル及び鍵参照に関連付けてもよい。鍵使用テンプレー

トは,鍵使用DOの集合を含む(表56参照)。 

表55−制御参照テンプレート内の制御参照DO 

タグ 

内容 

AT KAT HT CCT DST CT-asym CT-sym 

“80” 

暗号機構参照 

ファイル及び鍵参照 

“81” 

ファイル参照(7.3.2と同じ符号化) 

“82” 

DF名(7.3.1参照) 

“83” 

秘密鍵参照(直接使用) 

公開鍵参照 

参照データ用途限定 

“84” 

セション鍵演算参照 

プライベート鍵参照 

“A3” 

鍵使用テンプレート(この表の直上の文章を参照) 

初期データ参照:初期検査ブロック 

“85” 

L=0,“ゼロ”ブロック 

“86” 

L=0,連鎖ブロック 

“87” 

L=0,前の初期値ブロックに1加算 

L=k,初期値ブロック 

background image

71 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表55−制御参照テンプレート内の制御参照DO(続き) 

タグ 

内容 

AT KAT HT CCT DST CT-asym CT-sym 

初期データ参照:補助データ要素(10.2.3.1参照) 

“88” 

L=0,前に交換された乱数に1加算 
L>0,追加指標なし。 

“89”〜“8D” L=0,個別データ要素の指標 

L>0,個別データ要素の値 


“90” 

L=0,カードから提供されるハッシュコード 

“91” 

L=0,カードから提供される乱数 
L>0,乱数 



“92” 

L=0,カードから提供されるタイムスタン 
L>0,タイムスタンプ 



“93” 

L=0,前のディジタル署名用カウンタ値に1加算 
L>0,ディジタル署名用カウンタ 




“94” 

鍵派生用の乱数又はデータ要素 

“95” 

用途限定バイト(表56の次の文章を参照) 

“8E” 

暗号内容参照(表57の次の文章を参照) 

− 制御参照テンプレートにおいて,状況依存クラスの他のDOは,ISO/IEC JTC 1/SC 17が予約する。 

表56−鍵使用テンプレート 

タグ 

内容 

“80”〜“84” 表55で規定したファイル及び鍵参照 

“90” 

鍵使用カウンタ 

“91” 

鍵再試行カウンタ 

− 状況依存クラスで,上記以外のDOは,ISO/IEC JTC 1/SC 17が予約する。 

任意の認証用制御参照テンプレート(AT),鍵共有用制御参照テンプレート(KAT),暗号化チェックサ

ム用制御参照テンプレート(CCT),機密性用制御参照テンプレート(CT),又はディジタル署名用制御参

照テンプレート(DST)において,タグ“95”で示される用途限定バイトは,セキュリティ条件として(9.3.3

及び表33参照),又はMANAGE SECURITY ENVIRONMENTコマンド(11.5.11参照)に応じて,そのテ

ンプレートの使用法を規定してもよい。表57は用途限定バイトを示す。 

表57−用途限定バイトの符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − − 検証(DST,CCT),暗号化(CT),外部認証(AT),鍵共有(KAT) 

− 

− − − − − − 計算(DST,CCT),復号(CT),内部認証(AT),鍵共有(KAT) 

− − 

− − − − − レスポンスデータフィールドのセキュアメッセージング(CCT,CT,DST) 

− − − 

− − − − コマンドデータフィールドのセキュアメッセージング(CCT,CT,DST) 

− − − − 

− − − パスワードに基づく利用者認証(AT) 

− − − − − 

− − 生体認証に基づく利用者認証(AT) 

− − − − − − 

00(他の値は,RFU) 

任意の機密性用制御参照テンプレート(CT)では,暗号内容参照(タグ“8E”)によって暗号文の内容

を規定してもよい。値フィールドの先頭バイトは,必須であり,暗号文記述子バイトと呼ぶ。表58は,

暗号文記述子バイトを示す。 

background image

72 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表58−暗号文記述子バイト 

値 

意味 

“00” 

詳細情報なし。 

“1X” 

情報(鍵ではない。)を暗号化するための1〜4個の秘密鍵(“X”はビット対応で,“0”〜“F”の値
とする。) 
具体例を,次に示す。 
“11”は,1番目の鍵を示す(例えば,有料テレビシステムの偶数スクランブル鍵)。 
“12”は,2番目の鍵を示す(例えば,有料テレビシステムの奇数スクランブル鍵)。 
“13”は,1番目の鍵と,それに続く2番目の鍵とを示す(例えば,有料テレビシステムのスクラン
ブル鍵対)。 

“2X” 

鍵(情報ではない。)を暗号化するための秘密鍵(“X”は参照値で,“0”〜“F”の値とする。) 
[例えば,有料テレビシステムでのスクランブル鍵を暗号化するためのワーク鍵,又はワーク鍵を
暗号化するための主(マスタ)鍵] 

“3X” 

非対称鍵対のプライベート鍵(“X”は参照値で,“0”〜“F”の値とする。) 

“4X” 

パスワード(“X”は参照値で,“0”〜“F”の値とする。) 

“80”〜“FF” 個別利用 

− 他の値は,ISO/IEC JTC 1/SC 17が将来使用のために予約する。 
注記 スクランブル鍵(control word),ワーク鍵(operational key)及び主(マスタ)鍵(management key)の用語は,

ディジタル放送におけるアクセス制御方式の標準規格(ARIB STD-B25)で使用している。 

10.3.3 セキュリティ環境 

ここでは,セキュアメッセージング及びセキュリティ処理(JIS X 6320-8参照)に必要となる暗号アル

ゴリズム,利用モード,プロトコル,手続き,鍵,及び任意の追加のデータを参照するためのセキュリテ

ィ環境(SE)を規定する。SEは,指定されたアルゴリズムによって処理される,カードに格納されてい

るデータ要素,又はある計算から生成されるデータ要素で構成する。SEは,その環境内で使用される一時

的データ(例えば,セション鍵)を初期化するための機構を含むことができる。SEは,計算結果の扱い方

法(例えば,カード内に記憶する。)を指示することもできる。産業間共通利用SEテンプレート(タグ“7B”)

は,SEについて記述する。 

SE識別子 SE識別子(SEID)は,任意のセキュリティ環境を参照してもよい。例えば,セキュアメッセ

ージングのため,並びにMANAGE SECURITY ENVIRONMENTコマンド(11.5.11参照)による格納及び

置換のため。 

− アプリケーションによって別段の定めがない限り,値“00”は,セキュアメッセージング及び認証を

定義しない環境を示す。 

− 値“FF”は,この環境では処理を行うことができないことを示す。 

− アプリケーションによって別段の定めがない限り,値“01”は,常に利用可能な省略時SEのために

予約される。ここでは,省略時SEの内容を規定しない。省略時SEは,存在しなくてもよい。 

− 値“EF”は将来使用するために予約される。 

構成要素 制御参照テンプレート(CRT)によってSEの様々な構成要素を記述してもよい。セキュリテ

ィ環境においてセキュリティ機構とともに指定された全ての相対的な制御参照(ファイル,鍵,又はデー

タ)を,機構を使用する前に選択されたcurDFに関して特定しなければならない。絶対的な制御参照(例

えば,絶対パス)は,特定する必要がない。SEにおいて,構成要素の中には次の二つの側面をもつものが

ある。一つは,コマンドデータフィールドのSMに有効であり,もう一方は,レスポンスデータフィール

ドのSMに有効である。 

カードの処理中は,省略時値又はカードによって実行されたコマンドの結果のいずれかによって,カレ

background image

73 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

ントSEは常に活性化しなければならない。カレントSEは,次の一つ以上の構成要素を含んでいる。 

− curDFに関連した省略時SEに属する構成要素 

− セキュアメッセージングを用いているコマンドによって送信される構成要素 

− MANAGE SECURITY ENVIRONMENTコマンドによって送信される構成要素 

− MANAGE SECURITY ENVIRONMENTコマンドのSEIDによって呼び出される構成要素 

カレントSEは,次の状態のいずれかになるまで有効とする。 

− 物理インタフェースの非活性化(5.1参照) 

− 論理チャネルのリセット(11.1.2参照) 

− VAの変更(例えば,curDFの変更) 

− カレントSEを設定又は再構築するMANAGE SECURITY ENVIRONMENTコマンド(11.5.11参照)の

実行 

SMにおいて,CRT内で送信された制御参照データDOは,カレントSEにある任意の対応する制御参照

データDOよりも優先しなければならない。 

証明書所持者許可書 認証手続きでは,カード検証可能な証明書を使用してもよい。すなわち,公開鍵を

使用したVERIFY CERTIFICATE処理によってカードが解釈し確認するテンプレートを使用することがで

きる(JIS X 6320-8参照)。そのような証明書では,産業間共通利用DO“5F4C”によって証明書所持者許

可書(例えば,役割識別子)を伝えてもよい。そのような(DO“5F4C”の)データ要素が,データ又は

機能へのアクセスを果たすために満足すべきセキュリティ条件で使用される場合,認証手続きについて記

述する認証(AT)用の制御参照テンプレート内にDO“5F4C”が存在しなければならない。 

注記1 ISO/IEC 7816-9の第1版では,タグ“5F4B”は,証明書所持者許可書(5バイト以上のデー

タ要素)を参照している。一方,ISO/IEC 7816-6の第1版の追補1:2000では,タグ“5F4B”

は,IC製造業者識別子(1バイトのデータ要素)を参照している。したがって,JIS X 6320

規格群 [6] では,タグ“5F4B”の使用を避ける。 

注記2 JIS X 6320-6:2006では,証明書所持者許可書としてタグ“5F4C”,及びIC製造業者識別子と

してタグ“5F4D”を規定している。 

アクセス制御 カードは,アクセス制御のために使用するセキュリティ環境を,産業間共通利用SEテン

プレート(タグ“7B”)としてEF内に格納してもよい(表10タグ“8D”参照)。アプリケーションは,

アプリケーション選択で設定されたVA中にDO“7B”を格納してもよい(例えば,第一世代DO)。産業

間共通利用SEテンプレート(タグ“7B”)では,状況依存クラスをセキュリティ環境DOのために予約す

る。表59に示すとおり,アクセス制御に使用する全てのSEについて,産業間共通利用SEテンプレート

は,SEID DO“80”,任意選択のLCS DO“8A”,任意選択の一つ以上の暗号機構識別子テンプレート(タ

グ“AC”)及び一つ以上のCRT(SMタグの“A4”,“A6”,“AA”,“B4”,“B6”及び“B8”)を含んでい

る。 

表59−セキュリティ環境DO 

タグ 

値 

“80” 

SEID(1バイト,必須) 

“8A” 

LCS(1バイト,7.4.10及び表14参照),任意選択 

“AC” 

暗号機構識別子テンプレート(9.2参照),任意選択 

“A4”,“A6”,“AA”,“B4”,“B6”,“B8” 

CRT(10.3.1参照) 

− タグ“7B”配下の状況依存クラスで,上記以外のDOは,ISO/IEC JTC 1/SC 17が予約する。 

background image

74 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

SEテンプレートのDO“8A”の値フィールドが,構造のLCS(例えば,表10のDO“8A”参照)と一

致する場合だけ,そのSEテンプレートは構造(箇条7参照)に適用可能である。SEテンプレート中に

DO“8A”が存在しない場合,そのSEテンプレートは,活性化された処理可能状態のときに有効である。 

SEテンプレート内で,あるCRTが同じタグで示される複数のDO(例えば,鍵参照を規定するDO)を

含む場合,それらのDOの少なくとも一つを満足しなければならない(OR条件)。 

SE読出し カレントSEの全てのCRTは,P1-P2に“004D”(拡張ヘッダリスト,8.4.5参照)を設定し,

コマンドデータフィールドに,CRTタグ及びこれに続く長さ情報“80”(拡張ヘッダで長さ情報“80”の

使用について,8.4.1参照)の対を一つ以上含んでいるSEテンプレート(タグ“7B”)を設定したGET DATA

コマンド(INS=“CA”)によって読み出してもよい。また,MANAGE SECURITY ENVIRONMENTコマン

ドのGET指定で読み出してもよい。 

10.3.4 レスポンス記述子テンプレート 

各コマンドデータフィールドは,レスポンス記述子テンプレートを含んでもよい。コマンドデータフィ

ールドにレスポンス記述子テンプレートが存在する場合,レスポンス記述子テンプレートは,要求される

SM DOをレスポンスデータフィールドで指定しなければならない。レスポンス記述子テンプレート自身に

は,そのセキュリティ機構はまだ適用されない。受信側のエンティティは,レスポンスデータフィールド

を構築するときにそれらを適用しなければならない。コマンドデータフィールドの処理に使用されるセキ

ュリティ項目(アルゴリズム,利用モード,鍵及び初期データ)は,レスポンスデータフィールドの処理

に使用されるものとは異なってもよい。次の規則を適用する。 

− カードは,個々の基本SM DOの空所を埋めなければならない。 

− レスポンス記述子テンプレートで指定された個々のCRTは,レスポンス内において,セキュリティ機

構,ファイル及び鍵のための同じ制御参照DOと同じ位置になければならない。 

− レスポンス記述子テンプレートが補助データを提供する場合,各々のDOは,応答するときに空で

なければならない。 

− 補助データのための空の参照DOがレスポンス記述子テンプレート内に存在する場合,応答すると

きにそのオブジェクトの空所を埋めなければならない。 

− 選択されたセキュリティ項目を使用した当該セキュリティ機構によって,カードは,要求された全て

の基本SM DOを生成しなければならない。 

10.4 コマンドレスポンス対へのSMの影響 

図6に,C-RPを示す。 

コマンドヘッダ部 

コマンド本体部 

CLA INS P1 P2 

(Lcフィールド)(データフィールド)(Leフィールド) 

レスポンス本体部 

レスポンス後続部 

(データフィールド) 

SW1-SW2 

図6−コマンドレスポンス対 

産業間共通利用クラスのC-RPをSM化する(5.4.1参照)。すなわち,ビットb8〜b6が000であるCLA

のビットb4を0から1に変更するとき,又はビットb8〜b7が01であるCLAのビットb6を0から1に変

更するときに,次の規定を適用する。記法CLA*は,SMの適用がCLAで示されていることを意味する。 

− SM化したコマンドデータフィールドは,SMフィールドとなる。このSMフィールドは,次のとおり

background image

75 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

構成しなければならない。 

− コマンドデータフィールドが存在する場合(Nc>0),平文DO(SMタグ“80”,“81”,“B2”及び“B3”)

又は機密性用DO(SMタグ“84”,“85”,“86”及び“87”)のいずれかによって,Ncバイトを伝えな

ければならない。 

− 4バイトのコマンドヘッダは,保護のためにカプセル化(SMタグ“89”)してもよい。 

− Leフィールドが存在する場合,新しいLeフィールド(“00”に設定されたバイトだけを含む。)及び

Le DO(SMタグ“96”及び“97”)が存在しなければならない。存在する場合,Le DOの値フィール

ドは,保護されていないレスポンスのためにLeを提供しなければならない。空のLe DO(“9600”又

は“9700”)は,いずれも最大値,すなわち,新しいLeフィールドが短縮か拡張されているかに依存

して256又は65 536を意味する。そうでなければ,保護されていないレスポンスのLeフィールドは, 

− 1バイトの場合,このバイトはLe DOの値フィールドにならなければならない。 

− 2バイトの場合,これら2バイトはLe DOの値フィールドにならなければならない。 

− 3バイトの場合,すなわち,1バイト目が00に設定され任意の2バイトがその後に続く場合,この

2バイトはLe DOの値フィールドにならなければならない。 

警告 一部の実装は,3バイトのLeフィールドを,値フィールドが3バイトのLe DOに符号化する。 

− SM化したレスポンスデータフィールドも,SMフィールドとなる。このSMフィールドは,次のとお

り解釈しなければならない。 

− 平文DO(SMタグ“80”,“81”,“B2”及び“B3”)又は機密性用DO(SMタグ“84”,“85”,“86”

及び“87”)が存在する場合,これらはレスポンスのデータバイトを伝える。 

− 処理状態DO(SMタグ“99”)が存在する場合,これは,保護のためにカプセル化された状態で

SW1-SW2を伝える。処理状態DOの値フィールドが存在しないことは,SW1-SW2が“9000”に設

定された応答を意味する。 

図7は,対応するSM化したC-RPを示す。 

コマンドヘッダ部 

コマンド本体部 

CLA* INS P1 P2 

(新Lcフィールド- {(SM化したデータフィールド)= 

(T- Nc-データバイト)-(T-“01”又は“02”- Le)})-(新Leフィールド) 

レスポンス本体部 

レスポンス後続部 

SM化したデータフィールド=(T-Nr-データバイト)-(T-“02”-SW1-SW2) 

SW1-SW2 

図7−SM化したコマンドレスポンス対 

INSのビットb1を1に設定するとき(奇数INSコード,5.5参照),SM化する前のデータフィールドは,

BER-TLVで符号化しており,それらをカプセル化するためにSMタグ“B2”,“B3”,“84”及び“85”を

使用しなければならない。タグ“80”,“81”,“86”及び“87”の使用を,アプリケーションレベルで指定

している場合は,除く。 

その他の場合(偶数INSコード,5.5参照)は,保護するデータフィールドの書式が必ずしも明白だと

は限らないため,SMタグ“80”,“81”,“86”及び“87”を使用することが望ましい。 

− SM化したデータフィールドは,SMフィールドとなる。それらは,終わりに他のSM DO,例えば,

暗号化チェックサム(SMタグ“8E”)又はディジタル署名(SMタグ“9E”)を含む場合もある。 

− 新しいLcフィールドは,SM化したコマンドデータフィールドのバイト数を符号化する。 

− SM化したレスポンスにデータフィールドが期待されない場合,新しいLeフィールドは存在してはな

76 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

らない。その他の場合,新しいLeフィールドは,“00”に設定されたバイトだけを含まなければなら

ない。 

− レスポンス後続部は,SM化したコマンドを処理した後の受信部の状態を示す。次の特定の誤り状態

を生じてもよい。 

− SW1-SW2が“6987”に設定される場合,期待されたSM DOが見当たらないことを意味する。 

− SW1-SW2が“6988”に設定される場合,SM DOが正しくないことを示す。 

附属書Bは,セキュアメッセージングの実例を示す。 

11 情報交換のためのコマンド 

ここでは,カード内部と外部との情報交換のためのコマンドを規定する。全てのコマンド又は採用した

コマンドの全ての任意選択を採用することを,この規格に準じる全てのカードに対して必須としてはなら

ない。交換を必要とするとき,アプリケーション非依存のカードサービス並びにそれに関連するコマンド

及び任意選択の集合は,箇条12に規定するとおりに使用しなければならない。 

11.1 選択 

物理インタフェース活性化後(5.1参照)の,基本論理チャネルのVAは,7.2.2で定義している。管理

情報バイト(12.1.1参照)又は初期データ列(12.1.2参照)は,暗黙的に選択するアプリケーションを示

してもよい。 

11.1.1は,ファイル,アプリケーション及びDOの選択について記載する。追加のDO選択機能は,11.4.2

に記載する。 

注記 SELECT又はSELECT DATAコマンドでは短縮EF識別子を使用することができないので,DF

のFCP DO“A2”はSELECT又はSELECT DATAコマンドには無関係である。したがって,間

接ファイル参照(7.4.11参照)は,SELECT又はSELECT DATAコマンド処理では生じない。 

11.1.1 SELECT コマンド 

表60に,SELECT C-RPを示す。 

SELECTコマンドは,処理が完了したとき,CLA(5.4.1参照)で番号付けた論理チャネル(5.4.2参照)

を開き,開けない場合(ファイルが閉塞しているなど)でも,その論理チャネルでカレント構造を設定す

る。後続するコマンドは,その論理チャネルを使って暗黙的にカレント構造を参照してもよい。 

選択したDF(MF,アプリケーションDF,DF)は,その論理チャネルにおいてカレントになる[7.2.2

の規則d)及びe)参照]。それまでに選択されていたDFは,その論理チャネルを介しては参照できなくなる。

DFを選択した後に,暗黙のカレントEFをその論理チャネルを使って参照してもよい。 

EFの選択は,当該EF及びその親DFを一組のカレントファイルに設定する[7.2.2の規則f)参照]。 

background image

77 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表60−SELECTコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“A4” 

P1 

表61参照 

P2 

表62参照 

Lcフィールド 

Nc=0のとき存在しない。Nc>0のとき存在する。 

データフィールド  存在しない,ファイル識別子,パス,DF名,又はタグ(P1によって決まる。) 

Leフィールド 

Ne=0のとき存在しない。Ne>0のとき存在する。 

データフィールド  存在しない,又はファイル制御機能(P2による。) 

SW1-SW2 

例えば,“6283”,“6284”,“6A80”,“6A81”,“6A82”,“6A86”,“6A87”,“6A88”と関連
するとき,表5及び表6を参照 

表61−SELECTコマンドのP1の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

コマンドデータフィールド 

ファイル識別子による選択 

MF,DF又はEFを選択 

ファイル識別子又は存在しない。 

子DFを選択 

DFを参照するファイル識別子 

カレントDF配下のEFを選択 

EFを参照するファイル識別子 

カレントDFの親DFを選択 

存在しない。 

DF名による選択 

DF名による選択 

例えば,(右端を切り詰めた)アプリ
ケーション識別子 

パスによる選択 

MFからの選択 

MF識別子なしのパス 

カレントDFからの選択 

カレントDF識別子なしのパス 

DOの選択 

カレントテンプレートのDOを選択 

カレントテンプレートに属するタグ 

カレントテンプレートを設定してい
る構造化DOの親DOを選択 

存在しない。 

− 他の値は,RFUとする。 
− ソフトウェア機能バイト1(表117参照)は,管理情報バイト(12.1.1参照)又はEF.ATR/INFO(12.2.2参照)

の中に存在するとき,カードが提供する選択手段を示す。 

background image

78 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表62−SELECTコマンドのP2の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − 

該当するファイル又はDOの指定 

− − 

− 先頭又は唯一のものを指定 

− − 

− 最終のものを指定 

− − 

− 次のものを指定 

− − 

− 前のものを指定 

− − レスポンスファイル制御情報(7.4.2及び表8参照) 

− − − FCIテンプレートが戻される。FCIのタグ及び長さを任意選択使用。 

− − − FCPテンプレートが戻される。CPのタグ及び長さを必須使用。 

− − − FMDテンプレートが戻される。FMDのタグ及び長さを必須使用。 

− タグリストの構造化DO選択によるテンプレート集合に属するタグが

戻される。 

− − − Leフィールドが存在しない場合レスポンスデータなし。又は,Leフィ

ールドが存在する場合,個別利用。 

− 他の値は,RFUとする。 

別段の定めがない限り,次の規則は,一つのDF階層構造内の開いている各論理チャネルに適用する。 

− カレントEFを変更する場合又はカレントEFがなくなる場合,元のカレントEFに特有のセキュリテ

ィステータスは,無効にしなければならない。 

− カレントDFが元のカレントDFの子又は元のカレントDFと同一の場合,元のカレントDFに特有の

セキュリティステータスは,維持しなければならない。 

− カレントDFが元のカレントDFの子でなく,かつ,元のカレントDFと同一でない場合,元のカレン

トDFに特有のセキュリティステータスは,無効にしなければならない。元のカレントDF及び新し

いカレントDFに共通の先祖DFのセキュリティステータスは,維持しなければならない。 

注記 先祖ファイルとは,階層構造中で該当ファイルの上位にあるDFを指す。 

P1を“00”に設定した場合,カードは,ファイル識別子の特定な符号化又はコマンド処理状況のいずれ

かによって,選択するファイルがMF,DF又はEFかを判別する。 

P2を“00”に設定し,コマンドデータフィールドが, 

− ファイル識別子を提供する場合,そのファイル識別子は,三つの環境,すなわち,カレントDF直下

の子,親DF及び親DF直下の子において唯一でなければならない。 

− 存在しないか“3F00”に設定した場合,MFを選択しなければならない。 

P1を“04”に設定した場合,コマンドデータフィールドはDF名とする。これは右端を切り詰めたアプ

リケーション識別子(12.2.3参照)であってもよい。部分DF名を採用している場合には,同じデータフ

ィールドをもつ連続するコマンドは,そのデータフィールドに一致するDF名をもつDFを選択しなけれ

ばならない。すなわち,コマンドデータフィールドとDF名が前方一致するDFを選択する。カードがデ

ータフィールドのないSELECTコマンドを受理する場合,DFの全て又は部分集合を連続的に選択するこ

とができる。 

P1を“10”に設定した場合,コマンドデータフィールドは,カレントテンプレートに属するタグとする。

選択されたDOは,カレントDOになる。選択されたDOが構造化の場合,テンプレートをカレントテン

プレートとして設定する。複数のDOのインスタンスを扱うために,P2のビットb1 b2(表62参照)の使

用を必須とする。 

Leフィールドを“00”に設定したバイトだけを含んでいる場合には,指定した任意選択に対応する全バ

79 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

イトは,短縮Leフィールドでは256の範囲で,拡張Leフィールドでは65 536の範囲で返すことが望まし

い。Leフィールドが存在しない場合,選択した構造の利用可能な制御情報(CP及び/又はFMD)を,DO

の扱いを通じて回復してもよい(11.4.3及び11.4.4参照)。 

11.1.2 MANAGE CHANNEL コマンド 

表63に,MANAGE CHANNEL C-RPを示す。 

MANAGE CHANNELコマンドは,処理が完了したとき,基本論理チャネル以外の論理チャネル(5.4.2

参照),すなわち,1〜19(これよりも大きい番号は,RFUとする。)の論理チャネルを開閉する。リセッ

ト機能は任意の論理チャネルに適用してもよい。 

チャネルを開く機能は,基本論理チャネル以外に新しい論理チャネルを開く。カードがチャネル番号を

割り当てるか,又はチャネル番号をカードに与えるかを,選択することができる。 

− P1のビットb8及びb7を00(すなわち,他の6ビットがRFUとしているので,P1は,“00”に設定

される。)に設定する場合,次のとおりMANAGE CHANNELは,1〜19の番号が付けられたチャネル

を開かなければならない。 

− P2を“00”に設定する場合,Leフィールドは,“01”(短縮形式)又は“000001”(拡張形式)に設

定され,レスポンスデータフィールドは,カードによって“01”〜“13”に割り当てられた0でない

チャネル番号を符号化するための1バイトで構成する。 

− P2を“01”〜“13”に設定する場合,それは外部的に割り当てられた0でないチャネル番号を符号化

し,Leフィールドは存在してはならない。 

− 基本論理チャネル(CLAのチャネル番号が0に符号化)からチャネルを開く機能を実行した後,MF

又は省略時アプリケーションDFを,新しい論理チャネル上のカレントDFとして暗黙的に選択しな

ければならない。 

− 基本でない論理チャネル(CLAのチャネル番号が0でない値に符号化)からチャネルを開く機能を実

行した後,CLAで示された論理チャネル上のカレントDFは,7.2.2の規則e)に従って,新しい論理チ

ャネル上のカレントDFにならなければならない。 

チャネルを閉じる機能は,明示的に基本以外の論理チャネルを閉じる。Leフィールドは存在してはなら

ない。チャネルを閉じた後,その論理チャネルは再使用できなければならない。P1のビットb8及びb7を

10(すなわち,他の6ビットがRFUとしているので,P1は“80”に設定される。)に設定する場合,次の

とおりMANAGE CHANNELは,1〜19の番号が付けられたチャネルを閉じなければならない。 

− P2を“00”に設定する場合,CLAで付番された番号(0でないチャネル番号)の論理チャネルは閉じ

なければならない。 

− P2を“01”〜“13”に設定する場合,P2で付番された番号の論理チャネルは閉じなければならない。 

警告 CLAが,基本論理チャネルもP2で付番された論理チャネルも示さない場合,チャネルを閉じ

る機能は中断してもよい。“8001”〜“8013”の範囲で符号化されたP1-P2は,今後使用を避け

る。 

リセット機能は,CLAによって定義した任意の論理チャネルを明示的に閉じて再び開く。Leフィールド

は存在してはならない。リセット後の論理チャネル上のVAは,7.2.2に定義している。この論理チャネル

上で設定されていたセキュリティステータスは,無効にしなければならない。 

基本論理チャネルをリセットし,追加の論理チャネルを全て閉じるコマンドは,基本論理チャネル上で

送らなければならない。 

注記 APDUレベルで,この機能(P1-P2=“4001”)は物理インタフェース(5.1参照)を活性化する

background image

80 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

のと等価である。 

表63−MANAGE CHANNELコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“70” 

P1-P2 

“0000” 

レスポンスデータフィールドで付番される論理チャネルを開く。 

“0001”〜“0013” P2で付番される論理チャネルを開く。 

“8000” 

CLAで付番される論理チャネルを閉じる(基本論理チャネルを除く。)。 

“8001”〜“8013” P2で付番される論理チャネルを閉じる。 

“4000” 

CLAで付番される論理チャネルをリセットする。 

“4001” 

基本論理チャネルをリセットし,追加の論理チャネルを全て閉じる。 

他の値 

RFU 

Lcフィールド 

Nc=0のため存在しない。 

データフィールド  存在しない。 

Leフィールド 

Ne=0のとき存在しない。Ne=1のとき存在する。 

データフィールド  存在しない(P1-P2を“0000”に設定しない。),又は“01”〜“13”(P1-P2を“0000”に設定) 

SW1-SW2 

例えば,“6200”,“6482”,“6881”,“6A81”と関連するとき,表5及び表6を参照 

11.2 データ単位の扱い 

11.2.1 データ単位 

データ単位を提供する各EF内で,オフセットは各データ単位を参照しなければならない。EFの最初の

データ単位に対し0から,オフセットは,その後のデータ単位ごとに一つずつ増加される。オフセットデ

ータ要素は,最小バイト数で2進符号化する。EFに含まれていないデータ単位への参照は,誤りとする。 

カードは,管理情報バイト(12.1.1参照),EF.ATR/INFO(12.2.2参照)及び任意のファイル制御情報(表

10のタグ“82”参照)によってデータ符号化バイト(表118参照)を提供することができる。データ符号

化バイトは,データ単位のサイズを定める。カードが幾つかの場所でデータ符号化バイトを提供する場合,

7.4.5がどのデータ符号化バイトを考慮しなければならないかを規定する。 

11.2.2 共通事項 

このグループに属するコマンドは,データ単位を提供しないEFに適用した場合中断しなければならな

い。セキュリティステータスが機能(すなわち,読取り,書込み,更新,削除,検索又は比較)に対して

定義したセキュリティ属性を満足する場合に限り,そのコマンドは,EF上で実行することができる。 

このグループの各コマンドは,短縮EF識別子又はファイル識別子のいずれかを使用してもよい。コマ

ンド発行時にカレントEFがある場合,プロセスは,単に対応するビットを全て0に設定することによっ

てそのEFを対象として完了してもよい。プロセスが完了する場合,識別されたEFは,カレントになる。 

INS P1 P2 このグループのコマンドは,全て,INSのビットb1及びP1のビットb8を次のとおり使用し

なければならない。 

− INSのビットb1を0,及びP1のビットb8を1に設定する場合,P1のビットb7及びb6は,00(他の

値はRFU)に設定され,P1のビットb5〜b1で短縮EF識別子を符号化する。また,P2(8ビット)は,

コマンドで参照したEFのオフセット値0〜255を符号化する。 

− INSのビットb1を0,及びP1のビットb8を0に設定する場合,P1-P2(15ビット)は,カレントEF

におけるオフセット値0〜32 767を符号化する。 

− INSのビットb1を1に設定する場合,P1-P2は,EFを識別しなければならない。P1-P2の最初の11

background image

81 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

ビットが0に設定され,P2のビットb5〜b1が全て等しくなく,かつ,カード及び/又はEFが短縮

EF識別子による選択を提供する場合,P2のビットb5〜b1で短縮EF識別子(1〜30の数)を符号化

する。その他の場合は,P1-P2は,ファイル識別子とする。“0000”に設定されたP1-P2は,カレント

EFを識別する。少なくとも一つのオフセットDO“54”が,コマンドデータフィールドに存在しなけ

ればならない。データは,コマンド又はレスポンスのデータフィールドに存在する場合,自由裁量DO

“53”(DO“73”の使用は避ける。)でカプセル化しなければならない。 

このグループのコマンドでは, 

− “63CX”に設定したSW1-SW2は,内部再試行の処理後,メモリ状態の変更に成功したことを示す。

“X”>“0”は,再試行回数を符号化する。“X”=“0”は,再試行回数が提供されないことを意味する。 

− “6B00”に設定したSW1-SW2は,オフセットがEFの外を示していることを示すために使用するの

が望ましい。 

11.2.3 READ BINARYコマンド 

表64に,READ BINARY C-RPを示す。 

レスポンスデータフィールドは,データ単位を提供するEFの内容又はその一部を与える。Leフィール

ドが“00”に設定された1バイトだけを含んでいる場合,ファイルの終端までの全てのバイトは,短縮Le

フィールドでは256の範囲で,又は拡張Leフィールドでは65 536の範囲で読まれることが望ましい。 

表64−READ BINARYコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“B0”又は“B1” 

P1-P2 

INS=“B0” 

オフセット値は必須,短縮EF識別子も可能 

11.2.2参照 

INS=“B1” 

EF識別子又は短縮EF識別子 

Lcフィールド 

Nc=0のとき存在しない。Nc>0のとき存在する。 

データフィールド  INS=“B0” 

存在しない。 

INS=“B1” 

オフセットDO 

Leフィールド 

Ne>0のため存在する。 

データフィールド  INS=“B0” 

読取りデータ 

INS=“B1” 

読取りデータをカプセル化する自由裁量DO 

SW1-SW2 

例えば,“6281”,“6282”,“6700”,“6981”,“6982”,“6986”,“6A81”,“6A82”,
“6B00”と関連するとき,表5及び表6を参照 

11.2.4 WRITE BINARYコマンド 

表65に,WRITE BINARY C-RPを示す。 

WRITE BINARYコマンドは,ファイル属性に従ってEF内で次の動作のいずれか一つを開始する。 

1) カード内の既存ビットとコマンドデータフィールドで与えられたビットとの論理和(ファイルのビッ

トの論理的消去状態は0とする。)。 

2) コマンドデータフィールドで与えられたビットの一度だけの書込み(データ単位の列が論理的消去状

態でない場合,コマンドは中断しなければならない。)。 

3) カード内の既存ビットとコマンドデータフィールドで与えられたビットとの論理積(ファイルのビッ

トの論理的消去状態は1とする。)。 

データ符号化バイトの省略時,すなわち,データ符号化バイト(11.2.1参照)が有効でないとき,その

EFに対して動作1)を適用しなければならない。 

background image

82 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表65−WRITE BINARYコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“D0”又は“D1” 

P1-P2 

INS=“D0” オフセット値は必須,短縮EF識別子も可能 

11.2.2参照 

INS=“D1” EF識別子又は短縮EF識別子 

Lcフィールド 

Nc>0のため存在する。 

データフィールド  INS=“D0” 書込みデータ単位の列 

INS=“D1” オフセットDO及び書込みデータ単位の列をカプセル化する自由裁量DO 

Leフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“63CX”(11.2.2参照),“6581”,“6700”,“6981”,“6982”,“6B00”と関連する
とき,表5及び表6を参照 

11.2.5 UPDATE BINARYコマンド 

表66に,UPDATE BINARY C-RPを示す。 

UPDATE BINARYコマンドは,コマンドデータフィールドで与えられたビットでEF内の既存ビットの

更新を開始する。処理が完了した時,各指定されたデータ単位の各ビットは,コマンドデータフィールド

で指定した値となる。 

表66−UPDATE BINARYコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“D6”又は“D7” 

P1-P2 

INS=“D6” オフセット値は必須,短縮EF識別子も可能 

11.2.2参照 

INS=“D7” EF識別子又は短縮EF識別子 

Lcフィールド 

Nc>0のため存在する。 

データフィールド  INS=“D6” 更新データ単位の列 

INS=“D7” オフセットDO及び更新データ単位の列をカプセル化する自由裁量DO 

Leフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“63CX”(11.2.2参照),“6581”,“6700”,“6981”,“6982”,“6B00”と関連する
とき,表5及び表6を参照 

11.2.6 SEARCH BINARYコマンド 

表67に,SEARCH BINARY C-RPを示す。 

SEARCH BINARYコマンドは,データ単位を提供するEF内の検索を開始する。レスポンスデータフィ

ールドは,データ単位のオフセットを与える。EF内の返されたオフセット位置のバイト列は,コマンドデ

ータフィールドの検索列と同じ値をもたなければならない。Leフィールドが存在しない,又は一致するも

のが見つからない場合,レスポンスデータフィールドは,存在しない。検索列がデータフィールドに存在

しない場合,レスポンスデータフィールドは,論理的消去状態のデータ単位の先頭オフセットを与える。 

background image

83 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表67−SEARCH BINARYコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“A0”又は“A1” 

P1-P2 

INS=“A0” オフセット値は必須,短縮EF識別子も可能 

11.2.2参照 

INS=“A1” EF識別子又は短縮EF識別子 

Lcフィールド 

Nc=0のとき存在しない。Nc>0のとき存在する。 

データフィールド 

INS=“A0” 存在しない,又は検索列 

INS=“A1” オフセットDO及び検索列をカプセル化する自由裁量DO 

Leフィールド 

Ne=0のとき存在しない。Ne>0のとき存在する。 

データフィールド 

INS=“A0” 存在しない,又はコマンドデータフィールドに合致する最初のデータ単位

のオフセット 

INS=“A1” 検索列に合致する最初のデータ単位を示すオフセットDO 

SW1-SW2 

例えば,“6282”,“6982”,“6B00”と関連するとき,表5及び表6を参照 

11.2.7 ERASE BINARYコマンド 

表68に,ERASE BINARY C-RPを示す。 

ERASE BINARYコマンドは,与えられたオフセットから始まるEFの内容又は内容の一部を連続して論

理的消去状態に設定する。 

− INS=“0E”のとき,データフィールドにオフセットが存在する場合には,コマンドデータフィールド

は消去されない最初のデータ単位のオフセットを符号化する。このオフセットは,P1-P2で符号化さ

れたものよりも大きい値でなければならない。データフィールドが存在しない場合,コマンドは,フ

ァイルの最後まで消去する。 

− INS=“0F”のとき,オフセットが存在する場合には,コマンドデータフィールドは,0〜2個のオフセ

ットDOで構成しなければならない。オフセットがない場合,このコマンドは,ファイル内のデータ

単位を全て消去する。オフセットが一つの場合,消去される先頭データ単位を示し,このコマンドは

ファイルの最後まで消去する。オフセットが二つの場合,データ列を定義する。第2のオフセットは,

消去されない最初のデータ単位を示し,第1のオフセットよりも大きい値でなければならない。 

表68−ERASE BINARYコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“0E”又は“0F” 

P1-P2 

INS=“0E” 

オフセット値は必須,短縮EF識別子も可能 

11.2.2参照 

INS=“0F” 

EF識別子又は短縮EF識別子 

Lcフィールド 

Nc=0のとき,存在しない。Nc>0のとき,存在する。 

データフィールド  INS=“0E” 

存在しない,又は消去されない最初のデータ単位のオフセット 

INS=“0F” 

0〜2個のDO 

Leフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“63CX”(11.2.2参照),“6581”,“6700”,“6981”,“6982”,“6B00”と関連する
とき,表5及び表6を参照 

11.2.8 COMPARE BINARY機能 

この機能は,COMPAREコマンドで提供される(11.6.1参照)。 

84 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

11.3 レコードの扱い 

11.3.1 レコード 

レコードを提供する各EF内において,レコード番号及び/又はレコード識別子によって各レコードを

参照しなければならない。EFに含まれていないレコードへの参照は,誤りとする。 

レコード番号による参照 各レコード番号は,唯一,かつ,連続的に付番する。 

− 順編成構造を提供する各EFにおいて,書込み又は追記する場合,レコード番号は,連続して割り当

てなければならない。すなわち,生成した順番で,先頭レコード(第1レコード)は,最初に生成さ

れたレコードとする。 

− 循環順編成構造を提供するEFにおいて,レコード番号は,逆の順番に連続して割り当てなければな

らない。すなわち,先頭レコード(第1レコード)は,最後に生成されたレコードとする。 

次の規則は,順編成構造及び循環順編成構造のために定義する。 

− レコード番号がゼロ(符号化された“00”)は,カレントレコード(すなわち,レコードポインタによ

って参照されたレコード)を参照しなければならない。 

レコード識別子による参照 各レコード識別子は,アプリケーションが用意する。複数のレコードは,同

じレコード識別子をもってもよい。その場合,レコードに含まれているデータは,それらを識別するため

に使用してもよい。データフィールドが簡易符号化TLVデータオブジェクトのレコードの場合,レコード

識別子は,データオブジェクトの最初のバイト,すなわち,簡易符号化TLVのタグとする。 

レコード識別子による参照は,レコードポインタの管理を行わなければならない。カードの物理インタ

フェースを活性化すること,論理チャネルをリセットすること,SELECTコマンド,及びEFへアクセス

するために正当な短縮EF識別子を使用する全てのコマンドが,レコードポインタに影響してもよい。レ

コード番号による参照は,レコードポインタに影響してはならない。 

レコード識別子で参照するごとに,対象となるレコードの論理的位置を示さなければならない。その論

理的位置とは,最初又は最後に該当するレコード位置,レコードポインタを基準として前又は後の該当す

るレコード位置となる。 

− 順編成構造を提供する各EFでは,書込み又は追記する場合,論理的位置は,生成の順序で連続して

割り当てなければならない。すなわち,最初に生成されたレコードは,論理的に最初の位置にあるこ

とになる。 

− 循環順編成構造を提供する各EFでは,論理的位置は,逆の順序で連続して割り当てなければならな

い。すなわち,最後に生成されたレコードは,論理的に最初の位置にあることになる。 

次の規則は,順編成構造及び循環順編成構造のために定義する。 

− 最初に該当するレコード位置は,指定された識別子を備えた最初の論理的レコード位置としなければ

ならない。最後に該当するレコード位置は,指定された識別子を備えた最後の論理的レコード位置と

しなければならない。 

− カレントレコードがある場合,後に該当するレコード位置は,指定された識別子を備えたカレントレ

コードよりも論理的に後で直近のレコード位置としなければならない。前に該当するレコード位置は,

指定された識別子を備えたカレントレコードよりも論理的に前で直近のレコード位置としなければな

らない。 

− カレントレコードがない場合,後に該当するレコード位置は,最初に該当するレコード位置と等しい。

前に該当するレコード位置は,最後に該当するレコード位置と等しくなければならない。 

− レコード識別子がゼロ(符号化された“00”)は,レコード識別子から独立して,番号順における最初,

background image

85 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

最後,後の,又は前のレコード位置を示さなければならない。 

11.3.2 共通事項 

このグループに属するコマンドは,レコードを提供しないEFに適用した場合中断しなければならない。

セキュリティステータスが機能(すなわち,読取り,書込み,追加,更新,検索,消去,活性化又は非活

性化)に対して定義したセキュリティ属性を満足する場合に限り,EF上で実行することができる。 

EFのレコードは,レコードライフサイクルを提供してもよい。一般に,非活性化レコードについては,

READ RECORD,WRITE RECORD,UPDATE RECORD,ERASE RECORD,APPEND RECORD,及び

COMPARE(RECORD)コマンドはアクセスできない。これらのコマンドが使用されている場合,各々の

コマンドは,状態バイト“6287”(少なくとも参照した記録の一つは,非活性化されている。)を返す。SEARCH 

RECORDコマンドを実行するとき,非活性化したレコードは,無視しなければならない。詳細及び上述し

た総則の例外は,次に記載する。 

このグループの二つのコマンド(読取り系,又は更新系)は,与えられたレコードの一部に対する動作

(部分読取り,部分更新)を実行するために奇数INSコード(データフィールドは,BER-TLVで符号化)

を用いてもよい。その場合オフセットは,レコード中の各バイトを参照しなければならない。オフセット

は,レコードの先頭バイトが0から始まり,レコード内の個々の後続バイトに対し1ずつ増加する。レコ

ードに含まれていないバイトへの参照は誤りとなる。必要であれば,オフセットデータ要素は,2進数で

符号化されタグ“54”によって参照される。データは,コマンド又はレスポンスのデータフィールドに存

在する場合,自由裁量DO“53”(“73”の使用は避ける。)内にカプセル化しなければならない。 

このグループの各コマンドは,短縮EF識別子を用いてもよい。処理が完了した場合,識別されたEFは

カレントになり,レコードポインタは,リセットされる。コマンド発行時にカレントEFがある場合,プ

ロセスは,EFを示さずに(対応する5ビットを全て0に設定することによって)実行してもよい。 

P1 各レコード番号又は識別子は,P1の値“01”〜“FE”によって符号化され,1〜254の番号となる。ゼ

ロ(符号化された“00”)は特別の目的で予約する。255(符号化された“FF”)は,将来使用するために

予約する。 

注記 レコードの数がレコードを扱うコマンドの番号付け範囲(“01”〜“FE”)を超える場合,レコー

ドは,例えば,レコード識別子が同じ次のレコードを指定する方法によって,扱うことができ

る。 

P2 ビットb8〜b4は,表69に従い短縮EF識別子とする。ビットb3〜b1は,コマンドに依存する。 

表69−P2の短縮EF識別子の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − カレントEF 

全ては等しくない。 

− − − 短縮EF識別子(1〜30の値) 

− − − 将来使用するために予約 

このグループのコマンドでは,“63CX”に設定されたSW1-SW2は,内部再試行の処理後,メモリ状態

の変更に成功したことを示す。“X”>“0”は,再試行回数を符号化する。“X”=“0”は,再試行回数が提

供されないことを意味する。 

11.3.3 READ RECORD(S)コマンド 

表70に,READ RECORD(S) C-RPを示す。 

レスポンスデータフィールドは,EF内の指定されたレコードの内容(又は単一レコードの先頭部分の内

background image

86 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

容)の一部を与える。 

P1及びP2で参照されるレコードのLCSが非活性化された場合は,コマンドは,状態バイト“6287”で

終了し,レスポンスデータフィールドは空でなければならない。 

INS=“B2”,かつ,レコードが簡易符号化TLVデータオブジェクト(6.1参照)の場合,レスポンスデ

ータフィールドは,図8のとおりである。TLV構造とNrとを比較することによって,唯一のレコード(1

レコード読取り)又は最後のレコード(全レコード読取り)が不完全か,完全か,又はパディングがされ

ているかどうかが識別できる。 

注記 レコードがデータオブジェクトでない場合,全レコード読取り機能は,区切りのないレコード

を受け取ることになる。 

INS=“B3”の場合,コマンドは,P2で示す任意選択機能“全レコード読出し”を提供しない。このコ

マンドは,P1によって参照されたレコードを部分的に読み取る。このコマンドデータフィールドは,レコ

ード内で読まれる最初のバイトを示すオフセットDO“54”を含まなければならない。レスポンスデータ

フィールドは,読み取ったデータをカプセル化する自由裁量DO“53”を含まなければならない。 

表70−READ RECORD(S)コマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“B2”又は“B3” 

P1 

レコード番号若しくはレコード識別子,又はカレントレコードを参照する“00” 

P2 

表71参照 

Lcフィールド 

Nc=0のとき存在しない。Nc>0のとき存在する。 

データフィールド  INS=“B2” 

存在しない。 

INS=“B3” 

オフセットDO 

Leフィールド 

Ne>0のため存在する。 

データフィールド  INS=“B2” 

読出しデータ 

INS=“B3” 

読出しデータをカプセル化する自由裁量DO 

SW1-SW2 

例えば,“6281”,“6282”,“6700”,“6981”,“6982”,“6A81”,“6A82”,“6A83”と関連
するとき,表5及び表6を参照 

表71−READ RECORD(S)コマンドのP2の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − 表69に従った短縮EF識別子 

− − − − − 

P1がレコード識別子 

− − − − − 

− 最初の該当レコードを読み出す。 

− − − − − 

− 最後の該当レコードを読み出す。 

− − − − − 

− 次の該当レコードを読み出す。 

− − − − − 

− 直前の該当レコードを読み出す。 

− − − − − 

P1がレコード番号 

− − − − − 

− P1で示すレコードを読み出す。 

− − − − − 

− P1で示すレコードから最後まで全レコードを読み出す(INS=“B2”)。 

− − − − − 

− 最初からP1で示すレコードまで全レコードを読み出す(INS=“B2”)。 

RFU 

Leフィールドを“00”に設定したバイトだけを含んでいる場合,コマンドは,P2のビットb3〜b1によ

って,短縮Leフィールドでは256の範囲又は拡張Leフィールドでは65 536の範囲で,要求された単一の

background image

87 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

レコード又は要求された連続するレコードのいずれかを完全に読み出すことが望ましい。 

ケースa−1レコードの部分読取り(Leフィールドは,“00”以外が設定されたバイトを含む。) 

Tn(1バイト) 

Ln(1又は3バイト) 

Vnの先頭からのバイト 

←----------------------------------------------------- Nr バイト----------------------------------------------------------------→ 

ケースb−1レコードの完全読取り(Leフィールドは,“00”が設定されたバイトだけを含む。) 

Tn(1バイト) 

Ln(1又は3バイト) 

Vnの全てのバイト 

ケースc−連続レコードの部分読取り(Leフィールドは,“00”以外が設定されたバイトを含む。) 

Tn - Ln - Vn 

… 

Tn+m - Ln+m - Vn+m (レコードの先頭からのバイト) 

←--------------------------------------------------- Nr バイト-------------------------------------------------------------------→ 

ケースd−ファイル終端までの複数レコード読取り 

(Leフィールドは,“00”が設定されたバイトだけを含む。) 

Tn - Ln - Vn 

… 

Tn+m - Ln+m - Vn+m 

図8−INS=“B2”のレスポンスデータフィールド 

(レコードが簡易符号化TLVデータオブジェクトのとき) 

11.3.4 WRITE RECORDコマンド 

表72に,WRITE RECORD C-RPを示す。 

WRITE RECORDコマンドは,一つのEF内でファイル属性に従い次の動作のいずれか一つを開始する。 

1) コマンドデータフィールドで与えられた1レコードの一度だけの書込み(レコードが論理的消去状態

でない場合,コマンドは,中断しなければならない。)。 

2) カード内の既存レコードのデータバイトとコマンドデータフィールドのレコードのデータバイトとの

論理和。 

3) カード内の既存レコードのデータバイトとコマンドデータフィールドのレコードのデータバイトとの

論理積。 

データ符号化バイトの省略時,すなわち,データ符号化バイトが有効でないとき(11.2.1参照),動作1)

がそのEFに適用されなければならない。 

P1及びP2で参照するレコードのLCSが非活性化の場合は,このコマンドは,レコードの内容を変更せ

ずに状態バイト“6287”で終了する。 

カレントレコードアドレス方式を使用するとき,このコマンドは,書込みに成功したレコードにレコー

ドポインタを設定しなければならない。 

固定長レコードの循環順編成構造をもつEFに適用する場合,“前のレコード”(P2のビットb3〜b1を

011に設定)は,APPEND RECORDと同様に動作する。 

background image

88 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表72−WRITE RECORDコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“D2” 

P1 

レコード番号又はカレントレコードを参照する“00” 

P2 

表73参照 

Lcフィールド 

Nc>0のため存在する。 

データフィールド  書込みレコード 

Leフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“63CX”(11.3.2参照),“6581”,“6700”,“6981”,“6982”,“6986”,“6A81”,
“6A82”,“6A83”,“6A84”,“6A85”と関連するとき,表5及び表6を参照 

表73−WRITE RECORDコマンドのP2の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − 表69に従った短縮EF識別子 

− − − − − 

P1を,“00”に設定 

− − − − − 

− 先頭レコード 

− − − − − 

− 最終レコード 

− − − − − 

− 次のレコード 

− − − − − 

− 前のレコード 

− − − − − 

P1がレコード番号 

− 他の値は,RFUとする。 

レコードが簡易符号化TLVデータオブジェクト(6.1参照)の場合,コマンドデータフィールドは,図

9のとおりである。 

Tn(1バイト) 

Ln(1又は3バイト) 

Vnの全てのバイト 

図9−APDUデータフィールド 

(簡易符号化TLVデータオブジェクトを入れ子にしている一つの完全なレコード) 

11.3.5 UPDATE RECORDコマンド 

表74に,UPDATE RECORD C-RPを示す。 

UPDATE RECORDコマンドは,コマンドデータフィールドで与えられたバイトで,特定されたレコード

の更新を開始する。カレントレコードアドレス方式を使用するとき,コマンドは,更新したレコードにレ

コードポインタを設定しなければならない。 

固定長レコードの順編成又は循環順編成構造をもつEFに適用する場合,更新後のレコード長が既存レ

コードの長さと異なるときは,コマンドは,処理を中断しなければならない。 

可変長レコードの順編成構造をもつEFに適用する場合,更新後のレコード長が既存レコード長と異な

るときは,コマンドを実行してもよい。 

固定長レコードの循環順編成構造をもつEFに適用する場合,“前のレコード”(P2のビットb3〜b1を

011に設定)は,APPEND RECORDと同様に動作する。 

P1及びP2で参照するレコードのLCSが非活性化の場合は,コマンドは,レコードの内容を変更せずに

状態バイト“6287”で終了する。 

background image

89 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

INS=“DC”であり,かつ,レコードが簡易符号化TLVデータオブジェクト(6.1参照)の場合,コマン

ドデータフィールドは,図9のとおりである。 

INS=“DD”の場合,コマンドは,P1によって参照されたレコードを部分的に更新する。コマンドデー

タフィールドは,レコード内の更新される最初のバイトを示すオフセットDO“54”及び更新するデータ

をカプセル化する自由裁量DO“53”(“73”の使用は避ける。)を含まなければならない。 

表74−UPDATE RECORDコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“DC”又は“DD” 

P1 

レコード番号又はカレントレコードを参照する“00” 

P2 

表73(INS=“DC”の場合)又は表75(INS=“DD”の場合)参照 

Lcフィールド 

Nc>0のため存在する。 

データフィールド  INS=“DC” 

更新データ 

INS=“DD” 

オフセットDO及び更新データをカプセル化する自由裁量DO 

Leフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“63CX”(11.3.2参照),“6581”,“6700”,“6981”,“6982”,“6986”,“6A81”,“6A82”,
“6A83”,“6A84”,“6A85”と関連するとき,表5及び表6を参照 

表75−INSが“DD”のUPDATE RECORDコマンドのP2の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − 表69に従った短縮EF識別子 

− − − − − 

P1のレコード番号 

− − − − − 

− 置換 

− − − − − 

− 論理積 

− − − − − 

− 論理和 

− − − − − 

− 排他的論理和 

− 他の値は,RFUとする。 

11.3.6 APPEND RECORDコマンド 

表76に,APPEND RECORD C-RPを示す。 

APPEND RECORDコマンドは,順編成構造をもつEFの終わり又は循環順編成構造をもつEFの始まり

(レコード番号1)のいずれかに新規レコードの書込みを実行する。カレントレコードアドレス方式を使

用する場合,コマンドは,追記が成功したレコードにレコードポインタを設定しなければならない。 

このコマンドをレコードで一杯の順編成構造をもつEFに実行する場合,コマンドは,ファイルに十分

なメモリ容量がないので処理を中断する。 

このコマンドを,レコードで一杯の循環順編成構造をもつEFに実行する場合,最も大きなレコード番

号のレコードが削除される。他の全てのレコード番号は,一つ繰り上げられる。追加されたレコードは,

レコード番号1になる。最も大きなレコード番号のレコードのLCSが非活性化の場合は,コマンドは,EF

内のレコードの内容及び番号を変更せずに状態バイト“6287”で終了する。 

EF内のレコードがレコードライフサイクルをもつ場合,追加されたレコードのLCSは,特に規定がな

い限り活性化状態に設定しなければならない。 

レコードが簡易符号化TLVデータオブジェクト(6.1参照)の場合,コマンドデータフィールドは,図

background image

90 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

9のとおりである。 

表76−APPEND RECORDコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“E2” 

P1 

“00”(他の値は,無効) 

P2 

表73を参照(ただし,ビットb3〜b1を000に設定,他の値は,RFUとする。) 

Lcフィールド 

Nc>0のため存在する。 

データフィールド  追記レコード 

Leフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“63CX”(11.3.2参照),“6287”,“6581”,“6700”,“6981”,“6982”,“6986”,
“6A81”,“6A82”,“6A83”,“6A84”,“6A85”と関連するとき,表5及び表6を参照 

11.3.7 SEARCH RECORDコマンド 

表77に,SEARCH RECORD C-RPを示す。 

SEARCH RECORDコマンドは,EF内に格納されたレコードに対し,単純検索,拡張検索,又は個別利

用検索を実行する。検索は,指定したレコード識別子,又は指定した番号よりも大きいか小さいレコード

番号に制限することができる。検索は,レコード番号の昇順で,又は降順で実行することができる。検索

は,レコードの先頭バイトから(単純検索),レコード内の指定されたオフセットから(拡張検索),又は

レコード内で指定されたバイトに該当する最初の位置から(拡張検索)のいずれかで開始する。レスポン

スデータフィールドは,レコードを提供するEF内の検索条件と一致するレコード番号を示す。このコマ

ンドは,検索条件と一致する最初のレコードにレコードポインタを設定しなければならない。 

順編成構造の可変長レコードをもつEFでは,検索文字列よりも短いレコードを検索してはならない。

順編成又は循環順編成構造の固定長レコードをもつEFでは,検索文字列がレコードよりも長い場合,カ

ードはコマンドの処理を中断しなればならない。 

レコードのLCSが非活性化のレコードは,検索中SEARCH RECORDコマンドを無視しなければならな

い。 

background image

91 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表77−SEARCH RECORDコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“A2” 

P1 

レコード番号若しくはレコード識別子,又はカレントレコードを参照する“00” 

P2 

表78参照 

Lcフィールド 

Nc>0のため存在する。 

データフィールド  単純検索,P2のビットb3及びb2を,11に設定してい

ない。 

検索文字列 

拡張検索,P2のビットb3〜b1を,110に設定。 

検索文字列が続く2バイトの
検索指示(表79参照) 

個別利用検索,P2のビットb3〜b1を,111に設定。 

個別利用 

Leフィールド 

Ne=0のとき,存在しない。Ne>0のとき,存在する。 

データフィールド  存在しない,又はレコード番号 

SW1-SW2 

例えば,“6282”,“6982”と関連するとき,表5及び表6を参照 

− Leフィールドが存在しない場合又は一致するものが見つからない場合,レスポンスデータフィールドは存

在しない。 

− レコード識別子は,唯一でないかもしれないので,レスポンスデータフィールドに示さない。 

拡張検索(P2のビットb3〜b1を110に設定)では,コマンドデータフィールドは,2バイトの検索指

示とその後に続く検索文字列とで構成する。表79は,検索指示の第1バイトを規定する。検索指示の第1

バイトによって,第2バイトはオフセット又は値のいずれかとなる。すなわち,レコードでの検索は,絶

対的な位置を示すこのオフセット(11.3.2参照)から,又はこの値に該当する最初の位置の後から実行し

なければならない。 

表78−SERCH RECORDコマンドのP2の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − 表69に従った短縮EF識別子 

− − − − − 

P1がレコード識別子で単純検索 

− − − − − 

− 最初の該当レコードから昇順 

− − − − − 

− 最終の該当レコードから降順 

− − − − − 

− 次の該当レコードから昇順 

− − − − − 

− 前の該当レコードから降順 

− − − − − 

P1がレコード番号で単純検索 

− − − − − 

− P1から昇順 

− − − − − 

− P1から降順 

− − − − − 

拡張検索(表79参照) 

− − − − − 

個別利用検索 

background image

92 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表79−検索指示の第1バイトの符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − 後続バイトがオフセット(オフセットの位置から実行する。) 

− − − 後続バイトが値(最初に該当する位置から実行する。) 

− − − − − 

P1がレコード識別子 

− − − − − 

− 最初の該当レコードから昇順 

− − − − − 

− 最終の該当レコードから降順 

− − − − − 

− 次の該当レコードから昇順 

− − − − − 

− 前の該当レコードから降順 

− − − − − 

P1がレコード番号 

− − − − − 

− P1から昇順 

− − − − − 

− P1から降順 

− − − − − 

− 次レコードから昇順 

− − − − − 

− 前レコードから降順 

− 他の値は,RFUとする。 

11.3.8 ERASE RECORD(S)コマンド 

表80に,ERASE RECORD(S) C-RPを示す。 

ERASE RECORD(S)コマンドは,P1によって参照するレコードを又はP1によって参照するレコードか

らファイルの最後のレコードまでを連続して論理的消去状態に設定する。消去されたレコード自体は削除

してはならず,WRITE RECORD及びUPDATE RECORDコマンドによってアクセス可能であってもよい。 

P1及びP2で参照するレコードのLCSが非活性化の場合は,コマンドは,レコードの内容を変更せずに

状態バイト“6287”で警告し終了する。 

表80−ERASE RECORD(S)コマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“0C” 

P1 

レコード番号 

P2 

表81参照 

Lcフィールド 

Nc=0のため存在しない。 

データフィールド  存在しない。 

Leフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“6287”,“63CX”(11.3.2参照),“6581”,“6700”,“6981”,“6982”,“6986”,
“6A81”,“6A82”,“6A83”,“6A84”,“6A85”と関連するとき,表5及び表6を参照 

表81−ERASE RECORD(S)コマンドのP2の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − 表69に従った短縮EF識別子 

− − − − − 

P1に指定したレコード番号 

− − − − − 

− レコードP1の消去 

− − − − − 

− P1から最後までの全レコードを消去 

− 他の値は,RFUとする。 

background image

93 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

11.3.9 ACTIVATE RECORD(S)コマンド 

表82に,ACTIVATE RECORD(S)C-RPを示す。 

ACTIVATE RECORD(S)コマンドは,P1及びP2によって参照したレコードのLCSを活性化に設定する。

コマンドは,レコードのポインタに影響を与えてはならない。 

P2によって参照したEFがレコードライフサイクルに対応しない場合,コマンドは,状態バイト“6981”

で異常終了しなければならない。 

指定したレコードが既に活性化の場合,コマンドは,状態バイト“9000”を返さなければならない。 

レコードLCSが非活性化の全てのレコードを活性化するために,ACTIVATE FILEコマンドを使用して

もよい。任意選択で存在するファイルLCS(7.4.10参照)の変更とは独立して,全てのレコードは,活性

化される。 

表82−ACTIVATE RECORD(S)コマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“08” 

P1 

レコード番号 

P2 

表83参照 

Lcフィールド 

存在しない。 

データフィールド  存在しない。 

Leフィールド 

存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“6981”,“6982”,“6986”,“6A82”,“6A83”と関連するとき,表5及び表6を
参照 

表83−ACTIVATE RECORD(S)又はDEACTIVATE RECORD(S)コマンドのP2の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − 表69に従った短縮EF識別子 

− − − − − 

P1に指定したレコード番号 

− − − − − 

− P1のレコードを活性化又は非活性化 

− − − − − 

− P1から最後のレコードまでを活性化又は非活性化 

− 他の値は,RFUとする。 

11.3.10 DEACTIVATE RECORD(S)コマンド 

表84に,DEACTIVATE RECORD(S) C-RPを示す。 

DEACTIVATE RECORD(S)コマンドは,P1及びP2によって参照したレコードのレコードLCSを非活性

化に設定する。コマンドは,レコードのポインタに影響を与えてはならない。 

P2によって参照したEFがレコードライフサイクルに対応しない場合,コマンドは,状態バイト“6981”

で異常終了しなければならない。 

指定したレコードが既に非活性化の場合,コマンドは,状態バイト“9000”を返さなければならない。 

background image

94 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表84−DEACTIVATE RECORD(S)コマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“06” 

P1 

レコード番号 

P2 

表83参照 

Lcフィールド 

存在しない。 

データフィールド  存在しない。 

Leフィールド 

存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“6981”,“6982”,“6986”,“6A82”,“6A83”と関連するとき,表5及び表6を
参照 

11.3.11 COMPARE RECORD機能 

この機能は,COMPAREコマンドで提供される(11.6.1参照)。 

11.4 データオブジェクトの扱い 

11.4.1 共通事項 

このグループのコマンドでは,“63CX”に設定されたSW1-SW2は,内部再試行の処理後,メモリ状態

の変更が成功したことを示す。“X”>“0”は,再試行回数を符号化し,“X”=“0”は,再試行回数が提供

されないことを意味する。 

11.4.1.1 偶数INSコードのP1-P2の符号化 

表85−データオブジェクトを扱うための偶数INSコードのP1-P2 

P1-P2の値 

意味 

“0000” 

ファイルを一括読出しするために使用する(12.4参照)。 
カードからカード創生の問合せ文を読み出す,又はカードへ返事を送る(12.5参照)。 

“0001”〜“00FE” P2のBER-TLVタグ(1バイト) 

“00FF” 

特殊機能(表89,表91,表92及び表93参照) 

“0100”〜“01FF” 個別利用 

“0200” 

RFU 

“0201”〜“02FE” P2の簡易符号化TLVタグ 

“02FF” 

特殊機能(この表の次の記載文を参照) 

“1F1F”〜“FFFF” P1-P2のBER-TLVタグ(2バイト) 

− “0001”〜“00FE”及び“1F1F”〜“FFFF”の範囲の無効BER-TLVタグは,RFUとする。 
− 他の値は,RFUとする。 

P1を“00”に設定する場合,“01”〜“FE”のP2は,1バイトのBER-TLVタグでなければならない。 

P1を“01”に設定する場合,“00”〜“FF”のP2は,カード内部試験,及び与えられたアプリケーショ

ン内で意味をもつ個別利用サービスのための識別子でなければならない。 

P1を“02”に設定する場合,“01”〜“FE”のP2は,簡易符号化TLVタグでなければならない。値“0200”

は,RFUである。値“02FF”は,コンテキストにおいて読出し可能な共通簡易符号化TLVデータオブジ

ェクトを全て得るため,又はコマンドデータフィールドが簡易符号化TLVで符号化されることを示すため

のいずれかに使用する。 

P1-P2が“1F1F”〜“FFFF”の場合,2バイトで有効なBER-TLVタグを符号化するだけでなければなら

ない。 

95 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

注記 “1F1F”〜“FFFF”の多くの値は,有効なBER-TLVタグではない(附属書E参照)。 

11.4.1.2 奇数INSコードのP1-P2の符号化 

INSのビットb1に1を設定する場合,SELECT DATAコマンドを除いて,“0000”及び“FFFF”以外の

P1-P2は,ファイルを識別しなければならない。 

− P1-P2の最初の11ビットが0に設定され,P2のビットb5〜b1が全て等しくなく,カード及び/又は

ファイルが短縮EF識別子による選択を提供する場合,P2のビットb5〜b1は,短縮EF識別子(1〜

30の数)を符号化する。その他の場合は,P1-P2は,ファイル識別子とする。 

− “3FFF”に設定されたP1-P2は,カレントDFを識別する。 

“0000”に設定されたP1-P2は,ファイル識別のためにコマンドデータフィールドでファイル参照DO

“51”を提供しない限り,カレントEFを識別する。 

“FFFF”に設定されたP1-P2は,コマンドデータフィールドが別のテンプレートの参照情報を提供しな

い限り,カレントテンプレートを識別する(表86の引き数1,引き数2及び引き数3を参照)。 

11.4.1.3 データフィールド 

INSのビットb1が0に設定され,DOがカレントテンプレート内で要求又は提供される場合,ペイロー

ドは,データオブジェクト(すなわち,簡易符号化TLVデータオブジェクト若しくは基本BER-TLVデー

タオブジェクトの参照されたデータ要素,又は構造化DOの参照されたテンプレートのいずれか)の値フ

ィールドを含まなければならない。 

INSコードのビットb1の値(奇数偶数)によらず,DOの集合が提供される場合又はEFの内容が要求

される場合には,適切なデータフィールドは,DO群を含まなければならない。 

11.4.1.4 カレントテンプレートの拡張へのアクセス 

テンプレートがタグ付ラッパによって拡張されるとき(8.4.9参照),この拡張は,GET DATA及びGET 

NEXT DATAコマンドだけに有効とする。タグだけでDOを扱う他の全てのコマンドは,基礎テンプレー

トに制限される。タグ付ラッパの自動解決(8.4.9参照)は,カレントテンプレートを変更してはならない。 

テンプレートが一つ又は数個のラッパを含んでいる場合,8.4.9は,テンプレートに関連していると予想

されたDOを回復する方法を記載する。 

11.4.1.5 実行又は拒絶条件 

アクセスするDOを選択するパラメタがカード内の実際の構造に一致していない場合,このグループの

コマンドは,中止しなければならない。例えば, 

− データオブジェクトを提供しない構造(DF又はEF)に適用される場合。 

− パラメタが実際のデータオブジェクト構造に一致しない場合。 

セキュリティステータスがその機能に対するコンテキスト内のアプリケーションによって定義されたセ

キュリティ条件を満足する場合に限り,この機能を実行できる。 

11.4.2 SELECT DATAコマンド 

11.4.2.1 共通事項 

DOのLCSを変更せず,SELECT DATAは,常に許されている。 

このコマンドの機能を,次に示す。 

− 一意に選択された(すなわち,コマンドで標的とした)DOをカレントDOとして設定する。 

− 選択したDOが構造化DOの場合,DOの値フィールドを,カレントテンプレートとして設定する。 

− 比較される参照データを設定する。例えば,後続するCOMPAREコマンド(11.6.1参照)による比較

データ。 

background image

96 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− 選択したDOがカレントテンプレートのカレントVAに属さない場合,VAを変更する(7.2.1参照)。

コマンドが, 

− アプリケーション識別子DO“4F”あり及びファイル参照DO“51”なしを伝送する場合には,アプ

リケーションDFを選択する[7.2.2の規則d)参照]。 

− DO“4F”なし及びDO“51”ありを伝送する場合には,ファイルを選択する[7.2.2の規則e)又は

f)参照]。 

− DO“4F”あり及びDO“51”ありを伝送する場合には,アプリケーションDF[7.2.2の規則d)参照]

及びファイル[7.2.2の規則e)又はf)参照]を選択する。 

− レコード番号(表86の引き数3参照)を伝送する場合には,curRecordを更新する[7.2.2の規則g)

参照]。 

− オフセット(表86の引き数3参照)を伝送する場合には,curDataStringを更新する[7.2.2の規則

h)参照]。 

表86−一般参照DO“60”の値(一般参照テンプレート) 

引き数 

入れ子にされたDO 

注釈 

アプリケーション識別子DO“4F” 

任意選択 

ファイル参照DO“51”(表7参照) 

任意選択,偶数バイト。パスが,カレントアプリケーション又
はDO“4F”で参照するアプリケーションのファイル構造に合
致している場合,有効とする。 

どれか
を選択 

長さDO“02”が後続するレコ
ード番号DO“02”a) 

任意選択。値フィールドがEF内のレコードである,レコード
又は仮想DO“7F70”を参照する。 

長さDO“02”が後続するオフ
セットDO“54” 

任意選択。値フィールドが透過構造EF内のデータ列である,
データ列又は仮想DO“7F70”を参照する。 

どれか
を選択 

タグリストDO“5C” 

カレントテンプレートに存在する一
つのタグを入れ子にする。 

DO参照箇所で必須。カ
レントテンプレート又
は前の引き数で設定さ
れた一時的カレントテ
ンプレートに適用する。 

拡張ヘッダリストDO“4D”
又は“5F61”(選択の論理的根
拠については,8.4.5参照) 

拡張ヘッダの値フィールドは,カレ
ントテンプレートに存在するタグか
ら始まる。 

マスクタグDO“5F8400” 

部分タグによってDOを参照する。 

フィルタDO“7F71” 

構造化DOをその内容によって参照
する。 

任意の順,任意の数のマスクタグDO
“5F8400”,及び/又はフィルタDO
“7F71”。 
DOの集合にマスクDO又はフィルタ
DOを適用した結果は,部分集合となる。 
全てのマスクDO及び全てのフィルタ
DOを適用した結果は,それら部分集合
の全ての交差となる。 

DO“5F8400”は,部分タグによって
DOを参照する。 
DO“7F71”は,その内容によって構
造化DOを参照する。 

任意選択,引き数4で参
照されるDOが構造化
されている場合。 

注a) タグ“02”は,ISO/IEC 8824-1で整数と規定している。 

background image

97 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表87−SELECT DATAコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“A5” 

P1 

<“F0” 

インスタンスの順序番号 

“F0” 

curConstructedDOによって参照されたDOの親を選択。 

>“F0” 

RFU 

P2 

表88参照 

Lcフィールド 

Nc=0のとき存在せず,Nc>0のとき存在する。 

データフィールド  P1=“F0”の場合,空かもしれない。他の場合,少なくとも,一般参照DO“60”の引き

数4(表86参照)。他の引き数は,任意選択とする。全ての引き数は,一般参照テンプレ
ートと同じ順になっていなければならない。 

Leフィールド 

Ne=0のとき存在せず,レスポンスデータがP2(表88参照)によって要求される場合,
Ne>0で存在する。 

データフィールド  存在しない,又はP2による情報。 

SW1-SW2 

例えば,“6202”〜“6280”,“6281”,“6700”,“6981”,“6982”,“6985”,“6A81”,“6A88”
(DOが存在しない。すなわち,参照データが見つからない。)と関連するとき,表5及
び表6を参照 

表88−SELECT DATAコマンドのP2の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − 

カレントテンプレート中のファイル又はDOオカレンス 

− − − 

− 先頭又はP1のオカレンスを割愛した後のDOのオカレンス 

− − − 

− P1のオカレンスを割愛した後のDOの最後のオカレンス 

− − − 

− P1のオカレンスを割愛した後のDOの次のオカレンス 

− − − 

− P1のオカレンスを割愛した後のDOの前のオカレンス 

− − レスポンスデータフィールド必要条件(7.4.2及び表8参照) 

− − データ制御情報(DO“62”)の返信 

− − カレントテンプレートのタグリスト(DO“5C”)を返信(dir機能) 

− − カレントテンプレートのタグリスト(DO“5C”)を返信(view機能) 

− − カレントテンプレートのタグリスト(DO“5C”)(view機能)が続く,カレ

ントテンプレートのタグリスト(DO“5C”)を返信(dir機能) 

− 他の値は,RFU。 

P1を“F0”に設定する場合以外は,このコマンドの処理は,一時的カレントテンプレート内の一致に対

する検索を必要とする。最後の一致に対する検索は, 

− 最後のタグが基本DO,又は任意選択の“先頭”若しくは“最後”の構造化DOのいずれかを参照す

るとき,引き数によって定義される最後の一時的カレント構造化DO(最も高い世代)内で行われる。

一致するものが見つかった場合,選択されたDOは最後の一時的構造化DOの子供である。 

− 最後のタグが任意選択の“次”又は“前”の構造化DOを参照するとき,最後の一時的カレントDO

(最も高い世代から一つ低い世代)の親DO内で行われる。一致するものが見つかった場合,選択さ

れたDOは,最後の一時的構造化DOの兄弟である。 

次の例において,“一時的カレントテンプレート”は,最後の一致が行われる一時的カレント構造化DO

の値フィールドを示す。 

P1-P2=“0000”は,一時的カレントテンプレート内のDOの最初のオカレンスを選択する。 

P1-P2=“0100”は,一時的カレントテンプレート内のDOの第2のオカレンスを選択する。 

98 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

P1-P2=“0101”は,一時的カレントテンプレート内のDOの最後から2番目のオカレンスを選択する。 

P1-P2=“0001”は,一時的カレントテンプレート内のDOの最後のオカレンスを選択する。 

P1-P2=“0102”は,一時的カレントテンプレート内の基本DOの第2の次のオカレンス又はカレント構造

化DOの第2の次の兄弟のいずれかを選択する。 

失敗したSELECT DATA C-RP(SW1>“62”,表6参照)は,カレントVAを更新しない。 

11.4.2.2 基本的な対象定義 

基本的な対象定義は,引き数1,2,及び4を使用する。対象,すなわち,選択されるDOが, 

− カレントアプリケーションに含まれない場合,データフィールドは,アプリケーション識別子DO“4F”

を含まなければならない。 

− 一時的アプリケーション選択後のカレントファイルに含まれない場合,データフィールドは,アプリ

ケーション内にファイル参照が適用されるとき,ファイル参照DO“51”を含まなければならない。 

対象のタグは,次のいずれかでなければならない。 

− タグリストDO“5C”にカプセル化される。 

− 拡張ヘッダリストDO“4D”又は“5F61”(いずれを選択するか理由は8.4.5参照)によって定義され

る。 

− マスクタグDO“5F8400”によって定義される。 

− フィルタDO“7F71”を適用した構造化DOの内容によって定義される。 

条件付き引き数3は,その値フィールドがレコード型EF内のレコード又は透明構造EF内のデータ列の

いずれかの仮想DO“7F70”を参照する。一時的カレントDO“7F70”は,必須引き数が構造化DOを参照

しない場合,カレント構造化DOにならなければならない。 

11.4.2.3 マスクタグDO及びフィルタDOによる参照 

コマンドがカレントテンプレートを設定して条件付き引き数5で構造化DOを参照する場合,マスクタ

グDO“5F8400”又はフィルタDO“7F71”は,存在してもよい。 

マスクタグDO“5F8400”が存在している場合,コマンドは,マスクタグに一致しているテンプレート

の全てのタグの連結を入れ子にしているタグリストDO“5C”を返すことが望ましい。マスクタグは,同

じ長さの二つのデータ要素を入れ子にする。すなわち,<マスク値>に<対象タグ>が続く。タグ<マッ

チングタグ>の一致は,次のとき発生する。 

<マスク値>及び<マッチングタグ>=<マスク値>及び<対象タグ> 

フィルタDO“7F71”が存在している場合,フィルタDO“7F71”の値が次のどちらかの場合に限って,

コマンドは成功しなければならない。 

− 一時的カレントテンプレートに属する構造化DO。このDOは,カレントとなる。 

− 一時的カレントテンプレートに属する構造化DOのサブツリー(8.2.3参照)。このDOは,カレント

となる。 

11.4.2.4 GET DATA CONTROL PARAMETERS機能 

P2のビットb3を1に設定した要求のとき,レスポンスペイロードは,データLCSの更新後の(一時的

又は最後の)カレントDOに関連したDO“62”(表10参照)とする。DO“62”が有効でない場合,CP DO

は,タグ割付け機関(8.3.4参照)のために予約されていたタグ配下で存在してもよい。 

11.4.2.5 DIR機能 

P2のビットb4を1に設定した要求のとき,コマンドは,コマンドによって設定されたカレントテンプ

レート(テンプレート拡張を含む。)の全てのタグの連結を入れ子にしているタグリストDO“5C”を返す

background image

99 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

ことが望ましい。 

実際のタグリストDOは,テンプレートに存在していてもよいし,又は実装でダイナミックに発生して

もよい。いずれの場合も, 

− タグは,対応するDOのセキュリティ属性又はデータLCSのいかんにかかわらず存在しなければなら

ない。 

− 同じDOの複数のインスタンスが存在している場合,タグは,繰り返されなければならない。 

− 存在する場合,ラッパDOは,常に現れなければならない。 

実装が間接参照を解決する場合,ラッパ中に定義されたDOの局所タグは,(拡張テンプレートを示す)

タグリスト中に現れてもよい。そうでない場合,タグリストは,現れてはならない(そのタグリストは,

基礎テンプレートを示す。)。 

11.4.2.6 VIEW機能 

P2のビットb5を1に設定した要求のとき,コマンドは,DIR機能と同じタグの連結を入れ子にしてい

るタグリストDO“5C”を返すことが望ましい。しかし,必要に応じて,アプリケーションが,例えば,

次のようなタグを除いてもよい。 

− カレントのセキュリティ状態の下では読取り可能でないDO。 

− 活性化状態でないDO。 

− タグ付ラッパの自動解決が許されているときのタグ付ラッパ(8.4.8及び8.4.9参照)。 

11.4.2.7 ファイル関連機能 

コマンドデータフィールドに,引き数4が存在せず引き数3が存在しているとき,SELECT DATAコマ

ンドは, 

− 引き数3がレコード番号を含んでいる場合,curRecordを設定しなければならない。 

− 引き数3がオフセットDOを含んでいる場合,curDataStringとして引き数3によって参照するデータ

列を設定しなければならない。 

コマンドデータフィールドに,引き数3及び引き数4が存在しないとき,引き数1及び引き数2は,ア

プリケーション,カレントアプリケーションのファイル,又は指定されたアプリケーション内のファイル

の選択を提供する。 

11.4.3 GET DATA又はGET NEXT DATAコマンド(偶数INSコード) 

表89−GET DATA又はGET NEXT DATAコマンドレスポンス対(偶数INSコード) 

CLA 

5.4.1で定義する。 

INS 

“CA” 

GET DATA 

“CC” 

GET NEXT DATA 

P1-P2 

表85参照。特別の値“00FF”が使用される場合,コマンドは,カレントテンプレートか
ら全てのDOを得る。 

Lcフィールド 

Nc=0のため存在しない。 

データフィールド  存在しない。 

Leフィールド 

Ne>0のため存在する。 

データフィールド  P1-P2に従った0,1又はそれ以上のデータバイト。 

SW1-SW2 

例えば,“6202”〜“6280”,“6281”,“6700”,“6981”,“6982”,“6985”,“6A81”,“6A88”
(データオブジェクトが見つからない,すなわち,参照データが見つからない。)と関連
するとき,表5及び表6を参照 

100 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

11.4.3.1 共通事項 

偶数INSコード(表89参照)のコマンドの主な機能は,カレントテンプレートに属するDOの値フィ

ールドの読出しとする。それは,DOを提供するEFの内容であってもよい。 

カレントテンプレートに(同じ)タグが複数ある場合,ここでは,それがDOの定義,本質,又は内容

によるので,GET DATAによってどのDOが返されるか定義しない。GET NEXT DATAには,明確な動作

がある(11.4.3.4参照)。 

セキュリティステータスがそのセキュリティ属性と一致しないとき,要求されたDO又はデータ要素は,

レスポンス中に存在してはならない。 

11.4.3.2 SELECT機能 

構造化DOに対するGET DATAコマンドの実行後,このDOは,カレント構造化DOになる。 

GET NEXT DATAコマンドは,カレントDO及びカレントテンプレートに影響を与えてはならない。 

11.4.3.3 GET DATA CONTROL PARAMETERS機能 

偶数INSのGET DATA又はGET NEXT DATAコマンドの引き数がタグ“62”のCPテンプレートのとき,

レスポンスペイロードは,同じテンプレートのDOに添えられたCP DO(表10参照)の連結とする。DO

“62”が利用可能でない場合,CP DOがタグ割付け機関のために予約されたタグ配下に存在していてもよ

い(8.4.4参照)。 

11.4.3.4 GET NEXT DATA及びポインタの扱いの特定の機能 

同じタグがテンプレート中に複数存在するとき,連続したGET NEXT DATAコマンドは,それらの値を

連続して返さなければならない。値が回復される順序は,それらのタグがDIR機能又はVIEW機能(11.4.2.5

又は11.4.2.6参照)で回復される順序と同じでなければならない。 

GET DATAコマンドとは逆に,実行したGET NEXT DATAコマンドは,VAに影響を与えてはならない。

複数のインスタンスの扱いは,次のことを意味する。 

− テンプレートは,カードと接続装置とのインタフェース上でDOの順序付きリストと見なされる。用

語“順序付きリスト”は,このリストが先頭及び最後の要素をもっていることを意味する。各リスト

要素には,最後のもの以外は次の要素がある。各リスト要素には,先頭以外は,前の要素がある。 

− ポインタは論理チャネルに付けられている。このとき,このポインタの値は,未設定とする。ポイン

タは,GET NEXT DATA,PUT DATA,PUT NEXT DATA又はUPDATE DATAコマンド(11.4.6,11.4.7

及び11.4.8参照)によって設定される。GET NEXT DATA又はPUT NEXT DATAコマンドと異なるコ

マンドを,同じ論理チャネル上で送信する場合,このポインタは,未設定にしなければならない。あ

る論理チャネルでのコマンドの送信は,別の論理チャネル上のポインタに影響を与えないほうがよい。 

DOの連続が循環の管理を提供するとき,GET DATA又はGET NEXT DATAコマンドは,最初に最新の

インスタンスを回復しなければならない。次のGET NEXT DATAコマンドは,残っているものの中で最新

のインスタンスを回復しなければならない。以降は同様である。 

全てのデータ要素又はDOを,連続したGET NEXT DATAレスポンスでカードによって送ったとき,そ

の後のGET NEXT DATAコマンドは,SW1 SW2=“6A88”によって拒絶しなければならない。 

11.4.4 GET DATA又はGET NEXT DATAコマンド(奇数INSコード) 

11.4.4.1 共通事項 

奇数INSコード(表90参照)のコマンドの主な機能は,コマンドの引き数による一つ以上のDOの値

フィールドの読出しとする。対象選択は,次を除いてSELECT DATA選択に非常に似ている。 

− SELECT DATAは一つのDOを選択するが,このコマンドは,数個のDOを返してもよい。 

background image

101 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− SELECT DATAコマンドの引き数2を,一つのファイル識別子を含むファイル参照DOと機能面で等

価なP1-P2のファイル識別子に取り替えてもよい。この任意選択機能を使用しているとき,コマンド

データフィールドは,引き数1(DO“4F”)を機能させてはならない。 

GET DATA又はGET NEXT DATAコマンドが一つ(又は複数)の構造化DOを要求する場合,その中に

入れ子にされた全てのDOは,次の場合を除き,レスポンス中に存在しなければならない。 

1) 要求されたタグを備えたDOが,テンプレートにおいて利用可能ではない。 

2) セキュリティステータスが,セキュリティ属性と一致しない。 

3) コマンドの引き数が拡張ヘッダリストであるときに,明示的に要求しない場合。 

一つ以上の要求されたDOがこれらの理由の一つで利用不可能な場合,GET DATA又はGET NEXT DATA

コマンドは拒絶しなくてもよい。全てのDOが利用可能でない場合だけ,拒絶しなければならない。 

カレントテンプレートに(同じ)タグが複数ある場合,GET DATAによってどのDOが返されるかはDO

の定義,本質又は内容によるので,ここでは定義しない。GET NEXT DATAには,明確な動作がある(11.4.3.4

参照)。 

表90−GET DATA又はGET NEXT DATAコマンドレスポンス対(奇数INSコード) 

CLA 

5.4.1で定義する。 

INS 

“CB” 

GET DATA 

“CD” 

GET NEXT DATA 

P1-P2 

“0000” 

データフィールドがファイルを参照している場合を除いて,カレントファ
イル。 

“FFFF” 

データフィールドによって設定されたカレントテンプレート又は一時的
カレントテンプレート 

他の値 

ファイル識別子,又は短縮EF識別子(11.4.1.2参照)。 
データフィールドは,アプリケーション識別子DO“4F”及びファイル参
照DO“51”のどちらも含まない。 

Lcフィールド 

Nc>0のため存在する。 

データフィールド  複数のDOを参照してもよいことを除いて,SELECT DATAのデータフィールドと同じ(表

86,表87参照)。 

Leフィールド 

Ne>0のため存在する。 

データフィールド  0,1又はそれ以上のデータバイト 

SW1-SW2 

例えば,“6202”〜“6280”,“6281”,“6700”,“6981”,“6982”,“6985”,“6A81”,“6A88”
(データオブジェクトが見つからない。すなわち,参照データが見つからない。)と関連
するとき,表5及び表6を参照 

11.4.4.2 必須の引き数 

コマンドデータフィールドは,タグリストDO“5C”(8.4.3参照),拡張ヘッダリストDO“4D”若しく

はDO“5F61”(8.4.5参照),マスクDO“5F8400”,又はフィルタDO“7F71”(11.4.2.3参照)のいずれか

で終了しなければならない。 

− タグリストのケースでは,レスポンスデータフィールドは,タグリストで参照した順序のDOに連結

しなければならない。順序は,テンプレート内のDOの順序と異なっていてもよい。テンプレート内

に数個の同じタグのDOが存在するとき,それら全てのDOを返さなければならない。セキュリティ

ステータスの理由によって,一つ以上のDOが欠如してもよい。空のタグリストは,全ての利用可能

なDOを要求する。 

102 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− 拡張ヘッダリストのケースでは,レスポンスデータフィールドは,8.4.6及び8.4.7によって拡張ヘッ

ダリストから得たDOに連結しなければならない。 

− マスクDO又はフィルタDOのケースでは,レスポンスデータフィールドは,一致したDOに連結し

なければならない。 

11.4.4.3 SELECT機能 

“FFFF”に等しくないP1-P2のGET DATAコマンドがファイルを参照する場合,その副次効果は,この

ファイルをカレントとし,また,ルートDO“7F70”の値フィールドをカレントテンプレートとして設定

しなければならない。 

この規格の対応国際規格の第2版(JIS X 6320-4:2009)に定義されていないシンタックスのGET DATA

コマンドは,VAに影響してはならない。すなわち,次のときである。 

− P1-P2を“FFFF”に設定 

− 引き数1及び/又は引き数3が存在 

− DO“4D”又はDO“5C”と異なる引き数4 

11.4.4.4 DIR機能及びVIEW機能 

引き数が次のときに,DIR機能及びVIEW機能を奇数INS GET DATA又はGET NEXT DATAコマンドに

よって提供する。 

− “5C 01 5C”(タグリストDOに入れ子にされたタグ“5C”)。レスポンスペイロードは,11.4.2.5又は

11.4.2.6で定義されたレスポンスペイロードを入れ子にするタグリストDO“5C”であることが望まし

い。 

− “5C 01 5D”(タグリストDOに入れ子にされたタグ“5D”)。レスポンスペイロードは,11.4.2.5又は

11.4.2.6で定義されたレスポンスペイロードを入れ子にするヘッダリストDO“5D”であることが望ま

しい。 

DIR機能及びVIEW機能の選択は,この規格の適用範囲外とする。 

11.4.4.5 GET DATA CONTROL PARAMETERS機能 

奇数INSのGET DATAコマンドの引き数が“5C 01 62”[タグリストDOに入れ子にされたタグ“62”(CP

テンプレートタグ)]のとき,レスポンスペイロードは,DO“62”であることが望ましい。 

11.4.4.6 GET NEXT DATA(INS=“CD”)の特定の機能 

GET DATAコマンド(INS=“CB”)に対するGET NEXT DATAコマンド(INS=“CD”)の特質は,偶数

INSコードのC-RPがデータ要素(DOの値)を返し,奇数INSコードのC-RPがDOを返すことを除いて,

GET DATAコマンド(INS=“CA”,11.4.3.4参照)に対するGET NEXT DATAコマンド(INS=“CC”)の

特質と同じである。 

11.4.5 PUT,PUT NEXT及びUPDATE DATAコマンドの一般特性 

これらのコマンドは,一つ以上のDO群(場合によっては構造化DO)を伝送することによって,カレ

ントテンプレートの内容の変更を開始する。INSのビットb1を次のとおり設定したPUT,PUT NEXT及

びUPDATE DATAは, 

− 0に設定したとき,カレントテンプレートだけで処理しなければならない。 

− 1に設定したとき,DO群を実際に扱う前に,仮想根幹DO“7F70”の値フィールドとして一時的テン

プレート(“FFFF”に等しくないP1-P2によって選択された)を設定する。コマンドが正常終了する

場合,一時的カレントテンプレートは,カレントテンプレートにならなければならない。 

ポインタがGET NEXT DATA又はPUT NEXT DATA C-RP(11.4.3.4を参照)によって設定される場合,

background image

103 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

UPDATE DATA又はPUT DATA C-RPによって,どのインスタンスが影響を受けなければならないかを定

義する。 

ポインタが未設定の場合(11.4.3.4参照),curDO(7.2.1参照)は,UPDATE DATA又はPUT DATA C-RP

によってどのDOが影響を受けるか定義する。 

PUT DATA及びUPDATE DATAコマンドは,コマンドデータフィールドに複数のDOを含んでいてもよ

いが,PUT NEXT DATAコマンドは,コマンドデータフィールドにただ一つのDOとしなければならない。 

11.4.6 PUT DATAコマンド 

表91に,PUT DATA C-RPを示す。PUT DATAコマンドは,UPDATE DATAコマンドで定義した動作及

び符号化をもっていてもよい(PUT NEXT DATAコマンドについても同様にもっていてもよい。)。この規

格の対応国際規格の第2版(JIS X 6320-4:2009)と矛盾なく,DOの定義,本質又は内容は,テンプレート

の内容に影響を及ぼさなければならない。INSが,“DB”を設定しP1-P2を“FFFF”に設定する場合,次

の規則を適用する。 

− PUT NEXT DATAコマンドを提供する場合,タグがテンプレートに既に存在するDOのPUT DATAコ

マンドは,既存のDOを新しいものに置換しなければならない。 

− UPDATE DATAコマンドを提供する場合,PUT DATAコマンドは,伝送されたDO全体をテンプレー

トに追加しなければならない。これはテンプレート内にインスタンスの複製をもたらしてもよい。 

Lcフィールドが存在しないとき,偶数INSのPUT DATAコマンドは,P1-P2が示すとおり,空のDOを

追加するか又は空のDOで既存のDOを置換しなければならない。 

表91−PUT DATAコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“DA”又は“DB” 

P1-P2 

INS=“DA” 表85参照。特別の値“00FF”を使用する場合,コマンドデータフィール

ドは,カレントテンプレートに追加又は交換するDOの連結を含んでいる。 

INS=“DB” ファイル識別子,又は短縮EF識別子(11.4.1.2参照)。 

Lcフィールド 

Nc>0のとき存在する,又はNc=0のとき存在しない。 

データフィールド  INS=“DA” P1-P2に従ったデータバイト,又はDOの値を削除するときには存在しな

い。 

INS=“DB” DOの連結 

Leフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“63CX”(11.4.1参照),“6581”,“6700”,“6981”,“6982”,“6985”,“6A80”,
“6A81”,“6A84”,“6A85”と関連するとき,表5及び表6を参照 

11.4.7 PUT NEXT DATAコマンド 

表92に,PUT NEXT DATA C-RPを示す。 

コマンドは,カレントテンプレート内に一つのDOの追加を開始する。挿入されるDOと同じタグのDO

がテンプレートに既に存在している場合,テンプレート内にこの新しいDOのインスタンスを追加しなけ

ればならない。インスタンスの数が最大値に達していない場合,PUT NEXT DATAコマンドは,カレント

テンプレートに伝送されたDOを追加し,追加したDOにポインタを設定しなければならない。このコマ

ンドの結果は,データ記述子バイト(表13参照)によって与えられるDOの構造に依存する。 

− DOの構造が“情報なし”でインスタンスの数がその最大値に達した場合,PUT NEXT DATAコマン

background image

104 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

ドをSW1-SW2=“6A84”で拒絶しなければならない。そうでなければ,新しいDOをDOの順序付き

リストの任意の位置に挿入する。 

− DOの構造が“順編成管理”でインスタンスの数がその最大値に達した場合,PUT NEXT DATAコマ

ンドをSW1-SW2=“6A84”で拒絶しなければならない。そうでなければ,ポインタを, 

− 設定していない場合,新しいDOをリストの最後の要素の後に追加しなければならない。 

− 設定している場合,指示しているDOがリストの前の要素になるように,新しいDOを挿入しなけ

ればならない。 

− DOの構造が“周期的管理”で,ポインタを, 

− 設定していない場合,新しいDOは,リストの最初の要素にならなければならない。 

− 設定している場合,指示しているDOがリストの次の要素になるように,新しいDOを挿入しなけ

ればならない。 

さらに,構造が“周期的管理”タイプで,順序付きリストに新しいDOを挿入した後にインスタンスの

数が最大値よりも大きい場合,挿入されたDOと同じタグで順序付きリストの最後に最も近いDOは,削

除されなければならない。 

注記1 新しいDOを挿入するための規則は,順編成管理及び周期的管理で,新しいDOを順序付き

リスト中の任意の位置に挿入することができる。 

注記2 ポインタが設定されていない場合,周期的管理は,循環順編成構造のEFに対するAPPEND 

RECORDコマンドと同様に振る舞う。 

注記3 構造が周期的管理で,ポインタが最後の要素を指しインスタンスの数がその最大値に達した

場合,規則は,新しいDOの挿入が順序付きリストに影響しないことを意味する。 

注記4 インスタンスが明示的に番号付けられる場合,インスタンス番号(表10参照)の扱いは,動

的でなければならない。 

注記5 この規格は,インスタンスの最大数がカードのインタフェース上でどのように見えるかにつ

いては定義しない。 

複数のDOを送信する場合,コマンドは,カレントテンプレート内を変更せずに,異常終了(SW1-SW2

=“6A80”)しなければならない。 

表92−PUT NEXT DATAコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“D8”又は“D9” 

P1-P2 

INS=“D8” 表85参照。特別の値“00FF”を使用する場合,コマンドデータフィール

ドは,カレントテンプレートに追加されるDOを含んでいる。 

INS=“D9” ファイル識別子,又は短縮EF識別子(11.4.1.2参照) 

Lcフィールド 

Nc>0のため存在する。 

データフィールド  INS=“D8” P1-P2に従ったデータバイト 

INS=“D9” 一つのDO 

Leフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“63CX”(11.4.1参照),“6581”,“6700”,“6981”,“6982”,“6985”,“6A80”,
“6A81”,“6A84”,“6A85”と関連するとき,表5及び表6を参照 

background image

105 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

11.4.8 UPDATE DATAコマンド 

表93に,UPDATE DATA C-RPを示す。 

表93−UPDATE DATAコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“DE”又は“DF” 

P1-P2 

INS=“DE” 表85参照。特別の値“00FF”を使用する場合,コマンドデータフィール

ドは,カレントテンプレート内で処理されるDOの連結を含んでいる。 

INS=“DF” ファイル識別子,又は短縮EF識別子(11.4.1.2参照) 

Lcフィールド 

Nc>0のため存在する。Nc=0のため存在しない(この表の次の記載を参照)。 

データフィールド  INS=“DE” P1-P2に従ったデータバイト, 

又は,DOの値を削除するときには存在しない。 

INS=“DF” 一つのDO(構造化の可能性がある。) 

Leフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“63CX”(11.4.1参照),“6581”,“6700”,“6981”,“6982”,“6985”,“6A80”,
“6A81”,“6A84”,“6A85”と関連するとき,表5及び表6を参照 

データフィールドで示された各DOに対して,コマンドは,次のa)〜c)のいずれかを実行しなければな

らない。 

a) カレントテンプレート内のDOの変更。DOの複数のインスタンスが存在する場合は,次のとおりと

する。 

1) 存在するインスタンスの一つがカレントDOの場合,それを更新しなければならない。 

2) カレントDOがインスタンスの一つでない場合,この規格は,DOのどのインスタンスを更新する

か定義しない。 

b) 複数のインスタンスが存在する場合,上記と同じ条件でカレントテンプレート内のDOの値フィール

ドを削除する。空のDOで空でないDOを更新することは,既存のDOを空のDOに置換する。 

c) 同じタグのDOが存在していない場合,カレントテンプレート内にDOを創生する。 

基本DOの更新は,既存DOを送信したDOに置換する。 

構造化DOを更新するために(F.3参照),送信したDO内に存在する全てのテンプレートを,最小の世

代番号から始めて,連続的に処理しなければならない。テンプレート内の既存DOは変更しなければなら

ないし,テンプレート内に存在しないDOは,テンプレート内に創生しなければならない。変更される一

つ以上のDOが構造化DOの場合,手続きは,次世代などで繰り返されなければならない。 

注記 これによって,構造化DO全体を再送する必要なしに構造化DO内のDOを更新する。 

11.4.9 COMPARE DATA機能 

この機能は,COMPAREコマンドで提供する(11.6.1参照)。 

11.5 基本セキュリティの扱い 

11.5.1 共通事項 

この箇条で規定するコマンドで提供するセキュリティ関連の手続きは,それらのコマンドの定められた

順序及びJIS X 6320-8で規定しているコマンドを含んでいる。セキュリティ属性拡張(9.3.6.2を参照)の

使用は,インタフェース上でそのような順序の記載を提供する。 

このグループに属するコマンドは,アルゴリズム及び幾つかの関連する参照データ(例えば,鍵)を参

background image

106 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

照するためにP1-P2を予約する。カレント鍵及びカレントアルゴリズムがある場合,コマンドは,暗黙的

にそれらを使用してもよい。 

P1 別段の定めがない限り,P1は,暗号アルゴリズム又は生体情報のアルゴリズム(JIS X 6320-11参照)

のいずれかを使用するアルゴリズムとして参照する。P1に“00”を設定することは,情報が与えられない

ことを意味する。すなわち,その参照がコマンドを発行する前に知られているか,又はコマンドデータフ

ィールドがアルゴリズムを提供するかのいずれかとする。 

P2 別段の定めがない限り,P2は,表94に従い参照データへ指定条件を与える。P2に“00”を設定する

ことは,情報が与えられないことを意味する。すなわち,その指定条件がコマンドを発行する前に知られ

ているか,又はコマンドデータフィールドがそれを提供するかのいずれかとする。その指定条件が,例え

ば,パスワード番号,鍵番号,又は短縮EF識別子であってもよい。 

表94−P2の参照データ指定条件の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

情報なし。 

− − − − − − − カード全体の参照データ(例えば,MF固有パスワード又は鍵) 

− − − − − − − 固有の参照データ(例えば,DF固有パスワード又は鍵) 

− 

− − − − − 00(他の値は,RFU) 

− − − 

指定条件,すなわち,参照データの番号又は秘密データの番号 

注記 MANAGE SECURITY ENVIRONMENTコマンドは,アルゴリズム参照及び/又は多重バイトの

参照データ指定条件を設定してもよい(表51参照)。 

このグループに属するコマンドにおいて,“6300”又は“63CX”に設定されたSW1-SW2は,検証が失

敗したことを示し,“X”≧“0”の場合の“X”は,許容再試行回数を示す。“6A88”に設定されたSW1-SW2

は,“参照データが見つからない。”を意味する。 

11.5.2 INTERNAL AUTHENTICATEコマンド 

表95に,INTERNAL AUTHENTICATE C-RPを示す。 

INTERNAL AUTHENTICATEコマンドは,接続装置によって送られたチャレンジデータ及びカードに格

納された関連する秘密データ(例えば,鍵)を使用して,カードによって認証データの計算を開始する。 

− 秘密データがMFに関連する場合,コマンドは,カード全体を認証するために使用してもよい。 

− 秘密データがDFに関連する場合,コマンドは,そのDFを認証するために使用してもよい。 

認証の成功は,先行するコマンド(例えば,VERIFY,SELECT)又は選択(例えば,関連する秘密デー

タ)の完了を前提としてもよい。 

カードは,関連する秘密データ又はアルゴリズムの使用を制限するために,コマンドが発行された回数

を記録してもよい。 

注記 レスポンスデータフィールドは,以降のセキュリティ機能に役立つデータ(例えば,乱数)を

含んでいてもよい。 

background image

107 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表95−INTERNAL AUTHENTICATEコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“88” 

P1-P2 

11.5.1及び表94参照 

Lcフィールド 

Nc>0のため存在する。 

データフィールド  認証関連データ(例えば,チャレンジデータ) 

Leフィールド 

Ne>0のため存在する。 

データフィールド  認証関連のデータ(例えば,チャレンジデータに対するレスポンス) 

SW1-SW2 

例えば,“6300”(11.5.1参照),“63CX”(11.5.1参照),“6581”,“6700”,“6982”,
“6983”,“6984”,“6A81”,“6A82”,“6A86”,“6A88”(11.5.1参照)と関連するとき,
表5及び表6を参照 

11.5.3 GET CHALLENGEコマンド 

表96にGET CHALLENGE C-RPを示す。 

GET CHALLENGEコマンドは,セキュリティに関連する手続き(例えば,EXTERNAL AUTHENTICATE

コマンド)で使用するチャレンジ(例えば,暗号認証のための乱数,又は声紋を使用した生体情報認証の

ために発声を促す文)を発行するのを要求する。そのチャレンジは,少なくともGET CHALLENGEコマ

ンドの次のコマンドに有効とする。ここでは,条件をこれ以上は規定しない。 

表96−GET CHALLENGEコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“84” 

P1 

11.5.1参照 

P2 

“00”(他の値は,RFU) 

Lcフィールド 

Nc=0のため存在しない。 

データフィールド  存在しない。 

Leフィールド 

Ne>0のため存在する。 

データフィールド  チャレンジデータ 

SW1-SW2 

例えば,“6700”,“6A86”(11.5.1参照)と関連するとき,表5及び表6を参照 

11.5.4 EXTERNAL AUTHENTICATEコマンド 

セキュリティステータスがこの処理のためのセキュリティ属性を満足する場合に限り,このコマンドの

機能は,実行できる。 

表97は,EXTERNAL AUTHENTICATE C-RP機能を示し,一方,表98は,MUTUAL AUTHENTICATE

機能のC-RPを示す。EXTERNAL AUTHENTICATEコマンドは,カードから先行して発行されたチャレン

ジ(例えば,GET CHALLENGEコマンドによる。)とカードに格納された(秘密の)鍵と接続装置から送

信された認証データとを使ったカードによる計算の結果(合否)に従って,セキュリティステータスを更

新する。 

認証の成功は,カードから得られた最後のチャレンジを使用することが必要である。カードは,認証失

敗を記録してもよい(例えば,参照データの以降の使用回数を制限するため。)。 

コマンドデータフィールドがないコマンドは,許容再試行の数“X”(“63CX”に設定されたSW1-SW2)

を読み出すためか,又は検証が要求されるか否か(“9000”に設定されたSW1-SW2)のいずれかを確認す

るために使用してもよい。 

background image

108 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

MUTUAL AUTHENTICATE機能 MUTUAL AUTHENTICATE機能は,EXTERNAL AUTHENTICATE及び

INTERNAL AUTHENTICATEコマンドと同様に使う。その機能は,先行のGET CHALLENGEコマンドと,

カードに格納した(秘密の)鍵とに基づいている。カード及び接続装置は,認証に関連するデータを共有

する。すなわち,共有するデータは,カードによって発行されたものと接続装置によって発行されたもの

との二つのチャレンジを含む。 

注記 このコマンドは,ISO/IEC 9798-2 [10] 及びISO/IEC 9798-3 [10] で規定する認証を実装するために

用いてもよい。 

表97−EXTERNAL AUTHENTICATEコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“82” 

P1-P2 

11.5.1及び表94参照 

Lcフィールド 

Nc=0のとき存在しない。Nc>0のとき存在する。 

データフィールド  存在しない,又は認証関連データ(例えば,チャレンジデータに対するレスポンス) 

Leフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“6300”(11.5.1参照),“63CX”(11.5.1参照),“6581”,“6700”,“6982”,“6983”,
“6984”,“6A81”,“6A82”,“6A86”,“6A88”(11.5.1参照)と関連するとき,表5及び
表6を参照 

表98−MUTUAL AUTHENTICATE機能に対するコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“82” 

P1-P2 

11.5.1及び表94参照 

Lcフィールド 

Nc>0のため存在する。 

データフィールド  認証関連データ 

Leフィールド 

Ne>0のため存在する。 

データフィールド  認証関連データ 

SW1-SW2 

例えば,“6300”(11.5.1参照),“63CX”(11.5.1参照),“6581”,“6700”,“6982”,
“6983”,“6984”,“6A81”,“6A82”,“6A86”,“6A88”(11.5.1参照)と関連するとき,
表5及び表6を参照 

11.5.5 GENERAL AUTHENTICATEコマンド 

表99に,GENERAL AUTHENTICATE C-RPを示す。 

GENERAL AUTHENTICATEコマンドは,EXTERNAL AUTHENTICATE,INTERNAL AUTHENTICATE

及びMUTUAL AUTHENTICATE機能を改良したものである。すなわち,カード外のエンティティは,カー

ド内のエンティティを認証(INTERNAL AUTHENTICATE機能)するか,カード内のエンティティは,カ

ード外のエンティティを認証(EXTERNAL AUTHENTICATE機能)するか,又は相互に認証(MUTUAL 

AUTHENTICATE機能)するかのいずれかとする。 

EXTERNAL AUTHENTICATE及びINTERNAL AUTHENTICATEコマンドは,チャレンジレスポンス対を

含む認証機構に適しているが,証拠情報(ウィットネス),チャレンジ及びレスポンスの3交信認証方式(ト

リプルズ)(ISO/IEC 9798-5 [10] 参照)を含む認証機構及び多段階認証プロトコルを実現できない。これら

の認証方式は,二つ以上のGENERAL AUTHENTICATE C-RPを要求する。このようなコマンドレスポンス

background image

109 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

対は連鎖していてもよい(5.3.3参照)。 

セキュリティステータスがこの処理のためのセキュリティ属性を満足する場合に限り,INTERNAL 

AUTHENTICATE,EXTERNAL AUTHENTICATE,又はMUTUAL AUTHENTICATEのいずれかの機能を実

行する。認証の成功は,先行するコマンド(例えば,VERIFY,SELECT)又は選択(例えば,関連する秘

密データ)の完了を前提としてもよい。カードによって実行された制御の結果(合否)は,条件付きでセ

キュリティステータスを更新してもよい。カードは,関連する秘密データ又はアルゴリズムの以降の使用

回数を制限するためにコマンドが発行された回数を記録してもよい。カードは,認証の失敗を記録しても

よい(例えば,参照データの以降の使用回数を制限するため。)。 

表99−GENERAL AUTHENTICATEコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“86”又は“87” 

P1-P2 

11.5.1及び表94参照 

Lcフィールド 

Nc>0のため存在する。 

データフィールド  認証関連データ 

Leフィールド 

Ne=0のとき存在しない。Ne>0のとき存在する。 

データフィールド  存在しない(例えば,EXTERNAL AUTHENTICATE機能の最終コマンドのため,又は処

理が中断されたためにLeフィールドが存在しない。),又は認証関連データ 

SW1-SW2 

例えば,“6300”(11.5.1参照),“63CX”(11.5.1参照),“6581”,“6700”,“6982”,
“6983”,“6984”,“6A81”,“6A82”,“6A86”,“6A88”(11.5.1参照)と関連するとき,
表5及び表6を参照 

表100−証拠情報(ウィットネス),チャレンジ及びレスポンスの3交信認証に対する動的認証DO 

タグ 

値 

“7C” 

次のタグがある動的認証DOの集合 

“80” 

証拠情報(ウィットネス)(例えば,公開鍵として使用するモジュラスよりも小さい一
つ以上の正の数) 

“81” 

チャレンジ(例えば,公開鍵として使用する,べき指数未満の一つ以上の0を含む数) 

“82” 

レスポンス(例えば,一つ以上の数で,公開鍵として使用するモジュラスよりも小さ
い1以上の正の数) 

“83” 

約束済み(コミティド)チャレンジ(例えば,一つ以上のチャレンジを含む大きな乱
数値のハッシュコード) 

“84” 

認証コード[例えば,一つ以上のデータフィールド及び証拠情報(ウィットネス)DO
のハッシュコード] 

“85” 

鍵共有技術用の暫時の公開鍵 

“86” 

暗号化データ 

“06” 

OID(この表の次の記載を参照) 

“A0” 

識別データテンプレート 

− タグ“7C”配下で,OIDが状況依存クラスを他の方法で指定しない場合,状況依存クラスの他の

DOは,ISO/IEC JTC 1/SC 17が予約する。 

各データフィールドは,存在する場合,タグ“7C”が参照した産業間共通利用テンプレートを含まなけ

ればならない。 

使用中の暗号プロトコルに関するGENERAL AUTHENTICATEコマンドの省略時の状況依存クラスのタ

グを,証拠情報(ウィットネス),チャレンジ及びレスポンスの3交信認証のために予約する(C.1参照)。

110 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

この場合,動的認証テンプレートにおいて,状況依存クラス(先頭バイトが“80”〜“BF”)を,表100に

示す動的認証DOのために予約する。 

この場合,各々の状況依存DOは,タグ“7C”のテンプレートに埋め込まれ,C-RPで送信しなければ

ならない(表100参照)。 

GENERAL AUTHENTICATEコマンドを多段階認証プロトコル(C.2参照)に使用する場合,各々のプロ

トコルOID又はOIDに関連したアルゴリズム参照は,認証用のCRT ATの中で先行したMANAGE 

SECURITY ENVIRONMENTコマンド(11.5.11参照)に含まれなければならない,及び/又は,C-RPで送

った追加的に埋め込んだコンテキスト特定のDOのプロトコルの解釈を示すタグ“7C”のテンプレート内

に含まれなければならない。 

省略時のコンテキストに対して,次の規則を動的認証用の産業間共通利用テンプレート内で適用する。 

− あるテンプレート内のDOが空の場合,その次のデータフィールドのそのテンプレートにおいて,そ

のDOは,完全なものでなければならない。 

− 先頭のコマンドデータフィールドで,テンプレートは次のとおり動的認証機能を示す。 

− 証拠情報(ウィットネス)要求[例えば,空の証拠情報(ウィットネス)]は,INTERNAL 

AUTHENTICATE機能を示す。 

− チャレンジ要求(例えば,空のチャレンジ)は,EXTERNAL AUTHENTICATE機能を示す。 

− 空のDOが存在しないことは,MUTUAL AUTHENTICATE機能を示す。したがって,カードが処理

を中断しない場合,レスポンスデータフィールドのテンプレートは,コマンドデータフィールドの

テンプレートと同じDOを含まなければならない。MUTUAL AUTHENTICATE機能は,二つのエン

ティティが,タグ“85”によって参照される一組の“指数関数的な”データ要素を使用して,セシ

ョン鍵を共有することを可能にする(ISO/IEC 11770-3 [17] の鍵共有技術を参照)。 

動的認証は,セションを通じて交換されたデータフィールドを保護してもよい。両方のエンティティが,

一つのコマンド又はレスポンスデータフィールドを含めることによって一度に更新される最新のハッシュ

コードを保持する。DO“84”は,証拠情報(ウィットネス)DO“80”を含めることによってカレントの

コードを更新することで認証コードを伝える。検証者は,連続的に証拠情報(ウィットネス)及び認証コ

ードを再構築する。再構築された証拠情報(ウィットネス)が0(ゼロ)でなく,かつ,二つのコードが

同一の場合,認証は成功する。 

省略時のコンテキストに対して,データフィールド認証及び鍵共有に対する拡張を含めて,INTERNAL 

AUTHENTICATE,EXTERNAL AUTHENTICATE及びMUTUAL AUTHENTICATE機能の実装のための

GENERAL AUTHENTICATE C-RPを,C.1に示す。 

11.5.6 VERIFYコマンド 

表101に,VERIFY C-RPを示す。 

background image

111 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表101−VERIFYコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“20”又は“21” 

P1 

“00” 

通常動作 

“FF” 

検証ステータスを“確認されなかった。”に設定する。この細分箇条の最
後の段落を参照。 

他の値 

RFU 

P2 

表94参照 

Lcフィールド 

Nc=0のとき存在しない。Nc>0のとき存在する。 

データフィールド  INS=“20” 

検証データ又は存在しない。 

INS=“21” 

検証データDO,及び条件付き拡張ヘッダリスト 

Leフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“6286”,“6300”(11.5.1参照),“63CX”(11.5.1参照),“6581”,“6700”,
“6982”,“6983”,“6984”,“6A81”,“6A82”,“6A86”,“6A88”(11.5.1参照)と関連す
るとき,表5及び表6を参照 

VERIFYコマンドは,接続装置から送られた検証データ(例えば,パスワード)又はカード上のセンサ

から送られた検証データ(例えば,指紋)と,格納されている参照データとの比較をカード内で開始する。

セキュリティステータスは比較の結果,変更してもよい。カードは,認証の失敗を記録してもよい(例え

ば,参照データの以降の使用回数を制限するため)。 

INS=“20”の場合,コマンドデータフィールドは,検証データを伝えるために通常存在する。コマンド

データフィールドが存在しないコマンドは,検証が必要か(“X”が,以降の許可された再試行回数を符号

化するところのSW1-SW2=“63CX”)又は必要ないか(SW1-SW2=“9000”)を確認するために使用する。 

INS=“21”の場合,コマンドデータフィールドは,通常空ではない検証DO(例えば,タグ“5F2E”,

JIS X 6320-11参照)を伝えなければならない。拡張ヘッダリスト(タグ“4D”,8.4.5参照)及び空の検証

DOの存在は,カード上のセンサから検証データがくることを示す。拡張ヘッダリストは,検証データDO

を参照する。 

両方のINS値で,P1=“FF”は,Lc及びコマンドデータフィールドが存在しない状態でだけ使用しなけ

ればならない。コマンドは,“確かめられない”として関連参照データの検証ステータスを設定しなければ

ならない。 

11.5.7 CHANGE REFERENCE DATAコマンド 

表102に,CHANGE REFERENCE DATA C-RPを示す。 

CHANGE REFERENCE DATAコマンドは,カードに格納されている参照データを接続装置から送られる

新しい参照データに置換するか,又は接続装置から送られた検証データとそれらの比較を開始し,その結

果でそれらを接続装置から送られた新しい参照データに置換する。コマンドは,セキュリティステータス

がこの処理のためのセキュリティ属性を満足する場合に限り,機能を実行することができる。 

background image

112 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表102−CHANGE REFERENCE DATAコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“24”又は“25” 

P1 

“00”又は“01”(他の値は,RFU) 

P2 

表94参照 

Lcフィールド 

Nc>0のため存在する。 

データフィールド  INS=“24” 

P1=“00” 

検証データの後に区切りなしの新しい参照データ 

P1=“01” 

新しい参照データ 

INS=“25” 

P1=“00” 

検証データDOの後に新しい参照データDO 

P1=“01” 

新しい参照データDO 

Lcフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“6300”(11.5.1参照),“63CX”(11.5.1参照),“6581”,“6700”,“6982”,
“6983”,“6984”,“6A81”,“6A82”,“6A86”,“6A88”(11.5.1参照)と関連するとき,
表5及び表6を参照 

11.5.8 ENABLE VERIFICATION REQUIREMENTコマンド 

表103に,ENABLE VERIFICATION REQUIREMENT C-RPを示す。 

ENABLE VERIFICATION REQUIREMENTコマンドは,検証データと参照データとを比較するための要

求を有効にする。それは,セキュリティステータスがこのコマンドのためのセキュリティ属性を満足する

場合に,実行することができる。 

表103−ENABLE VERIFICATION REQUIREMENTコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“28” 

P1 

“00”又は“01”(他の値は,RFU) 

P2 

表94参照 

Lcフィールド 

Nc=0のとき存在しない。Nc>0のとき存在する。 

データフィールド  P1=“00” 

検証データ 

P1=“01” 

存在しない。 

Leフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“6300”(11.5.1参照),“63CX”(11.5.1参照),“6581”,“6700”,“6982”,
“6983”,“6984”,“6A81”,“6A82”,“6A86”,“6A88”(11.5.1参照)と関連するとき,
表5及び表6を参照 

11.5.9 DISABLE VERIFICATION REQUIREMENTコマンド 

表104に,DISABLE VERIFICATION REQUIREMENT C-RPを示す。 

background image

113 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表104−DISABLE VERIFICATION REQUIREMENTコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“26” 

P1 

“00”,“01”又は下位5ビットが,参照データ番号を表す100xxxxx(他の値は,RFU) 

P2 

表94参照 

Lcフィールド 

Nc=0のとき存在しない。Nc>0のとき存在する。 

データフィールド  P1=“00”又はP1=100x xxxx 

検証データ 

P1=“01” 

存在しない。 

Leフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“6300”(11.5.1参照),“63CX”(11.5.1参照),“6581”,“6700”,“6982”,
“6983”,“6984”,“6A81”,“6A82”,“6A86”,“6A88”(11.5.1参照)と関連するとき,
表5及び表6を参照 

DISABLE VERIFICATION REQUIREMENTコマンドは,検証データと参照データとを比較するための要

求を無効にする。また,検証データと他の参照データとを比較するための要求が有効になる場合がある。

それは,セキュリティステータスがこのコマンドのためのセキュリティ属性を満足する場合に,実行する

ことができる。 

11.5.10 RESET RETRY COUNTERコマンド 

表105に,RESET RETRY COUNTER C-RPを示す。 

RESET RETRY COUNTERコマンドは,参照データ再試行カウンタを初期値にリセットするか,又は参

照データ再試行カウンタの初期値へのリセット完了後に参照データを変更する。それは,セキュリティス

テータスがこのコマンドのためのセキュリティ属性を満足する場合に,実行することができる。 

表105−RESET RETRY COUNTERコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“2C”又は“2D” 

P1 

“00”,“01”,“02”又は“03”(他の値は,RFU) 

P2 

表94参照 

Lcフィールド 

Nc=0のとき,存在しない。Nc>0のとき,存在する。 

データフィールド  INS=“2C” 

P1=“03” 

存在しない。 

P1=“00” 

リセットコードの後に区切りなしの新しい参照データ 

P1=“01” 

リセットコード 

P1=“02” 

新しい参照データ 

INS=“2D” P1=“03” 

存在しない。 

P1=“00” 

リセットコードDOの後に新しい参照データDO 

P1=“01” 

リセットコードDO 

P1=“02” 

新しい参照データDO 

Leフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“6300”(11.5.1参照),“63CX”(11.5.1参照),“6581”,“6700”,“6982”,
“6983”,“6984”,“6A81”,“6A82”,“6A86”,“6A88”(11.5.1参照)と関連するとき,
表5及び表6を参照 

background image

114 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

11.5.11 MANAGE SECURITY ENVIRONMENTコマンド 

表106に,MANAGE SECURITY ENVIRONMENT C-RPを示す。 

MANAGE SECURITY ENVIRONMENTコマンドは,セキュアメッセージング(箇条10参照)及びセキ

ュリティコマンド(例えば,EXTERNAL AUTHENTICATE,INTERNAL AUTHENTICATE及びGENERAL 

AUTHENTICATE。JIS X 6320-8のPERFORM SECURITY OPERATIONも参照)の下準備を行う。コマンド

は,次の機能を提供する。 

− SET すなわち,カレントSEの一つの構成要素を設定するか又は置換する。 

− STORE すなわち,カレントSEをP2のSEIDの下に保存する。 

− RESTORE すなわち,カードに格納されていて,かつ,P2のSEIDで識別したSEでカレントSEを

置換する。 

− ERASE すなわち,カードに格納されていて,かつ,P2のSEIDで識別したSEを削除する。 

− RESET すなわち,DF又はアプリケーションDFの選択後に省略時SEを再設定する。 

− GET SE すなわち,カレントSEに属する全ての制御参照DOを読み出す。 

− GET CRT すなわち,カレントSEに属する一つの制御参照テンプレートを読み出す。 

表106−MANAGE SECURITY ENVIRONMENTコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“22” 

P1 

表107参照 

P2 

表108参照 

Lcフィールド 

Nc=0のとき存在しない。Nc>0のとき存在する。 

データフィールド  GET,STORE,RESTORE,ERASE,RESET 存在しない。 

SET 

制御参照DOの連結 

Leフィールド 

SET,STORE,RESTORE,ERASE,RESET Ne=0のため存在しない。 

GET 

Ne>0のため存在する。 

データフィールド  GET SE 

制御参照DOの連結 

GET CRT 

一つの制御参照テンプレート 

その他 

存在しない。 

SW1-SW2 

例えば,“6600”,“6987”,“6988”,“6A88”(11.5.1参照)と関連するとき,表5及び表6
を参照 

background image

115 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表107−MANAGE SECURITY ENVIRONMENTコマンドのP1の符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − 

− − − − コマンドデータフィールドのセキュアメッセージング 

− − 

− − − − − レスポンスデータフィールドのセキュアメッセージング 

− 

− − − − − − 計算,復号,内部認証及び鍵共有 

− − − − − − − 検証,暗号化,外部認証及び鍵共有 

− − − − 

SET 

STORE 

RESTORE 

RESET 

ERASE 

GET CRT 

GET SE 

− 他の値は,RFUである。 

表108−MANAGE SECURITY ENVIRONMENTコマンドのP2の符号化 

値 

意味 

“XX” 

P1がSTORE,RESTORE又はERASEを示す場合,“EF”を除いた
“01”〜“FE”の値のSEID(10.3.3参照) 

“A4”,“A6”,“AA”,

“B4”,“B6”,“B8” 

P1がSET又はGET CRTを示す場合,コマンドデータフィールド中
に存在する表54の意味を備えたCRTのタグ 

“00” 

P1がGET SE又はRESETを示す場合 

− 他の値は,RFUである。 

KEY DERIVATION機能 主(マスタ)鍵概念を適用すると,主(マスタ)鍵を格納しているカード内で

鍵の派生を必要とする場合がある。表109は,鍵を派生するためのMANAGE SECURITY ENVIRONMENT

コマンドの使用法を示す。ここでは,カード内で主(マスタ)鍵及びアルゴリズムは,暗黙的に選択され

ている。そうでなければ,MANAGE SECURITY ENVIRONMENTコマンドは,鍵及びアルゴリズムを明示

的に選択することができる。 

注記 アルゴリズム参照によって,主(マスタ)鍵から鍵を派生するためのデータは,後続するコマ

ンド(例えば,EXTERNAL AUTHENTICATE)の入力データの一部であってもよい。この場合,

鍵を派生するためのMANAGE SECURITY ENVIRONMENTコマンドは必要ではない。 

表109−KEY DERIVATION機能に対するコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“22” 

P1 

“X1”(SET,表107参照) 

P2 

CRTタグ(例えば,EXTERNAL AUTHENTICATEが続く場合は“A4”,又はVERIFY 
CRYPTOGRAPHIC CHECKSUMが続く場合は“B4”。) 

Lcフィールド 

Nc>0のため存在する。 

データフィールド  {“94”‒L‒ 鍵を派生するデータ(必須)} SM DOが存在してもよい。 

Leフィールド 

Ne=0のため存在しない。 

データフィールド  存在しない。 

SW1-SW2 

例えば,“6600”,“6987”,“6988”,“6A88”(参照データが存在しない。)と関連すると
き,表5及び表6を参照 

background image

116 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

11.6 その他 

11.6.1 COMPAREコマンド 

表110に,COMPARE C-RPを示す。 

COMPAREコマンドは,参照データと比較データとの比較を開始する。参照データは,基本DOの値,

レコードの内容,又はデータ列の内容のいずれかとする。参照データは,表86に従って定義される。カ

ードは,比較に適切な全ての個々の要素を2進符号化数として解釈しなければならない。コマンド又はレ

スポンスデータの中で範囲が提供される場合,その範囲の限界値は,比較されるデータと同じタイプでな

ければならない。 

表110−COMPAREコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“33” 

P1 

“00” 

COMPARE BINARY機能。参照値は,透過構造EFに位置する。 

“01” 

COMPARE RECORD機能。参照値は,構造化EFに位置する。 

“02” 

COMPARE DATA機能。参照値は,DOに位置する。 

その他の値 

RFU 

P2 

処理指定条件(詳細は,次を参照) 

“00” 

OIDによって定義された比較 

“01” 

等しい。 

“02” 

より大きい。 

“03” 

より小さい。 

“04” 

等しくない。 

“05” 

範囲内の要素[下限値,上限値] 

“06” 

範囲外の要素[下限値,上限値] 

“07” 

比較データは,コマンドによって定義された値の有限集合に属さなければ
ならない。 

“08” 

比較データは,コマンドによって定義された値の有限集合に属してはなら
ない。 

[“09”〜“7F”]RFU 

[“80”〜“FF”]個別利用 

Lcフィールド 

Nc>0のため存在する。 

データフィールド  DO“06”OID条件付き。P2=“00”場合だけに存在する。 

いずれか選
択(必須) 

一般参照テンプレートDO“60”,表86で定義される。 

コマンドの対象を参照するためにアプリケーションが定義するDOを入れ
子にする,タグ“70”〜“72”又はタグ“74”〜“77”(8.3.5参照)のDOに
続くDO“78”。 

表37で定義されるオブジェクトロケータDO“7F72” 

ラッパDO“63”(8.4.8参照) 

データフィールドは,DO“53”又はDO“73”配下でカプセル化された比較データで任
意に終了する。 

Leフィールド 

Ne=0のため存在しない,又はNe>0のため存在する。 

データフィールド  存在しない,又は存在する(次を参照)。 

SW1-SW2 

例えば,“6282”,“6340”,“6982”と関連するとき,表5及び表6を参照 

比較データは,次のいずれかでなければならない。 

− コマンドデータフィールドで伝送されたデータ。 

117 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− カードによって知られているデータ。 

定義によって,参照値は,参照データの中で符号化された数であり,比較値は,比較データの中で符号

化された数とする。 

コマンドの機能(COMPARE BINARY,COMPARE RECORD,又はCOMPARE DATA)は,設定するP1

で各々値“00”,“01”,“02”として符号化しなければならない。 

処理のタイプは,P2(処理指定条件)によって定義する。 

− P2=“00” 比較機能が,データフィールドのOID DO“06”によって定義される。 

− P2=“01” 参照値が比較値と等しい場合,比較は成功する。 

− P2=“02” 参照値が比較値よりも大きい場合,比較は成功する。 

− P2=“03” 参照値が比較値よりも小さい場合,比較は成功する。 

− P2=“04” 参照値が比較値と等しくない場合,比較は成功する。 

− P2=“05” 参照値がコマンドで定義された範囲内の要素である場合,比較は成功する。 

− P2=“06” 参照値がコマンドで定義された値の範囲内の要素でない場合,比較は成功する。 

− P2=“07” 参照値がコマンドで定義された値の有限集合の要素である場合,比較は成功する。 

− P2=“08” 参照値がコマンドで定義された値の有限集合の要素でない場合,比較は成功する。 

− P2の値[“09”〜“7F”]は,RFUとする。 

− P2の値[“80”〜“FF”]は,個別利用とする。 

結果は,コマンドレスポンスの状態バイトによって示す。“6340”に設定されたSW1-SW2は,比較デー

タが参照データと一致しなかったことを示す。 

比較データがコマンドデータフィールド中で与えられる場合,P2の値によって,次のいずれかとする。 

− “01”,“02”,“03”又は“04”に等しい場合,値は,DO“53”の値フィールドで与えなければならな

い。 

− “05”又は“06”に等しい場合,閉ざされた範囲は,DO“73”の値フィールドで提供しなければなら

ない。この場合,DO“73”は,二つのDO“80”だけを含んでいなければならない。最初のDO“80”

は,範囲の下限値を含んでいなければならない。2番目のDO“80”は,範囲の上限値を含んでいなけ

ればならない。 

− “07”又は“08”に等しい場合,集合は,DO“73”の値フィールドで提供しなければならない。この

場合,集合の各々の値は,DO“53”の値フィールドで与えなければならない。 

コマンドが成功し,P2=“01”,“04”,“05”又は“06”のとき,任意のレスポンスデータフィールドは,

存在してもよい。存在しているとき,それは,比較データに一つの要素が一致する(P2=“01”又は“05”)

の範囲内で,又はどの要素も一致しない(P2=“04”又は“06”)範囲内で,閉ざされた範囲の限界を定義

する二つのDO“80”の連結でなければならない。 

11.6.2 GET ATTRIBUTEコマンド 

表111に,GET ATTRIBUTE C-RPを示す。 

GET ATTRIBUTEコマンドは,各々の処理のためのアクセス条件を満たしている場合,参照したセキュ

リティオブジェクトの一つのオブジェクト属性を読み出す。各々のセキュリティオブジェクトを,コマン

ドのデータフィールドのデータオブジェクトロケータが参照しなければならない。コマンドでEF又はDO

を参照する場合,空の属性参照は,オブジェクトロケータテンプレートで必須とする。各々の属性は,参

照したセキュリティオブジェクトによって,専用のセキュリティ環境に,又は専用のサービス提供に関連

してもよい。関連属性は,レスポンスAPDUのデータフィールドのBER-TLVオブジェクトとして読み出

background image

118 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

される。 

表111−GET ATTRIBUTEコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“34”又は“35” 

P1-P2 

“0000” 

Lcフィールド 

Nc>0のため存在する。 

データフィールド 

INS=“34” オブジェクトロケータテンプレート(表37参照) 

INS=“35” オブジェクトロケータDO“7F72”(表37参照) 

Leフィールド 

Ne>0 のため存在する。 

データフィールド 

BER-TLVに符号化された属性 

SW1-SW2 

関連する応答がある場合,表5及び表6参照 

11.7 伝送用コマンドの扱い 

11.7.1 GET RESPONSEコマンド 

表112に,GET RESPONSE C-RPを示す。 

GET RESPONSEコマンドは,利用可能な伝送プロトコルでは送信できなかったレスポンスAPDU又は

その一部分を送信する(5.3.4参照)。 

注記 Leフィールドが“00”に設定されたバイトだけを含んでいる場合には,送信すべきバイトは全

て,短縮Leフィールドでは256の範囲,又は拡張Leフィールドでは65 536の範囲で返すのが

望ましい。 

表112−GET RESPONSEコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“C0” 

P1-P2 

“0000”(他の値は,RFUである。) 

Lcフィールド 

Nc=0のため存在しない。 

データフィールド  存在しない。 

Leフィールド 

Ne>0のため存在する。 

データフィールド  誤りの場合は存在しない,又はNeによるレスポンスAPDU又はその一部分 

SW1-SW2 

例えば,“61XX”(“XX”は,後続するGET RESPONSEによる送信可能な残存バイト数
を示す。),“6281”,“6700”,“6A81”,“6A82”,“6A86”,“6CXX”と関連するとき,表5
及び表6を参照 

11.7.2 ENVELOPEコマンド 

表113に,ENVELOPE C-RPを示す。 

INS=“C2”のENVELOPEコマンド又はENVELOPEコマンドの連鎖は,コマンドAPDUであるペイロ

ードを送信する。 

INS=“C3”のENVELOPEコマンド又はENVELOPEコマンドの連鎖は,DOであるペイロードを送信す

る。特別の用途は,次のとおりとする。 

− DOがDO“52”(コマンド実行)のとき,レスポンスがDOの連結になるのを除いて,INS=“C2”と

同じ機能性がある。入れ子にされたコマンドで指定されたレスポンスがそうでない場合,DO“53”で

入れ子にしなければならない。 

− DOがDO“06”(オブジェクト識別子)のとき,コマンドの正常終了(SW1-SW2=“9000”)は,カー

background image

119 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

ドがこのオブジェクト識別子によって参照されたドキュメントによって,定義された手順を開始する

準備ができていることを意味する。この手順又はスクリプトは,標準のAPDU構文に従わなければな

らない。手順の終わりは,手順の中で定義されなければならない。 

例1 インタフェース上でIPデータグラムの機構を用いるために,OIDによって示された仕様は,コ

マンド及びレスポンスペイロードで用いるデータグラムのカプセル化を定義しなければならな

い。 

例2 インタフェース上でISO/IEC 24727-3 [25] によって定義したAPIから得られたコマンド構文を用

いるために,ISO/IEC 24727-3 [25] で定義し,BER-TLVに整理した要求及び確認(ペイロード)

は,INS=“C3”のENVELOPE C-RPのコマンドデータフィールドでカプセル化する。 

注記 附属書Bは,セキュアメッセージングのためのENVELOPEコマンドの使用法を示す。 

表113−ENVELOPEコマンドレスポンス対 

CLA 

5.4.1で定義する。 

INS 

“C2”又は“C3” 

P1-P2 

“0000”(他の値は,RFUである。) 

Lcフィールド 

Nc>0のため存在する。 

データフィールド  INS=“C2” コマンドAPDU又はその一部 

INS=“C3” DO又はDOの一部 

Leフィールド 

Ne=0のとき存在しない。Ne>0のとき存在する。 

データフィールド  レスポンスAPDU若しくはその一部(INS=“C2”),DO“53”若しくはその一部(INS=

“C3”でDO“52”のとき),又は存在しない。 

SW1-SW2 

例えば,“6700”と関連するとき,表5及び表6を参照 

12 アプリケーション非依存のカードサービス 

カードサービスの目的は,この規格に従うこと以外は互いに関して何も知らないカードと接続装置との

間の情報交換の機構を提供することである。カードサービスは,管理情報バイト(12.1.1参照)の各種組

合せ,EF.DIR及びEF.ATR/INFOの内容(12.2.1及び12.2.2参照)並びにコマンドの順序に起因する。別段

の定めがない限り,全てのコマンドAPDUは,“00”に設定されたCLAを使用する。すなわち,コマンド

連鎖なし,セキュアメッセージングなし及び基本論理チャネルだけとする。 

一旦,アプリケーションがカード内で識別され選択されたならば,それは,この箇条に従う必要はない。

アプリケーションは,同様の機能を達成するためのこの規格と互換性をもつ他の機構を使用してもよい。

しかしながら,そのような方法は,情報交換を保証されないことがある。 

産業間共通利用情報は,基本論理チャネルでなく追加の論理チャネル経由で送られたコマンドによって

復元されてもよい。さらに,そのコマンドでは,いかなるNeを使用してもよい。このことは,12.1.1.1,

12.1.2,12.2.1,12.2.2及び12.4の情報読出しと同様に,前の段落と関係がある。 

12.1 カード識別 

このサービスは,接続装置がカードを識別し,扱えるようにする。管理情報バイト(12.1.1参照)は,

カード識別に対する総括的な支援情報を提供する。カードは,物理インタフェースを活性化(5.1参照)し

た直後に暗黙的に選択されたファイルへのアクセスを示すことで,論理的な内容に関する情報をカードの

外部世界へ直接的及び/又は間接的に提供する。直接的に提供する場合は,例えば,カードサービスデー

タバイト(表116参照)を用いる。間接的に提供する場合は,例えば,初期アクセスデータ(12.1.1.6参照)

background image

120 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

を用いる。したがって,この時点で利用可能なデータ,すなわち,初期データ列(12.1.2参照)は,この

後読み出せなくてもよい。 

12.1.1 管理情報バイト 

12.1.1.1 目的及び読出し 

管理情報バイト(JIS X 6320-3に定義するとおり15バイトまでの文字列)は,カードの動作特性を示す。

カードがリセットに応答するとき,リセット応答情報(Answer-to-Reset)は,管理情報バイトを含んでい

てもよい。 

物理的インタフェースがカードのリセット応答に適合しない場合,例えば,ユニバーサルシリアルバス

又は無線周波数によるアクセスの場合には,GET DATAコマンド(11.4.3参照)を用いて次のデータを読

み出してもよい。 

− DO“5F52”の管理情報バイト。コマンドAPDUは,“00CA 5F52 0F”とする。実用のために,DO“5F52”

は,物理インタフェース活性化後にカレントテンプレートに属することが望ましい。 

− DO“5F51”のリセット応答情報(Answer-to-Reset)。コマンドAPDUは,“00CA 5F51 20”とする。実

用のために,DO“5F51”は,物理インタフェース活性化後にカレントテンプレートに属することが望

ましい。 

12.1.1.2 構造及びCOMPACT-TLVデータオブジェクト 

管理情報バイトの先頭バイトは,“カテゴリ指標子バイト”とする。カテゴリ指標子バイトが“00”又は

“8X”に設定される場合,表114は,管理情報バイトの書式を示す。他の値は,個別利用書式を示す。 

第1の管理情報バイトが, 

− “00”に設定される場合には,残りの管理情報バイトは,任意選択の連続するCOMPACT-TLVデータ

オブジェクトと,それに後続する必須のステータス指標子(12.1.1.11参照)とで構成しなければなら

ない。 

− “80”に設定される場合には,残りの管理情報バイトは,任意選択の連続するCOMPACT-TLVデータ

オブジェクトで構成する。最後のデータオブジェクトは,COMPACT-TLV書式のステータス指標子

(12.1.1.11参照)としてもよい。 

タグフィールドが“4X”,長さフィールドが“0Y”及び値フィールドがYバイトで構成する全ての産業

間共通利用DOは,“コンパクトヘッダ”と呼ばれる“XY”及びYバイトの値フィールドで構成する

COMPACT-TLVデータオブジェクトに変換することができる。 

これ以降の12.1.1.3〜12.1.1.10で定義される全ての産業間共通利用データ要素は,EF.ATR/INFO(12.2.2

参照)内に存在してもよい。EF.ATR/INFO内に存在する場合には,DOの中に現れなければならない。す

なわち,タグフィールドが“4X”,長さフィールドが“0Y”及び値フィールドがYバイトに設定される。 

表114−カテゴリ指標子バイト 

値 

意味 

“00” 

ステータス指標子は,管理情報バイトの最後の3バイトに存在しな
ければならない(12.1.1.11参照)。 

“80” 

ステータス指標子は,COMPACT-TLVデータオブジェクトに存在し
てもよい(1〜3バイト,12.1.1.11参照)。 

“81”〜“8F” RFU 

− 他の値は,個別利用書式を示す。 

background image

121 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

12.1.1.3 国又は発行者指標子 

この産業間共通利用データ要素は,“1Y”又は“2Y”に設定されたコンパクトヘッダによって参照され,

国又は発行者の指標子を示す(表16のタグ“41”及び“42”も参照)。表115は,国又は発行者指標子を

示す。 

表115−国又は発行者指標子 

コンパクトヘッダ 

値 

“1Y” 

国コード(JIS X 0304 [3] 参照)及び任意選択の国データ 

“2Y” 

発行者識別番号(ISO/IEC 7812-1 [5] 参照)及び任意選択の発行者データ 

国指標子は,国コード(3桁の“0”〜“9”の値,JIS X 0304 [3] 参照)とバイト単位のデータとして扱う

ために付加した(少なくとも,4ビットの)データ1) とで構成する。関係する国の標準規格化機構は,バ

イト単位として扱えるようにデータ[奇数個のカルテット(4ビットデータ)]を追加しなければならない。 

発行者指標子は,発行者識別番号(ISO/IEC 7812-1 [5] 参照)と,後続データがある場合はそのデータと

で構成する。カード発行者は,後続バイト(例えば,カード発行者とカード保有者とを特定する最大19

桁の数字からなる番号を符号化するバイト)が存在する場合,その後続バイトを選択しなければならない。 

注記 ISO/IEC 7812-1:1993では,発行者識別番号は,4ビットで示す“0”〜“9”の値の桁数が奇数個

となってもよいとしている。この場合,最後のバイトのビットb4〜b1を(1111)に設定する。 

注1) ICカードは,バイト単位でデータ交換を行うため,3桁の国コードに対し不足の4ビットを付

加する。 

12.1.1.4 アプリケーション識別子 

この産業間共通利用データ要素は,“FY”に設定されたコンパクトヘッダによって参照され,アプリケ

ーション識別子(AID。12.2.3参照,及び表16のタグ“4F”も参照)とする。管理情報バイト内又は初期

データ列(12.1.2参照)内に存在する場合,AIDは,暗黙的に選択されたアプリケーションを示す(12.2.5.1

参照)。 

12.1.1.5 カードサービスデータ 

この産業間共通利用データ要素は,“31”に設定されたコンパクトヘッダによって参照され,箇条12で

記載するサービスを提供するカードの利用可能な方法を示す。表116は,カードサービスデータバイトを

示す。カードサービスデータバイトが管理情報バイト内又は初期データ列(12.1.2参照)内に存在する場

合には,カードサービスデータバイトは,EF.DIR及び/又はEF.ATR/INFO(12.2.1及び12.2.2参照)の存

在の有無を示し,また,それらにアクセスする方法を示す。管理情報バイト内及び初期データ列内にカー

ドサービスデータバイトが存在しない場合は,カードが暗黙のアプリケーション選択だけ(省略時値)を

提供することを示す。 

background image

122 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表116−カードサービスデータバイトの符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − アプリケーション選択 

− − − − − − − − DF名による選択 

− 

− − − − − − − 部分DF名による選択 

− − 

− − − − DOを使用 

− − 

− − − − − − EF.DIR内(12.2.1参照) 

− − − 

− − − − − EF.ATR/INFO内(12.2.2参照) 

− − − − 

− EF.DIR及びEF.ATR/INFOアクセスサービス 

− − − − 

− − READ BINARYコマンドによるアクセス(透過構造) 

− − − − 

− − READ RECORD(S)コマンドによるアクセス(レコード構造) 

− − − − 

− − GET DATAコマンドによるアクセス(BER-TLV構造) 

− − − − 

他の値 

− RFU 

− − − − − − − 

MFのあるカード 

− − − − − − − 

MFのないカード 

12.1.1.6 初期アクセスデータ 

この産業間共通利用データ要素は,“4Y”に設定されたコンパクトヘッダによって参照され,物理イン

タフェース活性化(5.1参照)後の最初のコマンドと想定されるコマンドAPDUを示す。コマンドAPDU

は,12.1.2で規定する。 

12.1.1.7 カード発行者データ 

この産業間共通利用データ要素は,“5Y”に設定されたコンパクトヘッダによって参照され,JIS X 6320

規格群 [6] では定義しない。カード発行者は,長さ,構造及び符号化を定義する。 

12.1.1.8 発行前データ 

この産業間共通利用データ要素は,“6Y”に設定されたコンパクトヘッダによって参照され,JIS X 6320

規格群 [6] では定義しない。カード製造業者は,カード製造業者,集積回路名,集積回路製造業者,ROM

マスクバージョン,オペレーティングシステムバージョンなどの長さ,構造及び符号化を定義する。この

産業間共通利用データ要素は,集積回路製造業者識別子を含んでいてもよい(JIS X 6320-6参照)。 

12.1.1.9 カード能力 

この産業間共通利用データ要素は,“71”,“72”又は“73”に設定されたコンパクトヘッダによって参照

され,次に示す三つ以内のソフトウェア機能バイトで構成する。データ要素の長さに応じて,次の処理を

行う。 

− 1バイトの場合,データ要素は,ソフトウェア機能バイト1(表117参照)とする。 

− 2バイトの場合,データ要素は,先頭バイトがソフトウェア機能バイト1(表117参照),2番目のバ

イトがソフトウェア機能バイト2(表118参照)とする。 

− 3バイトの場合,データ要素は,先頭バイトがソフトウェア機能バイト1(表117参照),2番目のバ

イトがソフトウェア機能バイト2(表118参照),3番目のバイトがソフトウェア機能バイト3(表119

参照)とする。 

ソフトウェア機能バイトの内容は,次のとおりとする。 

− ソフトウェア機能バイト1は,カードが提供している選択方法を示す。 

− ソフトウェア機能バイト2は,“データ符号化バイト”とする。データ符号化バイトは,タグ“82”に

よって参照されるファイルCPの2バイト目に存在してもよい(表10参照)。 

background image

123 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− ソフトウェア機能バイト3は,コマンド連鎖,拡張Lc及びLeフィールドの扱い,並びに論理チャネ

ル管理能力を示す。 

表117−ソフトウェア機能バイト1の符号化(選択方法) 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − DF選択(7.3参照) 

− − − − − − − − DF名による選択 

− 

− − − − − − − 部分DF名による選択 

− − 

− − − − − − パスによる選択 

− − − 

− − − − − ファイル識別子による選択 

− − − − 

− − − 暗黙のDF選択 

− − − − − 

− − 短縮EF識別子の提供 

− − − − − − 

− レコード番号の提供 

− − − − − − − 

レコード識別子の提供 

表118−ソフトウェア機能バイト2の符号化(データ符号化バイト) 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − − BER-TLV構造を提供するEF 

− 

− − − − − 書込み機能の種別 

− 

− − − − − − 一度書込み 

− 

− − − − − − 個別利用書込み 

− 

− − − − − − OR書込み 

− 

− − − − − − AND書込み 

− − − − 

カルテット(4ビットデータ)で表すデータ単位のサイズ(1〜32 768カル
テット,すなわち,16 384バイト)(2のべき乗値で表す。例えば,0001=2
カルテット=1バイト,省略時値。1111=215カルテット=32 768カルテッ
ト=16 384バイト) 

− − − 

− − − − BER-TLVタグフィールドの先頭バイトに対する値“FF”(8.1.1参照) 

− − − 

− − − − − 無効(パディングへの使用,省略時値) 

− − − 

− − − − − 有効(長い私的クラスのタグ,構造化符号化) 

表119−ソフトウェア機能バイト3の符号化(コマンド連鎖,長さフィールド及び論理チャネル番号) 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − − コマンド連鎖(5.3.3参照) 

− 

− − − − − − 拡張Lc及びLeフィールド(5.1参照) 

− − 

− − − − − EF ATR/INFO内の拡張長さ情報 

− − − 

− − − 論理チャネル番号の付与方法(5.4.2及び11.1参照) 

− − − 

− − − − カードによる付与 

− − − 

− − − − 接続装置による付与 

− − − 

− − − 基本論理チャネルだけ。 

− − − − − 

最大論理チャネル番号(5.4.1参照) 
− y,z及びtの全てが1でない場合には,4y+2z+t+1を意

味する。すなわち,1〜7。 

− y=z=t=1は,8以上を意味する。 

124 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

12.1.1.10 

アプリケーションファミリー識別子 

この産業間共通利用データ要素は,“91”に設定されたコンパクトヘッダによって参照され,JIS X 

6322-3 [18] で定義される1バイトで構成する。 

12.1.1.11 ステータス指標子 

カテゴリ指標子バイトを“00”に設定する場合には,最後の三つの管理情報バイトは,ステータス指標

子でなければならない。すなわち,カードLCS(1バイト)及びそれにSW1-SW2で示される二つの処理

状態バイトが後続する。 

カテゴリ指標子バイトを“80”に設定する場合,コンパクトヘッダが“81”,“82”又は“83”で参照さ

れる産業間共通利用データ要素は,管理情報バイトの終わりに1〜3バイト(他の長さは,RFU)のステー

タス指標子として存在してもよい。 

− 長さが1の場合,データ要素は,カードLCSとする。 

− 長さが2の場合,データ要素は,SW1-SW2とする。 

− 長さが3の場合,データ要素は,LCS及びそれに後続するSW1-SW2とする。 

LCSは,7.4.10及び表14によって解釈しなければならない。値“00”は,ステータスを報告しないこと

を示す。SW1-SW2の解釈は,5.6,表5及び表6による。値“0000”は,ステータスを報告しないことを

示す。 

12.1.2 初期データ列回復 

この産業間共通利用データ要素は,管理情報バイト(12.1.1参照)内の“4Y”に設定されたコンパクト

ヘッダ,又はEF.ATR/INFO(12.2.2参照)内のタグ“44”によって参照され,“初期アクセスデータ”と呼

ばれ,コマンドAPDUを示す。 

− 長さが1の場合には,コマンドAPDUは,次に示すようなREAD BINARYコマンド(11.2.3参照)と

する。すなわち,CLA INS P1 P2は,“00B0 0000”に設定し,Leフィールドは,初期アクセスデータ

の先頭,かつ,唯一のバイトに設定する。 

− 長さが2の場合には,表120に従って,初期アクセスデータの1バイト目は,読むべきEFの構造(ビ

ットb8)及び短縮識別子(ビットb5〜b1)を示す。 

− 第1バイトのビットb8を1に設定する場合には,コマンドAPDUは,次のようなREAD BINARY

コマンド(11.2.3参照)となる。すなわち,CLA INSは,“00B0”に設定する。ビットb5〜b1を00000

に設定した場合,P1は,“00”に設定しなければならない,そうでない場合は,P1は,初期アクセ

スデータの先頭バイトの値に設定し,P2は,“00”に設定し,そしてLeフィールドは,初期アクセ

スデータの2バイト目の値に設定しなければならない。 

− 第1バイトのビットb8を0に設定する場合には,コマンドAPDUは,READ RECORD(S)コマンド

(11.3.3参照)となる。すなわち,CLA INS P1は,“00B201”に設定し,P2のビットb8〜b4は,

初期アクセスデータの先頭バイトのビットb5〜b1の値(カレントEF又は短縮EF識別子を示す。)

とし,P2のビットb3〜b1は,110に設定し,そしてLeフィールドは,初期アクセスデータの2バ

イト目の値を設定する。 

− 長さが5以上の場合には,コマンドAPDUは初期アクセスデータのYバイトで構成する。 

コマンドAPDUは,カードへ送らなければならない。処理が完了した場合には,レスポンスデータフィ

ールドは,一連の産業間共通利用DOとする。これらは,“初期データ列”と呼び,全てのアプリケーショ

ンに関係するかもしれない。 

background image

125 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

表120−長さが2のときの初期アクセスデータの先頭バイトの符号化 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − − EF構造 

− − − − − − − レコード構造 

− − − − − − − 透過構造 

− 

− − − − − 00(他の値は,RFU) 

− − − 

カレントEF 

− − − 全てが同じではない。 短縮EF識別子 

12.2 アプリケーション識別及び選択 

このサービスは,カードのアプリケーションを識別し,選択する方法と同様に,どのアプリケーション

がカード内で提供されているかを接続装置が知ることを可能にする。 

二つの特定のEF(すなわち,EF.DIR及びEF.ATR/INFO)は,アプリケーション識別及び選択のために

補助的に用いる。それらは,DOの集合を含んでいる。これらのEFでは,DOの消去又は修正によって,

READ BINARY及びREAD RECORD(S)コマンドのレスポンスデータフィールドのDOの前,間及び後を,

パディングで埋めてもよい(8.1.1参照)。 

12.2.1 EF.DIR 

このEFは,カードが提供するアプリケーションの一覧を示す。これは,アプリケーションテンプレー

ト(12.2.4参照)及び/又はアプリケーション識別子DO(12.2.3参照)の集合を,任意の順に含んでいる。

これは,示されたアプリケーションを選択するためにどのコマンドを実行しなければならないかを決める。 

MF及びEF.DIRが存在する場合,EF.DIRは,親ファイルとしてMFをもち,パスは,“3F002F00”でな

ければならない。MF直下では,短縮EF識別子30(すなわち,2進数で11110)は,EF.DIRを参照する。 

MFが存在しない場合,EF.DIRは存在してもよい。EF.DIRは,物理インタフェース活性化(5.1参照)

後にファイル識別子“2F00”によって指定可能であることが望ましい。 

注記 内容を読み出すためのコマンド(の順序)は,EF.DIRの構造(例えば,表116参照)に依存し,

カードの外部世界のアプリケーションによって暗黙的に知られていてもよい。 

EF.DIRがDOの扱いを提供する場合又はその内容がファイルに保存されていない場合,カードはGET 

DATAコマンド(11.4.3参照)で内容を提供してもよい。コマンド“00CB 2F00 02 5C00 00”のレスポンス

データは,EF.DIR内に存在しているか,又は,EF.DIRが実際には存在していないならばどこかに存在し

ているであろう,全てのDOを連結したものである。 

カードがこのサービスを提供する場合,コマンドは,少なくとも,物理インタフェース活性化(5.1参照)

直後に正常に処理されることが望ましい。 

12.2.2 EF.ATR/INFO 

このEFは,カードの動作特性を示す。これは,アプリケーション選択に関係しないか又はEF.DIRがな

いかのいずれかの理由によって,EF.DIR内で入れ子にすることができない産業間共通利用DOの集合を含

んでいる。 

注記1 EF.ATR/INFOは,この規格の前の版ではEF.ATRと称した。非接触カードがATRを提供しな

い場合があるので,この用語は非接触カードの分野で紛らわしかった。代わりに,新しい用

語としてEF.ATR/INFOを推奨している。接触カードの規格及び仕様では,EF.ATRとしてい

てもよいし,非接触カード規格及び仕様ではEF.INFOとしていてもよい。 

MF及びEF.ATR/INFOが存在する場合,EF.ATR/INFOは,親ファイルとしてMFをもち,パスは,

background image

126 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

“3F002F01”でなければならない。 

MFが存在しない場合,EF.ATR/INFOは,親ファイルとしてアプリケーションDFをもち,そのアプリ

ケーション内に置かれていてもよい。アプリケーションによって他の方法で定義されないならば,そのフ

ァイル識別子は,“2F01”でなければならない。 

注記2 内容を読み出すためのコマンド(の順序)は,EF.ATR/INFOの構造(例えば,表116参照)

に依存し,カードの外部世界のアプリケーションによって暗黙的に知られていてもよい。 

EF.ATR/INFOがDOの扱いを提供する場合又はその内容がファイルに保存されていない場合,カードは,

GET DATAコマンド(11.4.3参照)で内容を提供してもよい。コマンド“00CB 2F01 02 5C00 00”のレスポ

ンスデータは,EF.ATR/INFOに存在しているか,又は,EF.ATR/INFOが実際には存在していないならばど

こかに存在しているであろう,全てのDOの連結である。 

カードがこのサービスを提供する場合,コマンドは,少なくとも物理インタフェース活性化(5.1参照)

直後に正常に処理されることが望ましい。 

注記3 インタフェースの活性化時にATRで示された情報が存在する場合は,その情報は,

EF.ATR/INFOの情報と取り替えてもよい。 

12.2.3 アプリケーション識別子 

この産業間共通利用データ要素は,管理情報バイト(12.1.1.4参照)内の“FY”に設定されたコンパク

トヘッダによって,又は初期データ列(12.1.2参照),EF.ATR/INFO,EF.DIR及び任意のDF(7.4参照)の

管理データ内のタグ“4F”によって参照され,アプリケーションを識別する。 

アプリケーション識別子(AID)は,16バイト以内で構成する。先頭バイトのビットb8〜b5は,表121

に従ってカテゴリを示す。 

表121−アプリケーション識別子のカテゴリ 

値 

分類 

意味 

“0”〜“9” 

− 

ISO/IEC 7812-1 [5] との下位互換性のために予約する(附属書D参照)。 

“A” 

国際用 

JIS X 6320-5に従ったアプリケーション提供者の国際登録 

“B”,“C” 

− 

RFU 

“D” 

国内用 

JIS X 6320-5に従ったアプリケーション提供者の国内登録(国コードは,JIS 
X 0304 [3] による。) 

“E” 

標準規格用 

ISO/IEC 8825-1に従ったオブジェクト識別子による標準規格の識別 

“F” 

個別利用 

アプリケーション提供者の登録管理外 

図10は,国際AIDを示す。国際AIDは,5バイトの登録アプリケーション提供者識別子(国際RID)

及び11バイト以内の任意選択な個別利用アプリケーション拡張識別子(PIX)で構成する。 

− 国際RIDは,一意にアプリケーション提供者を識別しなければならない(JIS X 6320-5参照)。 

− 先頭バイトのビットb8〜b5は,1010に設定しなければならない。すなわち,先頭のカルテット(4

ビットデータ)は,“A”に設定しなければならない。 

− 後続する9カルテットの各々は,“0”〜“9”の範囲で設定しなければならない。 

注記1 9カルテット(アプリケーション提供者識別子)は,国際RID機関から付番される。 

− 拡張部分は,自由に符号化する。拡張部分は,アプリケーション提供者がその異なるアプリケーショ

ンを識別することを可能にする。 

background image

127 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

登録されたアプリケーション提供者識別子 

(国際RIDで5バイト。先頭バイトは,“AX”に設定) 

個別アプリケーション拡張識別子 

(PIX。11バイト以内) 

図10−国際AID 

図11は,国内AIDを示す。国内AIDは,5バイトの登録アプリケーション提供者識別子(国内RID)

及び11バイト以内の任意選択の個別アプリケーション拡張識別子(PIX)で構成する。 

− 国内RIDは,一意にアプリケーション提供者を識別しなければならない(JIS X 6320-5参照)。 

− 先頭バイトのビットb8〜b5は,1101に設定する。すなわち,先頭のカルテットは,“D”に設定し

なければならない。 

− 後続する3カルテット(各値が“0”〜“9”)は,国コードを形成しなければならない(JIS X 0304 [3]

参照)。 

− 最後の6カルテットの各推奨値は,“0”〜“9”とする。 

注記2 6カルテット(アプリケーション提供者識別子)は,国内RID機関から付番される。 

− 拡張部分は,自由に符号化する。拡張部分は,アプリケーション提供者がその異なるアプリケーショ

ンを識別することを可能にする。 

登録されたアプリケーション提供者識別子 

(国内RIDで5バイト。先頭バイトは,“DX”に設定) 

個別アプリケーション拡張識別子 

(PIX。11バイト以内) 

図11−国内AID 

図12は,標準規格AIDを示す。標準規格AIDは,16バイト以内で構成する。先頭バイトは,1110 1000,

すなわち,“E8”に設定しなければならない。値“E0”〜“E7”及び“E9”〜“EF”は,RFUとする。オブ

ジェクト識別子(ISO/IEC 8825-1参照)は,アプリケーションを規定する標準規格を識別するために,先

頭バイトに続かなければならない[附属書Aの例を参照。例えば,JIS X 6320-11(バイオメトリクスを用

いた本人確認),JIS X 6320-15(暗号情報アプリケーション)]。アプリケーション拡張識別子(識別された

標準規格によって規定)は,異なる実装を識別するために続いてもよい。 

“E8” オブジェクト識別子(附属書A参照) 

アプリケーション特定のアプリケーション拡張識別子 

図12−標準規格AID 

図13は,個別利用AIDを示す。個別利用AIDは,16バイト以内で構成する。個別利用AIDの先頭バ

イトのビットb8〜b5は1111に,すなわち,“F”に設定しなければならない。個別利用のカテゴリでは,

アプリケーション提供者が登録されないので,異なるアプリケーション提供者が同じAIDを用いてもよい。 

個別利用アプリケーション識別子(個別利用AIDで16バイト以内。先頭バイトは,“FX”に設定) 

図13−個別利用AID 

警告 5バイトよりも短いAIDも,この規格に適合する。実装によっては,AIDの長さが少なくとも

5バイトであることを要求してもよい。AIDを割り当てる場合,このことは,考慮に入れるこ

とが望ましい。 

12.2.4 アプリケーションテンプレート及び関連データ要素 

この産業間共通利用テンプレートは,タグ“61”によって参照され,EF.ATR/INFO(12.2.2参照)内,

EF.DIR(12.2.1参照)内及び任意のDFの管理データ(7.4参照)内に存在してもよい。 

background image

128 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− そのようなテンプレートは,唯一のアプリケーション識別子を含まなければならない。幾つかのアプ

リケーション識別子が同一DFに対して有効なDF名の場合,各々は,異なるアプリケーションテン

プレート内に存在することが望ましい。 

− そのようなテンプレートは,表122に示し,次に定義するアプリケーションに関係のある他の産業間

共通利用DOを任意選択で含んでいてもよい。 

表122−アプリケーションの識別及び選択のための産業間共通利用DO 

タグ 

値 

“4F” 

アプリケーション識別子 

“50” 

アプリケーションラベル 

“51” 

ファイル参照 

“52” 

コマンドAPDU 

“53”,“73” 

自由裁量データ,自由裁量テンプレート 

“5F50” 

ユニフォームリソースロケータ(URL)(IETF RFC 1738 [26] 及びIETF RFC 2396 [27] 参照) 

“61” 

アプリケーション関連DOの集合 

“79” 

DO“61”配下で,このDOは,共存するタグ割付け体系を示す。 

次の産業間共通利用データ要素は,アプリケーション識別及び選択に対し補助的に用いる。 

アプリケーションラベル この産業間共通利用データ要素は,タグ“50”によって参照され,JIS X 6320

規格群 [6] では定義しない。アプリケーション提供者は,マンマシンインタフェース(例えば,表示するた

めの商標)で使用するためにそれを定義する。 

ファイル参照 この産業間共通利用データ要素は,タグ“51”によって参照される(7.3.2参照)。 

自由裁量のデータ(又はテンプレート) この産業間共通利用データ要素(又はテンプレート)は,タグ

“53”(又は“73”)によって参照され,アプリケーション提供者によって定義された関連するデータ要素

(又は入れ子DO)で構成する。 

ユニフォームリソースロケータ この産業間共通利用データ要素は,タグ“5F50”によって参照され,IETF 

RFC 1738 [26] 及びIETF RFC 2396 [27] で定義されるユニフォームリソースロケータ(URL)とする。カー

ド内のアプリケーションと通信する接続装置で要求されたソフトウェアの一部を指す。 

12.2.5 アプリケーション選択 

カードは,次のアプリケーション選択方法の,少なくとも一つを提供しなければならない。 

1) 暗黙のアプリケーション選択 

2) DF名のアプリケーション識別子(AID,12.2.3参照)を使用するアプリケーション選択 

3) EF.DIR又はEF.ATR/INFOを使用するアプリケーション選択 

12.2.5.1 暗黙のアプリケーション選択 

アプリケーションが物理インタフェースを活性化した結果として暗黙的に選択される場合,アプリケー

ション識別子は,管理情報バイト(12.1.1参照)内又は初期データ列(12.1.2参照)内に存在することが

望ましい。それが存在する場合には,暗黙的に選択されたアプリケーションを示す。アプリケーションが

管理情報バイト及び初期データ列内にアプリケーション識別子なしで暗黙的に選択される場合,アプリケ

ーション識別子は,EF.ATR/INFO(12.2.2参照)内に存在しなければならない。 

12.2.5.2 DF名としてAIDを使用したアプリケーション選択 

マルチアプリケーションカードは,5〜16バイトのAIDをデータフィールドに含む,P1=“04”,P2=“00”

に設定したSELECTコマンドに応答しなければならない。カード内部のアプリケーションのAIDがデータ

129 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

フィールドに一致している場合,コマンドは,正常に終了しなければならない。 

カード能力(12.1.1.9及び表117参照)が,カードは短縮のAIDによる選択を提供していると規定して

いる場合,カードは,P1=“04”,P2=“00”又はP1=“04”,P2=“02”のSELECTコマンドに応答しなけ

ればならない。その場合は,カード内部の任意のアプリケーションのAIDの最初の部分がデータフィール

ドに一致しているならば,コマンドは,正常に終了しなければならない。カードの複数のAIDが入力デー

タに一致している場合,これらのアプリケーションがコマンドの終了後に実際に選択される順序は,実装

依存とする。コマンドがAIDの部分的な一致で正常に終了する場合,それは,ファイル制御又は管理デー

タ中に(DO“84”又はDO“4F”として)選択されたアプリケーションの完全なAIDを返さなければなら

ない。 

カードは,アプリケーション選択でAID完全一致のための要件を規定する機構を提供してもよい。

SELECTコマンドは,アプリケーションAIDがカード内の唯一選択可能なアプリケーションとして短縮さ

れたAIDに一致している場合,失敗しなければならない,又は他のアプリケーションAIDが一致し選択

できる場合,アプリケーションを無視しなければならない。 

注記 カードのアプリケーションがP1=“02”の連続したSELECTコマンドで選択される順序は,例

えば,前のセッションで最後に選択されたアプリケーションに基づいて,静的又は動的であっ

てもよい。 

マルチアプリケーションカードのアプリケーションは,次のどれかによって特定されなければならない。 

− 個別利用,国内用,又は,国際用のカテゴリにおける単一のAID 

− 標準規格用カテゴリにおける一つ以上のAID 

アプリケーションが標準規格用カテゴリのAIDを指定することによって選択される場合,SELECTコマ

ンドで返されたAIDは,そのAIDがアプリケーションに対し規定されている場合には,個別利用,国内

用,又は国際用のカテゴリにおけるAIDとする。 

12.2.5.3 EF.DIR又はEF.ATR/INFOを使用したアプリケーション選択 

マルチアプリケーション接続装置については,EF.DIR又はEF.ATR/INFOを使用することが12.2.5.2の方

法よりも効率的となることがある。 

− アプリケーション識別子DOが,アプリケーションテンプレートになく,ファイル参照又は実行コマ

ンドのDOを伴わない場合,選択は,AIDをDF名として使用しなければならない。 

− アプリケーション識別子DOが,値フィールドが2バイト以上で構成するファイル参照DO(7.3.2参

照)を伴うアプリケーションテンプレート中にある場合,パスによる選択は,12.3によって実行しな

ければならない。 

− アプリケーション識別子DOが,一つ以上の実行コマンドのDOを伴うアプリケーションテンプレー

ト中にある場合,アプリケーション選択は,示されたコマンドによって行われる。実行するコマンド

DOが幾つかある場合,それらは,テンプレート内に存在する順に実行しなければならない。 

12.3 パスによる選択 

このサービスは,パス,すなわち,3バイト以上で構成するファイル参照DO(7.3.2参照)によってフ

ァイル識別子をもつEF及びファイル識別子をもつDFを選択できる。 

− 長さが偶数の場合,パスは,その最初の2バイトが“3F00”に設定されるときは絶対パス,設定され

ないときは相対パスとなる。最後の2バイトは,DF又はEFのいずれかを識別する。 

− DFへのパスについては,選択は,一つ以上のSELECTコマンド(“00A4 0100 02”に設定されたCLA 

INS P1 P2 Lc)によって実行することが望ましい。 

130 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− EFへのパスについては,パスの長さが4バイト以上の場合,選択は,一つ以上のSELECTコマン

ド(“00A4 0100 02”に設定されたCLA INS P1 P2 Lc)によって実行することが望ましい。最後であ

り唯一かもしれない選択は,“00A4 0200 02”に設定されたCLA INS P1 P2 Lcとともにパスの最後の

2バイト(EF識別子)を使用する。 

− 長さが奇数の場合には,パスは条件が付いている。パスは,“3F00”のない絶対パス,又はカレント

DFの識別子のない相対パスのいずれかに,一つ以上のSELECTコマンドでP1として使用する1バイ

ト値を続けて構成する。P1の値は,選択方法を決める。 

− P1の値が“08”又は“09”の場合,カードは,条件付きパスがP1,Lc及びデータフィールドを規

定し,P2が“00”に設定されるSELECTコマンドを提供しなければならない。 

− 他の場合,カードは,条件付きパスの最後のバイトに設定されたP1と“0002”に設定されたP2 Lc

とからなる一つ以上のSELECTコマンドを提供しなければならない。パスに沿った個々のファイル

は,連続して選択されなければならない。 

12.4 データ読出し 

このサービスは,接続装置がアプリケーション選択前に,交換のために使用される産業間共通利用デー

タ要素を読み出せるようにする。産業間共通利用DOは,存在するならば,管理情報バイト(12.1.1参照),

初期データ列(12.1.2参照),EF.ATR/INFO(12.2.2参照),及びEF.DIR(12.2.1参照)の順序で,直接又は

間接に読み出すのが望ましい。これらの産業間共通利用DOは,タグ割付け体系(8.3参照)に従って解釈

しなければならない。規格群が,GET DATAコマンド(11.4.3参照)による産業間共通利用DOの読出し

を推奨,又は必須とする。 

12.5 カード創生バイト列 

このサービスは,カードがバイト列を作り出せるようにする。ここでは,明瞭にするため,問合せ文と

は,カード創生バイト列(又はその一部)を示し,返答とは,外部装置からの応答(又はその一部)を示

す。例えば,完成した問合せ文は,コマンドAPDUを形成してもよいし,完成した返答は,レスポンス

APDUを形成してもよい。このように,場合によってはネットワークを通して,カードから接続装置まで

の伝送サービス,及びカードからカードまでの伝送サービスを可能にする。 

ここでは,次の三つの方法を規定する。 

− カードが,問合せ文を出したいことを示すトリガとしてのSW1-SW2の使い方。このようにして,カ

ードは,返答を期待できる。 

− 接続装置が,存在すれば,カードから問合せ文を読み出すための偶数INSのGET DATAコマンド(11.4.3

参照)及びカードへの返答を送信するための偶数INSのPUT DATAコマンド(11.4.6参照)の使い方。

GET DATA及びPUT DATAコマンドは,P1-P2を“0000”に設定しなければならない(表85参照)。 

− 問合せ文及び返答の構成方法 

12.5.1 カードによるトリガ 

“62XX”(“XX”は“02”〜“80”の値)に設定したSW1-SW2は,カードに接続機器が読み出すことが

望ましい“XX”バイトの問合せ文があることを意味する。これによって,カードは,返答を期待できる。 

“64XX”(“XX”が“02”〜“80”の値)に設定したSW1-SW2は,カードがコマンドを中断させたこと

を意味する。コマンドの完了は,“XX”バイトの問合せ文の回復によって条件付けられる。これによって,

カードは,返答を期待できる。 

上記の値が管理情報バイト内に存在する場合には,SW1-SW2を,上記のとおり解釈しなければならな

い。 

131 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

返答を送信するためのPUT DATAコマンド(12.5.2,2番目のダッシュを参照)を“64XX”に設定した

SW1-SW2で中断する場合には,カードは,次の動作を意図している。 

− “64XX”が“6402”〜“6480”のとき,カードは,少なくとももう一つの“XX”バイトの問合せ文を

送る。 

− “64XX”が“6401”のとき,カードは即時の返答を待つ。 

12.5.2 問合せ文及び返答 

カードにおいて利用可能な“XX”バイトの問合せ文を読み出すために,接続装置は,INSを“CA”に

し,P1-P2を“0000”に設定し,Leフィールドを“XX”に設定したGET DATAコマンドを送信しなければ

ならない。 

− “62XX”(“XX”は,“02”〜“80”の値)に設定したSW1-SW2は,接続装置が“XX”バイトの問合

せ文を更に読み出し,カード創生バイト列を外部装置で処理する前に既に読み出しておいた問合せ文

と連結することが望ましいことを意味する。 

− “9000”に設定したSW1-SW2は,カード創生バイト列が完全であることを意味する。これは,外部

装置で処理されてもよい。 

カードに返答を送信するために,接続装置は,INSを“DA”にし,P1-P2を“0000”に設定したPUT DATA

コマンドを送らなればならない。応答が一つのコマンドでは長すぎる場合には,幾つかのPUT DATAコマ

ンドは連鎖しなければならない(5.3.3参照)。各PUT DATAコマンドは,返答を送信し,その返答の連結

を応答とする。 

12.5.3 書式 

カード創生バイト列の先頭バイトの値は,次の書式を意味する。 

− 先頭バイトを“FF”に設定する場合には,後続バイトは,ISO/IEC TR 9577 [7] によって初期プロトコ

ル識別子を符号化しなければならない。バイト列は示されたプロトコルに従わなければならない。 

− 先頭バイトを“FF”に設定しない場合には,カード創生バイト列及び応答は,共にC-RPを形成しな

ければならない。 

全ての条件は,カードによって示された通信プロトコルに関連する。ただし,GET DATAコマンド,PUT 

DATAコマンド及び状態バイトSW1-SW2の適切な使用を除く。ここでは,応答の必要性,及び応答の内

容に関与するエンティティについては言及しない。 

12.6 一般的特徴管理 

このサービスは,カードが一般的な方法でカードに存在する特徴についてカードの外部世界に通知する

ことを可能とする。追加のサブテンプレートを加えることによって今後拡張可能なテンプレート(DO

“7F74”)は,カード[例えば,EF.ATR/INFO(12.2.2参照)及び/又は任意のアプリケーションDFのFCI]

に入っている。情報は,全てのアプリケーションに適用してもよい。アプリケーションFCIで指定された

値は,そのアプリケーションだけに適用する(EF.ATR/INFO内で指定された値に取って代わる。)。

EF.ATR/INFO又はアプリケーションFCIは,DO“7F74”の二つ以上のインスタンスを含んではならない。

情報は,EF.ATR/INFOを読むことによって,又はアプリケーションを選択するコマンドのレスポンスデー

タフィールド内で読み出されてもよい。 

このサービスは,格納されている特徴及びアプリケーションに関する簡潔な情報の読出しを提供する。

接続装置は,他の規格によって定義されるような格納されている特徴及びアプリケーションに関する追加

情報を読み出してもよい。 

background image

132 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

12.6.1 オンカードサービス 

このサービスは,カード上に有している特徴及び機構に関してカードの外部世界に通知するのを可能と

する。特徴管理テンプレートの中で入れ子にされた,このサブテンプレートは,連続する8ビットを一組

とするビット列で構成する。各ビットは,カードがもつ特徴及び機構を示す。ビットを設定することは,

カードがこの特徴をもっていることを示す。表123に,あらかじめ定められたカードがもつサービスを示

す。 

12.6.2 インタフェースサービス 

国際規格は,同時に活性化される可能性がある種々様々のインタフェースを定義する。各プロトコルの

通信機構は,マルチインタフェースの存在及び併用を示す可能性を提示していない。特徴管理テンプレー

ト中のこのサブテンプレートは,既存のプロトコルに関する情報及び通信の扱い方法を提示する(表123

参照)。 

表123−特徴管理DO“7F74”のためのテンプレート 

タグ 

長さ 

意味 

“81” 

可変長  オンカードサービスのためのサブテンプレート識別子 

特徴リスト[0〜n],拡張可能 

b8 b7 b6 b5 b4 b3 b2 b1 

第1バイトのビットの意味 

− − − − − − − 表示装置 

− 

− − − − − − 生体情報入力センサ 

− − 

000000(他の値は,RFU) 

“82” 

可変長  インタフェースサービスのためのサブテンプレート識別子 

通信特徴リスト[0〜n],拡張可能 

b8 b7 b6 b5 b4 b3 b2 b1 

第1バイトのビットの意味 

− − − − − − − 示された可能なインタフェースの同時使用 

− − − − − − 示された可能なインタフェースの最大一つの活性化 

− − − − − − − 

JIS X 6320-3に従ったT=0 

− − − − − − 

− JIS X 6320-3に従ったT=1 

− − − − − 

− − JIS X 6322-2に従った非接触 

− − − − 

− − − ISO/IEC 7816-12に従ったUSB 

− − − 

− − − − ETSI TS 102 613,TS 102 622に従ったSWP 

− 

− − − − − 00(他の値は,RFU) 

12.6.3 プロファイルサービス 

この規格は,アプリケーションのためのショートカットサービス(例えば,AID又はパスによるアプリ

ケーション選択。12.2.5.2及び12.3参照)を定義する。特に古いバージョンに対応した多くのアプリケー

ションが,様々な特徴がある異なるハードウェアチップに対応しなければならない。これらのアプリケー

ションの端末は,非常に速い方法でアプリケーション及びカードの可能な特徴を識別する必要がある(表

124参照)。 

この識別は,例えば,EF.DIR内で,プロファイルサービスによって提供される。 

表124−アプリケーションプロファイル識別のための産業間共通利用DO 

タグ 

値 

“73”  アプリケーションプロファイル識別子 

133 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

12.6.4 追加情報の提供 

例えば,周辺装置又はプロトコルの詳細情報は,一般特徴管理テンプレート内に存在してもよい。この

情報は,状況依存クラスのタグをもつ構造化DO内で提供しなければならない。そのタグ及び内容は,他

の規格又は仕様で定義してもよい。 

12.7 APDU管理 

12.7.1 拡張長さ情報 

拡張長さ情報(DO“7F66”)の存在は,カード能力に関するソフトウェア機能バイト3で示される(表

119参照)。 

DO“7F66”は,EF.ATR/INFO(12.2.2参照)及び/又はアプリケーションDFのFMD中に存在してい

てもよい。EF.ATR/INFOの場合,情報は全てのアプリケーションに適用する。アプリケーションFMDで

指定された値は,EF.ATR/INFO内で指定された値にとって代わって,そのアプリケーションにだけ適用す

る。 

EF.ATR/INFOは,DO“7F66”のインスタンスを最大一つ含まなければならない。アプリケーションFMD

は,DO“7F66”のインスタンスを最大一つ含まなければならない。DO“7F66”に入れ子にされた全ての

DOは,可変長とする。 

コマンドAPDU及びレスポンスAPDUのサイズ制限は,(各々DO“02”に入れ子にされている)二つの

整数によって定義される。タグ“7F66”配下では, 

− 最初のDO“02”は,正の整数を含まなければならない。コマンドAPDUのバイト数は,この数を超

えてはならない。 

− 2番目のDO“02”は,正の整数を含まなければならない。カードが特定のC-RPにレスポンス連鎖を

提供しない場合,このC-RPのNeを,レスポンスAPDUのバイト数がこの数を超えない値に設定しな

ければならない。 

12.7.2 提供されたINSコードのリスト 

INSリストDO“5F63”は,EF.ATR/INFO(12.2.2参照)及び/又は任意のアプリケーションDFのFMD

中に存在していてもよい。EF.ATR/INFOの場合,情報は全てのアプリケーションに適用する。アプリケー

ションFMDで指定された値は,EF.ATR/INFO内で指定された値にとって代わって,そのアプリケーショ

ンにだけ適用とする。 

DO“5F63”が存在する場合,EF.ATR/INFO又は任意のアプリケーションFMDは,最大一つのインスタ

ンスを含まなければならない。 

INSリストDO“5F63”は,カード又はアプリケーションが提供するINSバイトの連結を入れ子にする。 

134 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

附属書A 

(参考) 

オブジェクト識別子及びタグ割付け体系の例 

A.1 オブジェクト識別子 

ISO規格に関しては,最初のバイトは“28”,すなわち,10進数40とする(ISO/IEC 8825-1参照)。一

つ以上の連続バイトがこれに続く。1バイト以上の場合,ビットb8は,連続する最後のバイトで0に,そ

れ以前のバイトでは1に設定する。連続するバイトのビットb7〜b1は,数を符号化する。各々の数は,最

小バイトで符号化しなければならない。すなわち,値“80”は,連続する最初のバイトに対しては無効と

する。最初の数は,規格の番号である。2番目の数が存在している場合には,2番目の数は,部編成規格の

各部を示す。 

第1の例,{iso(1)standard(0)ic-cards(7816)}は,ISO/IEC 7816規格群 [6] を示す。 

− 10進数の7816は,“1E88”に等しい。すなわち,2進数で表すと0001 1110 1000 1000となり,さらに,

7ビットの2ブロックで0111101 0001000となる。 

− 各ブロックに適切な値のビットb8を挿入後,第1の規格シリーズ番号バイトの符号化は,1011 1101 

0000 1000となり,“BD08”に等しい。 

データ要素“28 BD08”は,標準カテゴリのAIDに使用されることがある(12.2.3参照)。 

AID=“E8 28 BD08 0B XX … XX”(ISO/IEC 7816-11は,アプリケーション識別子拡張“XX … XX”を

規定する。) 

AID=“E8 28 BD08 0F XX … XX”(ISO/IEC 7816-15は,アプリケーション識別子拡張“XX … XX”を

規定する。) 

第2の例,{iso(1)standard(0)e-auth(9798)part(5)}は,ISO/IEC 9798 [10] を示す。第1の規格シ

リーズ番号バイトは,次によって得られる。 

− 10進数の9798は,“2646”に等しい。2進数で表すと0010 0110 0100 0110となり,さらに,7ビット

の2ブロックで1001100 1000110となる。 

− 各ブロックに適切な値のビットb8を挿入後,第1の規格シリーズ番号バイトの符号化は,11001100 

01000110となり,“CC46”に等しい。 

データ要素“28 CC46 05 02”は,ISO/IEC 9798-5 [10] で2番目の機構を示す。すなわち,GQ2である。

そのような識別子はDO(タグ“06”,ユニバーサルクラス。ISO/IEC 8825-1参照)で伝えてもよい。 

DO = {“06 05 28 CC 46 05 02”} 

第3の例,{iso(1)standard(0)mess(9992)part(2)}は,ISO 9992-2 [12] を示す。 

第1の規格シリーズ番号バイトは,次によって得られる。 

− 10進数の9992は,“2708”に等しい。2進数で表すと0010 0111 0000 1000となり,さらに,7ビット

の2ブロックで1001110 0001000となる。 

− 各ブロックに適切な値のビットb8を挿入後,第1の規格シリーズ番号バイトの符号化は,1100 1110 

0000 1000となり,“CE08”に等しい。 

135 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

データ要素は,“28 CE08 02”(第2の連続バイトは“02”)となる。それはDOで伝えてもよい。 

DO = {“06 04 28 CE 08 02”} 

A.2 タグ割付け体系 

省略時タグ割付け体系の例 

DO1 = {“59 02 95 02”} 

DO2 = {“5F 24 03 97 03 31”} 

DO1(タグ“59”,カード有効期限)は,カード有効期限として1995年2月を符号化している(JIS X 6320-6

参照)。 

DO2(タグ“5F24”,アプリケーション有効期限)は,アプリケーション有効期限として1997年3月31

日を符号化する。 

互換性をもつタグ割付け体系の例 

DO1={“78 06”{“06 04 28 CE 08 02”}} 

DO2={“5F 24 03 97 03 31”} 

DO3={“70 04”{“80 02 XX XX”}} 

DO4={“67 06”{“5F 29 03 XX XX XX”} } 

DO1(タグ“78”,互換タグ割付け機関)は,オブジェクト識別子によって参照するISO 9992-2 [12] で定

義された互換タグ割付け体系を示す。DO1が初期データ列(12.1.2参照),又はEF.ATR/INFO(12.2.2参照)

に現れる場合には,タグ割付け機関は,カード全体で有効とする。DO1がDFに関する管理データ(7.4

参照)に現れる場合には,タグ割付け機関は,そのDF内で有効とする。 

DO2(タグ“5F24”,アプリケーション有効期限)は,アプリケーション有効期限として1997年3月31

日を符号化している。 

DO3(タグ“70”,タグ割付け機関に従った産業間共通利用テンプレート)は,ISO 9992-2 [12] で定義す

るタグ“80”のDOを含む。また,タグ“70”の意味も,ISO 9992-2 [12] で定義する。 

DO4(タグ“67”,認証データテンプレート)は,タグ“5F29”の交換プロファイルDOを含む。 

互換性をもつタグ割付け体系の別の例 

DO1={“5F 24 03 97 03 31”} 

DO2={“70 0C”{“06 04 28 CE 08 02”}{“80 04 XX XX XX XX”}} 

DO3={“67 06”{“5F 29 03 XX XX XX”}} 

DO1(タグ“5F24”,アプリケーション有効期限)は,適用有効期限として1997年3月31日を符号化す

る。 

DO2(タグ“70”,含まれているオブジェクト識別子によって定義する産業間共通利用テンプレート)は,

タグ“06”のDOを含む。そのDOは,後続するタグ“80”のDOをISO 9992-2 [12] に定義していることを

示す。タグ“70”の意味も,ISO 9992-2 [12] に定義している。 

DO3(タグ“67”,産業間共通利用認証データテンプレート)は,タグ“5F29”の交換プロファイルDO

を含む。 

注記1 この例では,タグ“78”の産業間共通利用DOを送信しないことを選択したために,ISO 

9992-2 [12] に定義されたDOは含むことができない。 

共存するタグ割付け体系の例 

DO1={“79 05”{“06 03 28 XX XX”}} 

136 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

DO2={“7E 06”{“5F 24 03 97 03 31”}} 

DO3={“70 06”{“XX XX XX XX XX XX”}} 

DO1(タグ“79”,共存するタグ割付け機関)は,タグ“28”から始めてオブジェクト識別子によって参

照する,すなわち,ISO規格で定義した共存タグ割付け体系について示す。DO1は,そのような体系で次

のいずれかに必ず現れなければならない。 

− タグ割付け機関が全カードに有効の場合,初期データ列(12.1.2参照)又はEF.ATR/INFO(12.2.2参

照)の中。 

− タグ割付け機関がDFのうちに有効の場合,そのDF(7.4参照)の管理データ中。 

DO2(タグ“7E”)は,産業間共通利用DOを入れ子にする産業間共通利用テンプレートである。 

注記2 この例では,“アプリケーション有効期限”という産業間共通利用DO(タグ“5F24”)が存

在し,アプリケーション有効期限としての1997年3月31日を符号化している。 

DO3(タグ“70”,テンプレート“79”に示されたタグ割付け機関に従って解釈される産業間共通利用テ

ンプレート)は,オブジェクト識別子で示された規格に従った解釈だけが可能である。 

background image

137 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

附属書B 

(参考) 

セキュアメッセージングの例 

B.1 

暗号化チェックサム 

ここでは,JIS X 6320-3の中で定義したC-RPの四つのケースについて,セキュアメッセージング(箇条

10参照)と暗号化チェックサム(10.2.3.1参照)とのそれぞれの使用例を示す。 

記法T*は,タグフィールドの最終バイトのビットb1が1(奇数タグ番号)に設定されることを意味す

る。すなわち,T*は,認証用のデータ要素の計算に含まれるSM DOを示す。 

記法CLA*は,データフィールドのセキュアメッセージングを意味する。CLA(5.4.1参照)においては,

ビットb8〜b6が000に,及びビットb4が1に設定されるか,又はビットb8〜b6が011に設定されるかの

いずれかである。 

記法CLA**は,CLAのビットb8〜b6が000に設定され,ビットb4及びb3が11に設定されている。す

なわち,コマンドヘッダが認証用のデータ要素の計算に含まれていることを意味する。 

その他の方法として,ヘッダは,タグ“89”のDOでカプセル化されてもよい。すなわち,タグ“89”

は,認証用のデータ要素の計算に含められるSM DOを示す。 

ケース1は,CLAの第一の符号化(表2参照)においてビットb3が暗号化チェックサムによるコマン

ドヘッダの保護をどのようにするかを示し,また,CLAの第二の符号化(表3参照)を使用する場合,機

能がどのように提供されるかを示す。ケース1では,保護はもちろん適用される。それが示されない他の

場合,CLAの第一の符号化においてビットb3の使用は,例を単純化するために,また,結果が常に同じ

であるのでコマンドAPDUの暗号化チェックサムの計算の対象となるデータの初めに1ブロックを加える。 

ケース1−コマンドデータなし及びレスポンスデータなし 

コマンドヘッダ部 

コマンド本体部 

CLA INS P1 P2 

存在しない。 

レスポンス本体部 

レスポンス後続部 

存在しない。 

SW1-SW2 

ケース1.a−保護なしのステータス 

コマンドヘッダは,このC-RP中で保護するただ一つの項目であるため,保護されると仮定する。 

コマンドヘッダ部 

コマンド本体部 

CLA*のb7 

CLA* INS P1 P2 

新Lcフィールド - 新データフィールド={T - L - 暗号化チェックサム} 

新Lcフィールド - 新データフィールド={T* - L - コマンドヘッダ}{T - L - 
暗号化チェックサム} 

暗号化チェックサムの長さが4バイトである場合,新しいLcフィールドを“06”(上段)又は“0C”(下

段)に設定する。 

新データフィールド=一つ又は二つのDO=条件付きの{T*-L -コマンドヘッダ},その後{T - L-暗号化チ

ェックサム} 

暗号化チェックサムの計算の対象となるデータは, 

− CLAの第一の符号化,1ブロック=[CLA** INS P1 P2パディング] 

background image

138 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− CLAの第二の符号化,1ブロック=[{T*-L -コマンドヘッダ}-パディング] 

注記1 ブロックについては,10.1参照。 

セキュアメッセージングを用いたレスポンスAPDUは,次のとおりとする。 

レスポンス本体部 

レスポンス後続部 

存在しない。 

SW1-SW2 

ケース1.b−保護されたステータス 

セキュアメッセージングを用いたコマンドAPDUは,次のとおりとする。 

コマンドヘッダ部 

コマンド本体部 

CLA*のb7 

CLA* INS P1 P2 

新Lcフィールド - 新データフィールド={T - L - 暗号化チェックサム} - 新
Leフィールド(“00”に設定) 

新Lcフィールド - 新データフィールド={(T - L - コマンドヘッダ}{T - L - 
暗号化チェックサム} - 新Leフィールド(“00”に設定) 

新データフィールド=一つ又は二つのDO=常に{T - L -暗号化チェックサム}で終わる条件付き{T -L -コ

マンドヘッダ} 

ケース1.aとの違いは,暗号化チェックサムがLeの存在によって要求しなければならない応答データに

属するため,新しいLeフィールド=“00”である。暗号化チェックサムの計算の対象となるデータは,ケ

ース1.aと同じものである。 

セキュアメッセージングを用いたレスポンスAPDUは,次のとおりとする。 

レスポンス本体部 

レスポンス後続部 

新データフィールド={T* - L - SW1-SW2} - {T - L - 暗号化チェックサム}) 

SW1-SW2 

新データフィールド=二つのDO={T*-L -SW1-SW2}-{T -L - 暗号化チェックサム} 

暗号化チェックサムの計算の対象となるデータ=1ブロック= [{T* - L - SW1-SW2} -パディング] 

ケース2−コマンドデータなし及びレスポンスデータあり 

セキュアメッセージングを用いないC-RPは,次のとおりとする。 

コマンドヘッダ部 

コマンド本体部 

CLA INS P1 P2 

Leフィールド 

レスポンス本体部 

レスポンス後続部 

データフィールド 

SW1-SW2 

セキュアメッセージングを用いたコマンドAPDUは,次のとおりとする。 

コマンドヘッダ部 

コマンド本体部 

CLA* INS P1 P2 

新Lcフィールド - 新データフィールド - 新Leフィールド(“00”に設定され
た1又は2バイト) 

新データフィールド=二つのDO={T*-L - Ne}-{T -L - 暗号化チェックサム} 

注記2 拡張Le“00 XX XX”をセキュアメッセージング中のデータオブジェクトの値部に設定する場

合は,“XX XX”とする(表50参照)。 

暗号化チェックサムの計算の対象となるデータ=1ブロック= [{T*-L - Ne}-パディング]。 

注記3 元のLeフィールドが“00”又は“000000”の場合,値フィールドは,存在しなくてもよい。

background image

139 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

すなわち,各々のDOは,“97 00”とする(10.4参照)。 

セキュアメッセージングを用いたレスポンスAPDUは,次のとおりとする。 

レスポンス本体部 

レスポンス後続部 

新しいデータフィールド 

SW1-SW2 

新データフィールド=三つのDO={T* - L - 平文}-{T*- L - SW1-SW2}-{T - L - 暗号化チェックサム} 

暗号化チェックサムの計算の対象となるデータ=平文に依存する一つ以上のブロック,例えば, 

− 1ブロック=[{T*-L -平文}{T*-L -SW1-SW2}-パディング] 

− 2ブロック=[{T*-L -平文の開始]-[平文の終了}-{T*- L -SW1-SW2}-パディング] 

ケース3−コマンドデータあり及びレスポンスデータなし 

セキュアメッセージングを用いないC-RPは,次のとおりとする。 

コマンドヘッダ部 

コマンド本体部 

CLA INS P1 P2 

Lcフィールド - データフィールド 

レスポンス本体部 

レスポンス後続部 

存在しない。 

SW1-SW2 

ケース3.a−保護なしのステータス 

セキュアメッセージングを用いたコマンドAPDUは,次のとおりとする。 

コマンドヘッダ部 

コマンド本体部 

CLA* INS P1 P2 

新Lcフィールド - 新データフィールド 

新データフィールド又は新コマンドペイロード=二つのDO={T* - L - 平文}-{T - L - 暗号化チェック

サム} 

暗号化チェックサムの計算の対象となるデータ=一つ以上の平文に依存しているブロックは,例えば,

次のとおりになる。 

例1 [{T*-L -平文}-パディング] 

例2 [{T*-L -平文}]-[パディング] 

例3 [{T*-L -平文の開始]-[ 平文の終了}-パディング] 

例1において,8バイトのブロックで,平文DO中のLの最大値は5である。その場合には,ブロック

は1バイトのパディングで終わる。 

例2において,8バイトのブロックで,平文DO中のLの値は6である。DOは,ブロック全体がパディ

ングのブロックが続くブロックを一杯にする。 

例3において,8バイトのブロックで,平文DO中のLの値は7〜13である。第2のブロックの終端に

少なくとも1バイトのパディングが入ることを残すためである。 

セキュアメッセージングを用いたレスポンスAPDUは,セキュアメッセージングを用いないレスポンス

APDUと同じとする。 

レスポンス本体部 

レスポンス後続部 

存在しない。 

SW1-SW2 

ケース3.b−保護されたステータス 

セキュアメッセージングを用いたコマンドAPDUは,次のとおりとする。 

background image

140 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

コマンドヘッダ部 

コマンド本体部 

CLA* INS P1 P2 

新Lcフィールド - 新データフィールド - 新Leフィールド(“00”に設定) 

新データフィールド又は新コマンドペイロード=二つのDO={T* - L - 平文} - {T - L - 暗号化チェック

サム} 

暗号化チェックサムの計算の対象となるデータ=一つ以上の平文に依存しているブロックは,例えば,

次のとおりになる。 

例4 [{T* - L -平文}- パディング] 

例5 [{T* - L -平文}] - [パディング] 

例6 [{T* - L -平文の開始] - [平文の終了} - パディング] 

例4において,8バイトのブロックで,平文DO中のLの最大値は5である。その場合には,ブロック

は1バイトのパディングで終わる。 

例5において,8バイトのブロックで,平文DO中のLの値は6である。DOがブロックを満たしており,

その後にパディングで満たされたブロックを伴わなければならない。 

例6において,8バイトのブロックで,平文DO中のLの値は7〜13である。第2のブロックの終端に

少なくとも1バイトのパディングが入ることを残すためである。 

セキュアメッセージングを用いたレスポンスAPDUは,次のとおりとする。 

レスポンス本体部 

レスポンス後続部 

新データフィールド(={T* - L - SW1-SW2} - {T - L - 暗号化チェックサム}) 

SW1-SW2 

新データフィールド=二つのDO={T* - L - SW1-SW2} - {T - L - 暗号化チェックサム} 

暗号化チェックサムの計算の対象となるデータ=1ブロック=[{T* - L - SW1-SW2 }- パディング] 

ケース4−コマンドデータあり及びレスポンスデータあり 

セキュアメッセージングを用いないC-RPは,次のとおりとする。 

コマンドヘッダ部 

コマンド本体部 

CLA INS P1 P2 

Lcフィールド - データフィールド - Leフィールド 

レスポンス本体部 

レスポンス後続部 

データフィールド 

SW1-SW2 

セキュアメッセージングを用いたコマンドAPDUは,次のとおりとする。 

コマンドヘッダ部 

コマンド本体部 

CLA* INS P1 P2 

新Lcフィールド - 新データフィールド - 新Leフィールド(“00”
に設定された1又は2バイト) 

新データフィールド=三つのDO= {T* - L - 平文} - {T* - L - Ne} - {T - L - 暗号化チェックサム} 

暗号化チェックサムの計算の対象となるデータは,ケース3.bと同じとする。 

セキュアメッセージングを用いたレスポンスAPDUは,次のとおりとする。 

レスポンス本体部 

レスポンス後続部 

新データフィールド(={T* - L - 平文} - {T* - L - SW1-SW2} - 
{T - L - 暗号化チェックサム}) 

SW1-SW2 

新データフィールド=三つのDO= 

141 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

{T* - L - 平文} - {T* - L - SW1-SW2} - {T - L - 暗号化チェックサム} 

暗号化チェックサムの計算の対象となるデータ=一つ以上のブロック= 

[{T* - L - 平文} - {T* - L - SW1-SW2 }- パディング] 

B.2 

暗号文 

パディングのある場合及びない場合の暗号文の使用(10.2.2参照)は,コマンド及びレスポンスデータ

フィールド内で示す。 

前に示した例における平文DOの代わりに,機密性のためのDOは,次のとおりに使用しなければなら

ない。 

1) ケースa−BER-TLVで符号化されない平文 

データフィールド={T - L - パディング内容指標バイト - 暗号文} 

暗号文として伝えられる平文=一つ以上のブロック=BER-TLVで符号化されない平文。平文は,パデ

ィング内容指標バイトに従ってパディングされていることがある。 

2) ケースb−BER-TLVで符号化された平文 

データフィールド={T - L - 暗号文} 

暗号文として伝えられる平文=暗号化されるべきバイト列=BER-TLV DO(パディングは,アルゴリ

ズム及びその利用モードに依存する。)。 

B.3 

制御参照 

制御参照(10.3.1及び10.3.2参照)の使用方法を示す。 

コマンドデータフィールド={T - L - 制御参照テンプレート} 

 ここで,制御参照テンプレート={T - L - ファイル参照} - {T - L - 鍵参照} 

B.4 

レスポンス記述子 

レスポンス記述子(10.3.4参照)の使用方法を示す。 

コマンドデータフィールド={T - L - レスポンス記述子} 

 ここで,レスポンス記述子={T(平文)- L(“00”)- T(暗号化チェックサム)- L(“00”)} 

レスポンスデータフィールド={T - L - 平文} - {T - L - 暗号化チェックサム} 

B.5 

ENVELOPEコマンド 

ENVELOPEコマンド(11.7.2参照)の使用方法を,次に示す。 

コマンドデータフィールド={T - L - パディング内容指標バイト - 暗号文} 

暗号文として伝えられる元の平文=(CLA* INS P1 P2から始まる)コマンドAPDU - パディング内容指標

バイトに従ったパディング 

レスポンスデータフィールド={T - L - パディング内容指標バイト - 暗号文} 

暗号文として伝えられる元の平文=レスポンスAPDU - パディング内容指標バイトに従ったパディング 

B.6 

セキュアメッセージング及びセキュリティ処理間の相互作用 

この箇条では,次の記号及び略語を適用する。 

142 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

CC 

暗号化チェックサム 

CG 

暗号文 

CLA** 

SM表示をもつCLA(ビットb8〜b6が000に設定され,ビットb4,b3が11に設定される。) 

DS 

ディジタル署名 

MSE 

MANAGE SECURITY ENVIRONMENT 

PCI 

パディング内容指標バイト 

PSO 

PERFORM SECURITY OPERATION 

SMC 

セキュリティ モジュール カード 

USC 

ユーザICカード 

次の例は,セキュリティモジュールカード(SMC)の使い方を示す。SMCは,ユーザICカード(USC)

へ送るためのセキュアなコマンドAPDUを生成し,対応するセキュアなレスポンスAPDUをUSCから受

け取って処理するため,すなわち,SM書式のデータフィールドを生成及び処理するために,セキュリテ

ィ処理を実行する。次の例では,二つのアプローチの相互作用を示す。 

− セキュリティ処理による個別のアプローチ(JIS X 6320-8参照) 

− セキュアメッセージングによる包括的なアプローチ(箇条10参照) 

次の例は,USC及びSMCが相互認証手順を完了したと仮定する。例えば,カード上で認証可能な証明

書に基づいて,相互認証手順が完了したと仮定する。認証手順は,この手順の後にUSC及びSMCで次の

2個の対称鍵を利用可能とする,鍵配送又は鍵共有機構を含んでいる。 

a) 暗号化チェックサムを計算するための対称鍵のセション鍵 

b) 暗号文を計算するための対称鍵のセション鍵 

認証手順としては,USC及びSMCの1個以上のカウンタを初期化する。例は,USC及びSMCによる

そのようなカウンタの利用及び管理方法を示しているわけではない。 

SMCのための全てのC-RPは,PSOコマンドとする。このコマンドは,セキュアメッセージングを使用

するのではなく,SM DO(及びMSEコマンドで設定したSM鍵)を使用する。 

USCのための全てのC-RPは,セキュアメッセージングを使用し,コマンドヘッダは,暗号化チェック

サムの計算に含められている。すなわち,CLAは,CLA**に切り換える。 

注記 コマンドPSO COMPUTE CC,PSO VERIFY CC及びPSO ENCIPHERによって行われる暗号処

理は,暗号アルゴリズムのブロック長の倍数である長さをもっている入力を要求してもよい。

この要求を満足するために,パディングが適用される。このパディングは,SMCの内部で適用

する。さらに,SMCは,PSO DECIPHERコマンドに応答する前にパディングバイトを削除す

る。したがって,入力又は出力データの末尾のパディングは,次の図及び記載には現れない。 

background image

143 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

図B.1は,SM化したAPDUを生成するための一般的な方式を示す。 

図B.1−SM化したAPDUの生成 

図B.2は,SM化したレスポンスAPDUを処理するための一般的な方法を示す。 

図B.2−SM化したレスポンスAPDUの処理 

次のシナリオは,ディジタル署名(DS)の計算方法を示す。ここでは,署名用プライベート鍵を使うと

きは,パスワードが正しく確認されることを必要としている。シナリオは,3段階で処理する。 

段階1−パスワード検証 

1.1) SMCへのコマンド: MSE SET [CCT, {“83”-“01”-“81”}] 

暗号化チェックサムを計算するためのセション鍵の参照が“81”の例を示す。 

SMCのレスポンス: 正常終了 

1.2) SMCへのコマンド: MSE SET [CT, {“83”-“01”-“82”}] 

暗号文を計算するためのセション鍵の参照が“82”の例を示す。 

SMCのレスポンス: 正常終了 

1.3) SMCへのコマンド: PSO ENCIPHER [パスワード] 

SM化する前のコマンドAPDU  

Lcフィールド 

データフィールド 

Leフィールド 

PSO Encipher 

データ 

CG(データ) 

“9000” 

PSO COMPUTE CC 

CLA** - INS - P1 - P2 - パディング - “87”- L - PCI=“01”- CG(データ)-“97”- L - Ne 

CC 

“9000” 

CLA** - INS - P1 - P2 

新Lcフィールド 

“87”- L - PCI=“01”- CG(データ)-“97”-L-Ne-“8E”-L- CC 

新Leフィールド 

SMC 

インタフェース 

CLA - INS - P1 - P2 

CLAをCLA**に切り替える 

USCへ送信するSM化したコマンドAPDU 

“80”- L - {“87”- L - PCI =“01”- CG(レスポンスデータ)-“99”-“02”-“9000”} - “8E”- L - CCB 

USCから受信するSM化したレスポンスAPDU 

“87”- L - PCI =“01”- CG(レスポンスデータ) - “99”-“02”-“9000” -“8E”-L- CC 

“9000” 

PSO VERIFY CC 

“9000” 

PSO DECIPHER 

CG(レスポンスデータ) 

レスポンスデータ 

“9000” 

SMC 

インタフェース 

SM化を解除したコマンドAPDU  

144 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

SMCのレスポンス: [CG(パスワード)] 

1.4) SMCへのコマンド: PSO COMPUTE CC [CLA** - INS - P1 - P2 ‒ パディング - {“87”- L - PCI - CG

(パスワード)} - {“97”- L - Ne }]  

SMCのレスポンス: [CC] 

接続装置は,SM化したVERIFYコマンドAPDUを構成する。 

1.5) USCへのコマンド: VERIFY [{“87”- L - PCI =“01”- CG(パスワード)} - {“97”- L - Ne } - {“8E”

-“04”- CC}] 

USCのレスポンス: [{“99”-“02”- SW1-SW2} - {“8E”-“04”- CC}] 

1.6) SMCへのコマンド: PSO VERIFY CC [{“80”-“04”- {“99”-“02”- SW1-SW2}} - {“8E”-“04”

- CC}] 

SMCのレスポンス: 正常終了 

段階2−ハッシュコードの計算 

2.1) SMCへのコマンド: PSO COMPUTE CC [CLA** - INS - P1 - P2 ‒ パディング - {“81”- L - ( {“90”- 

L - 中間ハッシュコード} - {“80”- L - 最終ブロック} ) } - {“97”- L - Ne }] 

SMCのレスポンス: [CC] 

2.2) USCへのコマンド: PSO HASH [ {“81”- L1(= 4+L2+L3)-( {“90”- L2 - 中間ハッシュコード} - {“80”

- L3 - 最終ブロック} )} - {“8E”-“04”- CC}] 

USCは,段階3でディジタル署名を計算するために内部の結果としてハッシュコードを保存する。 

USCのレスポンス: [ {“99”-“02”- SW1-SW2} - {“8E”-“04”- CC} ] 

2.3) SMCへのコマンド: PSO VERIFY CC [ {“80”-“04”- {“99”-“02”- SW1-SW2} } - {“8E”-“04”

- CC} ] 

SMCのレスポンス: 正常終了 

段階3−ディジタル署名の計算 

3.1) SMCへのコマンド: PSO COMPUTE CC [CLA** - INS - P1 - P2 - パディング - {“97”-“01”-“00”} ] 

SMCのレスポンス: [CC] 

3.2) USCへのコマンド: PSO COMPUTE DS [ {“97”-“01”-“00”} - {“8E”-“04”- CC} ] 

USCのレスポンス:  [ {“81”- L - DS} - {“8E”-“04”- CC} ] 

3.3) SMCへのコマンド: PSO VERIFY CC [ {“80”- L1(=2+L2)- {“81”- L2 - DS} } - {“8E”-“04”- CC} ] 

SMCのレスポンス: 正常終了 

145 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

附属書C 
(参考) 

GENERAL AUTHENTICATEコマンドによる認証機能の例 

二つ以上のGENERAL AUTHENTICATE C-RPは,認証機能を実行する。 

連鎖が使用されている場合には,CLAは,連鎖の最初のコマンドから最後から2番目のコマンドまで0xx1 

xxxxに設定し,連鎖の最後のコマンドは,0xx0 xxxxに設定する。他の6ビットは,連鎖中では一定のま

までなければならない(5.3.3参照)。 

INS P1 P2は,“86 00 00”,又は“87 00 00”のいずれかに設定する。 

Lcフィールドの値は,コマンドデータフィールドのDOに依存する。Leフィールドは,レスポンスデー

タフィールドが必要な場合は,“00”に設定され,レスポンスデータフィールドが不要な場合は,存在しな

い。 

C.1 証拠情報(ウィットネス),チャレンジ及びレスポンスの3交信認証方式を使用する一般認証 

C.1.1 一般 

この附属書は,ISO/IEC 9798-5 [10](すなわち,ゼロ知識技法を使用する機構)に規定しているような機

構を実装するGENERAL AUTHENTICATEコマンドのデータフィールドを説明する。 

− 検証者は,公知の問題を知っており,要求者は,公知の問題に対する秘密の解決策を知っている。 

− ゼロ知識プロトコルの結果によって,検証者は,要求者が公知の問題に対する解決策を知っていると

確信する。そのうえ,解決策は秘密のままである。 

注記 ISO/IEC 9798-5 [10] は,二つのGQ技法を規定する。 

− 指数vが257=28+1,65 537=216+1又は236+213+1のような素数をもつRSAの公開鍵が与えられた

場合には,GQ1技法は,その値に関する知識なしでRSA署名を検証することを可能にする。又は,

もう一つの方法としてGQ1技法は,値を明らかにしないでRSA署名に関する知識を立証することを

可能とする。使用中のRSA署名規格(例えば,ISO/IEC 14888-2 [19] 参照)に規定しているように,形

式化する機構によって,要求者の識別データ(テンプレート)を公知の数Gに変換する。対応するプ

ライベートの数Qは,識別データのRSA署名である。要求者及び検証者は,RSAの公開鍵を知って

いる。GQ1プロトコルは,要求者が自分の識別データのRSA署名を知っていることを立証する。 

− 公開剰余値n(二つの素因数の積)が与えられた場合には,GQ2技法は,それらに関する知識なしで,

因数について検証するか,又はそれらを明らかにしないで,因数に関する知識を立証する。この機構

は,セキュリティパラメタk>0及び最初のm個の素数(m個の基本数という。)を含む。k×mは,8

〜36となる。各々の公知の数は基本数の2乗である。つまりG=g2。対応するプライベートの数Qは,

Gのモジュラ2k+1乗根である。nに関するgのヤコビ(Jacobi)シンボルが−1になるような少なくと

も一つの基本数gが存在し,かつ,nがmod 4で1に一致している場合には,GQ2プロトコルは,n

が合成数であること及び要求者が要素を知っていることを立証する。 

プロトコルは,一般に三つの番号,すなわち,証拠情報(ウィットネス),チャレンジ及びレスポンスを

やり取りする。 

− 要求者は2段階で実行する。第1段階として,要求者は,内部で毎回生成する乱数を選択し,それを

“証拠情報(ウィットネス)定式”に従って証拠情報に変換する。第2段階として,チャレンジを受

background image

146 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

けて,要求者は,“レスポンス定式”に従い,その乱数及び非公開の数値からチャレンジへのレスポン

スを得て,次にその乱数を消去する。 

− “検証定式”に従って,検証者はチャレンジとレスポンスとから証拠情報を再構築する。 

定義上,検証定式を検証しながら,3交信認証方式は,三つの番号,すなわち,証拠情報,チャレンジ

及びレスポンスで構成する。どのエンティティも,任意のチャレンジとレスポンスとから“公開のモード”

で3交信認証を無作為に生成してもよい。検証者又は観察者は,公開のモードで(すなわち,そのプライ

ベート鍵を知らないエンティティによって)生成された無作為の3交信認証と,“プライベートのモード”

で(すなわち,プライベート鍵を知っているエンティティによって)生成された無作為の3交信認証とを,

区別することができない。 

この附属書は,三つの認証機能を説明する。 

− 内部認証機能−カード外部の検証者は,カード内の要求者を認証する。 

− 外部認証機能−カード内の検証者は,カード外部の要求者を認証する。 

− 相互認証機能−両エンティティが相互に認証する。 

C.1.2 内部認証機能 

最初のデータフィールドが証拠情報要求,すなわち,空の証拠情報(ウィットネス)(“8000”)又は空

の認証コード(“8400”)のいずれかを伝える場合には,機能は内部認証とする。 

基本プロトコル(二つのC-RP) 

カードからの証拠情報 

コマンドデータフィールド 

{“7C”-“02”-{“80”-“00”}}  

レスポンスデータフィールド 

{“7C”-L1(=2+L2)-{“80”-L2-証拠情報}} 

カード外部からのチャレンジ及びカードからのレスポンス 

コマンドデータフィールド 

{“7C”-L1(=4+L2)-{“81”-L2-チャレンジ}-{“82”-“00”}} 

レスポンスデータフィールド 

{“7C”-L1(=2+L2)-{“82”-L2-レスポンス}} 

約束済み(コミティド)チャレンジ(二つのC-RP) 

カードからの証拠情報 

コマンドデータフィールド 

{“7C”-L1(=4+L2)-{“83”-L2-約束済み(committed)チャレンジ}-{“80”
-“00”}} 

レスポンスデータフィールド 

{“7C”-L1(=2+L2)-{“80”-L2-証拠情報}} 

注記 約束済みチャレンジは,チャレンジ及び証拠情報が独立して選ばれることを確実にする。 

カード外部からのチャレンジ及びカードからのレスポンス 

コマンドデータフィールド 

{“7C”-L1(=4+L2)-{“81”-L2-チャレンジ}-{“82”-“00”}} 

レスポンスデータフィールド 

− チャレンジが正しい場合,{“7C”-L1(=2+L2)-{“82”-L2-レ

スポンス}とする。 

− チャレンジが正しくない場合,存在しない。 

background image

147 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

データフィールド認証の拡張(二つのC-RP) 

カードは,既に交換されたデータフィールドをハッシュ処理する。結果は,最新のハッシュコードとな

る。カードは,認証コードを得るための証拠情報DOを含み,これをタグ“84”で伝える。 

カードからの証拠情報 

コマンドデータフィールド 

{“7C”-“02”-{“84”-“00”}} 

レスポンスデータフィールド 

{“7C”-L1(=2+L2)-{“84”-L2-認証コード}} 

カード外部からのチャレンジ及びカードからのレスポンス 

コマンドデータフィールド 

{“7C”-L1(=4+L2)-{“81”-L2-チャレンジ}-{“82”-“00”}} 

レスポンスデータフィールド 

{“7C”-L1(=2+L2)-{“82”-L2-レスポンス}} 

C.1.3 外部認証機能 

最初のデータフィールドがチャレンジ要求,すなわち,空のチャレンジ(“8100”)又は空の約束済みチ

ャレンジ(“8300”)のいずれかを伝える場合には,機能は,外部認証とする。 

基本プロトコル(二つのC-RP) 

カード外部からの証拠情報及びカードからのチャレンジ 

コマンドデータフィールド 

{“7C”-L1(=4+L2)-{“80”-L2-証拠情報}-{“81”-“00”}} 

レスポンスデータフィールド 

{“7C”-L1(=2+L2)-{“81”-L2-チャレンジ}} 

カード外部からのレスポンス及びカードによる検証 

コマンドデータフィールド 

{“7C”-L1(=2+L2)-{“82”-L2-レスポンス}} 

レスポンスデータフィールド 

存在しない。 

約束済みチャレンジ(三つのC-RP) 

カードからの約束済みチャレンジ 

コマンドデータフィールド 

{“7C”-“02”-{“83”-“00”}} 

レスポンスデータフィールド 

{“7C”-L1(=4+L2)-{“83”-L2-約束済みチャレンジ}-{“80”-“00”}} 

カード外部からの証拠情報及びカードからのチャレンジ 

コマンドデータフィールド 

{“7C”-L1(=4+L2)-{“80”-L2-証拠情報}-{“81”-“00”}} 

レスポンスデータフィールド 

{“7C”-L1(=2+L2)-{“81”-L2-チャレンジ}} 

カード外部からのレスポンス及びカードによる検証 

コマンドデータフィールド 

{“7C”-L1(=2+L2)-{“82”-L2-レスポンス}} 

レスポンスデータフィールド 

存在しない。 

データフィールド認証の拡張(二つのC-RP) 

要求者は,既に交換されたデータフィールドをハッシュ処理する。結果は,最新のハッシュコードとな

る。それは,認証コードを得るための証拠情報DOを含み,タグ“84”で伝える。 

background image

148 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

カード外部からの証拠情報及びカードからのチャレンジ 

コマンドデータフィールド 

{“7C”-L1(=4+L2)-{“84”-L2-認証コード}-{“81”-“00”}} 

レスポンスデータフィールド 

{“7C”-L1(=2+L2)-{“81”-L2-チャレンジ}} 

カード外部からのレスポンス及びカードによる検証 

コマンドデータフィールド 

{“7C”-L1(=2+L2)-{“82”-L2-レスポンス}} 

レスポンスデータフィールド 

存在しない。 

C.1.4 相互認証機能 

最初のデータフィールドが空でないDOを伝える場合には,その機能は,相互認証とする。すなわち,

カード外部は,コマンドデータフィールド内のDOと同じDOをレスポンスデータフィールド内で要求す

る。 

基本プロトコル(三つのC-RP) 

証拠情報 

コマンドデータフィールド 

{“7C”-L1(=2+L2)-{“81”-L2-証拠情報}} 

レスポンスデータフィールド 

{“7C”-L1(=2+L2)-{“81”-L2-証拠情報}} 

チャレンジ 

コマンドデータフィールド 

{“7C”-L1(=2+L2)-{“81”-L2-チャレンジ}} 

レスポンスデータフィールド 

{“7C”-L1(=2+L2)-{“81”-L2-チャレンジ}} 

レスポンス 

コマンドデータフィールド 

{“7C”-L1(=2+L2)-{“82”-L2-レスポンス}} 

レスポンスデータフィールド 

− レスポンスが正しい場合,{“7C”-L1(=2+L2)-{“82”-L2-レ

スポンス}}とする。 

− レスポンスが正しくない場合,存在しない。 

約束済みチャレンジ(四つのC-RP) 

約束済みチャレンジ 

コマンドデータフィールド 

{“7C”-L1(=2+L2)-{“83”-L2-約束済みチャレンジ}} 

レスポンスデータフィールド 

{“7C”-L1(=2+L2)-{“83”-L2-約束済みチャレンジ}} 

証拠情報 

コマンドデータフィールド 

{“7C”-L1(=2+L2)-{“80”-L2-証拠情報}} 

レスポンスデータフィールド 

{“7C”-L1(=2+L2)-{“80”-L2-証拠情報}} 

チャレンジ 

コマンドデータフィールド 

{“7C”-L1(=2+L2)-{“81”-L2- チャレンジ}} 

レスポンスデータフィールド 

− レスポンスが正しい場合,{“7C”-L1(=2+L2)-{“81”-L2-チ

ャレンジ}}とする。 

− レスポンスが正しくない場合,存在しない。 

background image

149 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

レスポンス 

コマンドデータフィールド 

{“7C”-L1(=2+L2)-{“82”-L2-レスポンス}} 

レスポンスデータフィールド 

− レスポンスが正しい場合,{“7C”-L1(=2+L2)-{“82”-L2-レ

スポンス}}とする。 

− レスポンスが正しくない場合,存在しない。 

鍵共有の拡張(四つのC-RP) 

一組の指数関数的なデータ要素は,セション鍵を共有できるようにする(JIS X 5058規格群及びISO/IEC 

11770規格群 [17] 参照)。 

最初のC-RPは,“指数関数的な”データ要素を入れ子にする動的認証テンプレートを交換する。例では,

以前にセション間でメッセージを交換していないため,初期のハッシュコードは,ゼロブロックとする。

次に,コマンドデータフィールド,すなわち,最初の動的認証テンプレートは,カレントのハッシュコー

ドを得るために含まれる。次に,レスポンスデータフィールド,すなわち,2番目の動的認証テンプレー

トは,カレントのハッシュコードを更新するために含まれる。カレントのハッシュコードは,両方のエン

ティティに対し同じであることが望ましい。最終的に,ゼロでなくカード外部に伝えられない,各エンテ

ィティにおいて異なる証拠情報DOは,各エンティティにおいて異なる認証コードを得るために含まれる。 

2番目のC-RPは,タグ“84”で認証コードを入れ子にする動的認証テンプレートを交換する。 

指数関数的な値 

コマンドデータフィールド 

{“7C”-L1(=2+L2)-{“85”-L2-指数関数的な値}} 

レスポンスデータフィールド 

{“7C”-L1(=2+L2)-{“85”-L2-指数関数的な値}} 

証拠情報 

コマンドデータフィールド 

{“7C”-L1(=2+L2)-{“84”-L2-認証コード}} 

レスポンスデータフィールド 

{“7C”-L1(=2+L2)-{“84”-L2-認証コード}} 

チャレンジ 

コマンドデータフィールド 

{“7C”-L1(=2+L2)-{“81”-L2-チャレンジ}} 

レスポンスデータフィールド 

{“7C”-L1(=2+L2)-{“81”-L2-チャレンジ}} 

レスポンス 

コマンドデータフィールド 

{“7C”-L1(=2+L2)-{“82”-L2-レスポンス}} 

レスポンスデータフィールド 

− レスポンスが正しい場合,{“7C”-L1(=2+L2)-{“82”-L2-レ

スポンス}}とする。 

− レスポンスが正しくない場合,存在しない。 

C.2 多段階認証プロトコルのためのGENERAL AUTHENTICATE 

C.2.1 一般 

ここでは,多段階認証プロトコルのためのGENERAL AUTHENTICATEコマンドの使用法について記載

する。すなわち,EN 14890-1に記載している認証体系PACE v2に基づいたパスワードである。 

そのために,多段階認証プロトコルは,幾つかの認証処理[一つ以上のGENERAL AUTHENTICATEコ

background image

150 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

マンドによる鍵共有[PERFORM KEY AGREEMENT (PKA)]処理]を含む。鍵共有処理は,例えば,パス

ワード認証だけによるICCとカードの外部世界との間のセキュアチャネルを確立するときのように,カー

ド中の鍵パラメタ及び/又はディフィーヘルマン鍵対について,生成を開始し,管理し,及び/又は使用

する。 

PKA処理を用いる特定のプロトコルによれば,次のために一つ以上のPKA処理を用いる。 

− 一時的な暗号化,及び/又は写像 

− 鍵共有のための非対称のディフィーヘルマン(DH)鍵対の生成 

− 非対称のDH鍵対,及び/又は前にカード中で生成された鍵パラメタに,事前アクセス 

− カード中と同じグローバルなパラメタに基づいた接続装置(IFD)からのDH公開鍵を格納 

− 鍵共有を処理 

− 例えば,セキュアメッセージングに使用するために,カード中の各々の暫時の鍵を提供 

一つ以上のMANAGE SECURITY ENVIRONMENTコマンド処理は,鍵生成に関係したパラメタと同様

に各々のオブジェクト識別子を設定するために鍵共有処理に先行する。例えば,鍵生成に関係したパラメ

タは,拡張アクセス制御(EAC),簡易パスワード認証指数鍵交換(SPEKE),EN 14890-1 [1] によるPACE v2

で使用するプロトコル及び変化したプロトコルに従ったCRT AT中のアルゴリズム参照である。 

注記 10.3.2で定義するとおり,制御参照テンプレート中で,DO“80”は暗号機構参照を転送するた

めに使用する。C.2.2の段階1及びC.2.3の段階3で,意図的に,暗号機構参照は,暗黙のタグ

付けによって認証プロトコルについて記述するオブジェクト識別子の値と同一のものが選ばれ

る。 

一つ以上のGENERAL AUTHENTICATE C-RPは,認証処理を実装する。 

− 連鎖が使用される場合は,5.3.3を参照。 

− INS P1 P2は,“86 00 00”又は“87 00 00”のいずれかに設定する。 

− Lcフィールドの値は,コマンドデータフィールドのDOに依存する。レスポンスデータフィールドを

期待するかどうかによって,Leフィールドは,“00”と設定するか又は存在しない。 

C.2.2 偶数INSバイト(“86”)の一般認証の使用,パスワードベースプロトコルPACE v2の例 

段階1 

SET SE 環境(CRT AT) 

コマンドデータフィールド 

{“80”- L - 特定の暗号化アルゴリズム(例えば,TDES又はAES)及び一時的
情報の写像[ジェネリックマッピング(generic mapping)又はインテグレーテッ
ドマッピング(integrated mapping)]を備えた一般的な写像に対するオブジェク
ト識別子の値} 
{“83”- L - パスワード参照} 
{“84”- 暫時のプライベート鍵(セッション鍵)の領域パラメタの参照} 

レスポンスデータフィールド 

{} ‒ 存在しない。 

段階2 

暗号化された一時的情報を得る。 

コマンドデータフィールド 

“7C”‒ L=0 

レスポンスデータフィールド 

{{“7C”‒ L2 ‒ {“80”‒ L‒ anywhere nonce)} 

段階3 

写像一時的情報[例えば,ディフィーヘルマン鍵交換(ジェネリックマッピング)
又はポイント(インテグレーテッドマッピング)へのECの特定の写像] 

コマンドデータフィールド 

{“7C”‒ L2 ‒ {“81”‒ L ‒ 写像データ)} 

レスポンスデータフィールド 

{“7C”‒ L2 ‒ {“82”‒ L ‒ 写像データ)}(ジェネリックマッピング)又は {} ‒ 存在
しない(インテグレーテッドマッピング)。 

background image

151 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

段階4 

鍵共有の実施(PKA) 

コマンドデータフィールド 

{“7C”‒ L2 ‒ {“83”‒ L ‒暫時公開鍵)} 

レスポンスデータフィールド 

{“7C”‒ L2 ‒ {“84”‒ L ‒暫時公開鍵)} 

段階5 

相互認証 

コマンドデータフィールド 

{“7C”‒ L2 ‒ {“85”‒ L ‒ 認証トークン)} 

レスポンスデータフィールド 

{“7C”‒ L2 ‒ {“86”‒ L ‒ 認証トークン}} 

C.2.3 偶数INSバイト(“86”)の一般認証の使用,拡張アクセスコントロール(EAC) 

EACのプロトコルは,二つの部分に分かれている。端末認証(TA)は,接続装置又はリモートサーバの

認証を可能にし,チップ認証(CA)は,カードの同一性を証明する。EN 14890-1 [1] に従って,二つのバ

ージョンを識別する。 

− EACv1は,シーケンスCA-TAに言及する。 

− EACv2は,シーケンスTA-CAに言及する。 

端末認証プロトコルは,最初にカードが証明可能な証明書を用いてカードの中に接続装置の公開鍵をも

ち込む。第2段階で,チャレンジレスポンスプロトコルが行われる。チップ認証プロトコルは,セキュア

チャネルを行うディフィーヘルマン鍵交換を規定する。 

NA.1.1 端末認証プロトコル 

段階1 

SET SE環境(CRT DST) 

コマンドデータフィールド 

{“83”‒ L ‒ 公開鍵参照 

レスポンスデータフィールド 

{} ‒ 存在しない。 

段階2 

PERFORM SECURITY OPERATION(VERIFY CERTIFICATE) 

コマンドデータフィールド 

{“7F4E”‒ L ‒ JIS X 6320-8の中で定義された証明書構造} 
{“5F37”‒ L ‒ ディジタル署名} 

レスポンスデータフィールド 

{} ‒ 存在しない。 

各々の認証機関の公開鍵が,証明書を発行し接続装置の公開鍵を伝えるカードにおいて利用可能である

間,証明書連鎖に沿った証明書の検証は継続してもよい。EACプロトコル群は,3レベルのPKIを規定す

る。その結果,二つの後続する証明書の検証が必要になる。 

段階3 

SET SE環境(CRT AT) 

コマンドデータフィールド 

{“80”‒ L ‒ オブジェクト識別子の値} 
{“83”‒ L ‒ 公開鍵参照} 
{“91”‒ L ‒ CAのためのIFDの暫時公開鍵} 

EACv2.0だけ 
 
EACv2.0だけ 

レスポンスデータフィールド 

{} ‒存在しない。 

段階4 

GET CHALLENGE 

コマンドデータフィールド  

{} ‒ 存在しない。 

レスポンスデータフィールド 

{任意のデータ} 

段階5 

EXTERNAL AUTHENTICATE 

コマンドデータフィールド 

{レスポンスデータ ‒ ランダムな認証データに署名するディジタル署名} 

レスポンスデータフィールド 

{} ‒存在しない。 

background image

152 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

NA.1.2 チップ認証プロトコル 

段階1 2) 

SET SE環境(CRT AT) 

コマンドデータフィールド 

{“80”‒ L ‒ オブジェクト識別子の値} 
{“84”‒ L ‒パブリック鍵参照} 

レスポンスデータフィールド 

{} ‒存在しない。 

段階2 

GENERAL AUTHENTICATE。“鍵共有の実行(PKA)”を意図する。 

コマンドデータフィールド 

{“7C”‒ L2 ‒ {“80”‒ L ‒ IFDの暫時公開鍵}} 

レスポンスデータフィールド 

{“7C”‒ L2 ‒ {“81”‒ L ‒任意のデータ} ‒ 
{“82”‒ L ‒ 認証トークン}}  

EAC v2だけ 

注2) TDESのEACv1については,次のコマンドだけを,段階1で使用している。この場合,段階2

は省略する。 

段階1 

SET SE環境(CRT KAT) 

コマンドデータフィールド 

{“91”‒ L ‒ IFDの暫時公開鍵} 
{“84”‒ L ‒ パブリック鍵参照} 

EACv1 TDESの場合だけ 
EACv1 TDESの場合だけ 

レスポンスデータフィールド 

{} ‒ 存在しない。 

background image

153 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

附属書D 
(参考) 

発行者識別番号を使用するアプリケーション識別子 

D.1 背景情報 

ISO/IEC 7816-5:1994では,アプリケーション識別子に発行者識別番号の使用を可能とした。この附属書

は,そのようなAIDの書式を示す。 

注記 ISO/IEC 7816-5の最新版は,2004年に発行された第2版であるが,ISO/IEC 7816規格群の見

直しの中で,アプリケーション識別子の構造(12.2.3参照)については,ICカードの主な機能

の一つとしてISO/IEC 7816-4に集約され,第2版からは削除されている。 

D.2 書式 

先頭バイトのビットb8〜b5が“0”〜“9”に設定される全てのAIDでは,ISO/IEC 7812-1 [5] に従って,

先頭フィールドを発行者識別番号とする。 

注記 ISO/IEC 7812-1:1993では,発行者識別番号は,“0”〜“9”の値をもつ奇数個のカルテット(4

ビットデータ)から構成してもよいとしていた。そして,最後のバイトのビットb4〜b1を1111

に設定することによって,バイト列として表していた。 

個別利用アプリケーション識別子拡張子が存在している場合には,“FF”に設定された1バイトが,二

つのフィールドを分離する。 

図D.1は,発行者識別番号を使用するAIDを示す。最大16バイトから構成される。 

ISO/IEC 7812-1 [5] による発行者識別番号 

(2バイト以上) 

“FF” 

個別利用アプリケーション拡張識別子 

(PIX) 

図D.1−発行者識別番号を使用するAID 

background image

154 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

附属書E 

(参考) 

BER符号化規則 

E.1 

BER-TLVタグフィールド 

タグフィールドの先頭バイトのビットb8及びb7は,クラスを示す(ISO/IEC 8825-1参照)。 

− 値00は,普遍的クラスのDOを示す。 

− 値01は,アプリケーションクラスのDOを示す。 

− 値10は,状況依存クラスのDOを示す。 

− 値11は,私的クラスのDOを示す。 

タグフィールドの先頭バイトのビットb6は,符号化を示す(E.3参照)。 

タグフィールドの先頭バイトのビットb5〜b1全てが1に設定されない場合には,0〜30のタグ番号を符

号化し,タグフィールドは,1バイトで構成する。タグ番号0は普遍的クラスでは除外される。 

ビットb5〜b1全てが1に設定される場合には,タグフィールドは,1バイト以上とする。 

− タグフィールドの最終バイト以外は,第2バイト以降の各バイトのビットb8を1に設定する。 

− タグフィールドの第2バイトのビットb7〜b1は,全てを0に設定してはならない。 

− タグフィールドの第2バイト以降の各バイトは,ビットb7〜b1によってタグ値を符号化する。 

表E.1はタグフィールドの先頭バイトを示す。値“00”は無効とする。 

表E.1−JIS X 6320規格群 [6] のBER-TLVタグフィールドの先頭バイト 

b8 b7 b6 b5 b4 b3 b2 b1 

意味 

− − − − − − 普遍的クラス,JIS X 6320規格群 [6] で定義しない。 

− − − − − − アプリケーションクラス,この規格で定義する識別 

− − − − − − 状況依存クラス,JIS X 6320規格群 [6] で定義する。 

− − − − − − 私的クラス,JIS X 6320規格群 [6] で定義しない。 

− − 

− − − − − 基本符号化 

− − 

− − − − − 構造化符号化 

− − − 

全てが1でない。 

0〜30のタグ番号(短いタグフィールド,すなわち,1バイト) 

− − − 

30を超えるタグ番号(長いタグフィールド,すなわち,2又は3バイト) 

2バイト以上のタグフィールドにおいて,第2バイトの値“00”〜“1E”及び“80”は,無効とする。 

− 2バイトのタグフィールドでは,第2バイトは,ビットb8を0に設定し,ビットb7〜b1を31以上の

数字で符号化する。第2バイトは,(31〜127のタグ値を符号化する)“1F”〜“7F”の値とする。 

− 3バイトのタグフィールドでは,第2バイトは,ビットb8を1に設定し,ビットb7〜b1を全てが0

でない値に設定する。第2バイトは,“81”〜“FF”の値で及び第3バイトの“00”〜“7F”の値とする。

タグ値128〜16 383を符号化する。 

注記 普遍的クラスのタグは,ISO/IEC 8824-1の表1に定義されている。 

E.2 

BER-TLV長さフィールド 

短縮書式(長さフィールドは1バイトで構成)の場合は,ビットb8を0に設定し,ビットb7〜b1に値

フィールドのバイト数を符号化する。1バイトは,このように0〜127の数を符号化することができる。 

background image

155 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

注記 1バイトのBER-TLV長さフィールドにおいて,1〜127の数は,Lcフィールド及びLeフィール

ドと同じ方法で符号化するが,0及び128以上の符号化方法は異なる。11.4.3のGET DATAコ

マンドのDO符号化の例を参照。 

短縮でない書式(長さフィールドは,2バイト以上で構成)の場合,先頭バイトのビットb8を1に設定

し,ビットb7〜b1で示される値(全てのビットが,同じでない値)で,長さフィールド内の後続バイト数

を符号化する。長さフィールドの第2バイト以降は,値フィールドのバイト数を符号化する。 

JIS X 6320規格群 [6] は,1,2,…5バイトまでの長さフィールドを提供する(表E.2参照)。JIS X 6320

規格群 [6] では,長さフィールドの先頭バイトの値“80”及び“85”〜“FF”を無効とする。 

表E.2−JIS X 6320規格群 [6] のBER-TLV長さフィールド 

構成バイト数 

1バイト目 

2バイト目 

3バイト目 

4バイト目 

5バイト目 

1バイト 

“00”〜“7F” 

− 

− 

− 

− 

0〜127 

2バイト 

“81” 

“00”〜“FF” 

− 

− 

− 

0〜255 

3バイト 

“82” 

“0000”〜“FFFF” 

− 

− 

0〜65 535 

4バイト 

“83” 

“000000”〜“FFFFFF” 

− 

0〜16 777 215 

5バイト 

“84” 

“00000000”〜“FFFFFFFF” 

0〜4 294 967 295 

E.3 

BER-TLV値フィールド 

タグフィールドの先頭バイトのビットb6は,値フィールドの符号化を示す。 

− 値0は,DOの基本符号化を示す。すなわち,値フィールドがBER-TLVで符号化されたとしても,値

フィールドの符号化に関する情報は提供されない(値フィールドは,BER-TLVで符号化しない。)。 

− 値1は,DOの構造化符号化を示す。すなわち,存在する場合,値フィールドは,BER-TLVで符号化

する。空でない値フィールドは,一つのDO,又はパディングのないDOの連結とする。 

background image

156 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

附属書F 

(参考) 

BER-TLVデータオブジェクトの扱い 

F.1 

構造化DO中の世代及びテンプレート 

ルートDO(仮想) 

第0次世代DO 

第一世代DO 

第二世代DO 

第三世代DO 

第四世代DO 

“7F70”L 

値= 

T1 L1 

値1= 

T2 L2 

V2 

T3 L3 

値3= 

T4 L4 

V4 

T6 L6 

V6 

T5 L5 

値5= 

T8 L8 

V8 

T8 L8' 

V8' 

T8 V8" 

V8" 

T2 L2' 

V2' 

T14 L14 

V14 

T9 L9 

値9= 

T4 L4' 

V4' 

T6 L6" 

V6" 

T6 L6' 

V6' 

図F.1−構造化DO中の世代,DO及びテンプレート 

図F.1の各横線には,一つのDOが存在している。DOは,同じ横線の二つの連続したセルを使用してい

る。左側のセルは,DOヘッダ(タグ,長さ)とし,右側のセルは,値フィールドとする。 

最も左側の太い垂直線は,ファイル選択後,又は仮想DO“7F70”選択後のカレントテンプレートを示

している。テンプレートは,(太い実線の右側にすぐ現れる)DO“T1”及び“T6”を含んでいる。Tn Ln

の組合せは,太い点線の右側にすぐには現れない。この点線は,テンプレートが完成していない部分を示

している。 

この点線の境界線に属するDOは,他の構造化DOに入れ子にされているので,構造(ファイル,レコ

ード,又はデータ列)に属するが,カレントテンプレートに属していない。すなわち,第一世代に属して

いない。 

DO“T1”の選択後,カレントテンプレートは,値1のセルのすぐ右側を始めとした太線で示される。

このセルは,この値フィールドが,DO“T1”の選択後にカレントテンプレートを構成するテンプレート

(すなわち,構造化DO“T1”に入れ子にされたDOの連結)であることを示す太い境界線によって縁ど

られている。このテンプレートは,五つの第二世代DO,DO“T2”,“T3”,“T2”,“T14”,“T9”で構成し

ている。このテンプレートにも,太い点線部分が存在する。この点線の境界線に属するDOは,DO“T1”

に属するが,他の構造化DOに入れ子にされているので,DO“T1”選択後のカレントテンプレートに属し

ていない。すなわち,第二世代に属していない。 

同じタグ値をもつが,長さと値フィールドとが異なる可能性がある二つのDO“T2”が,存在する。二

background image

157 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

つ存在することは許容されているが,これらのDOを扱うときは,テンプレート内の順序に従ってDOを

扱わなければならない。二つの同じタグ値のDOが同じテンプレートに属しているとき,参照するタグの

一貫した扱いによって,二つの同じタグ値は,同じ意味で使用する。 

DO“T3”選択後,カレントテンプレートは,太い線で示される。このテンプレートは,三つの第三世

代DO,DO“T4”,“T6”,“T5”で構成している。 

DO“T9”選択後,カレントテンプレートは,二つの第三世代DO,DO“T4”,“T6”で構成している。

これらは,DO“T3”選択後のカレントテンプレート(異なったテンプレート)と同じ世代である。第三

世代には,二つのDO“T6”が存在しているが,これらは異なったテンプレートに属しており,二つのDO

“T6”は,このことによって,(例えば,タグ“T6”の類から)他の情報が得られる場合を除いて,異な

った意味をもっていてもよい。 

F.2 

拡張ヘッダによる参照 

この細分箇条で示す例の全ては,全ての図から削除された二つの最左端の欄と同じバイト列をもたらす。

この細分箇条名は,“拡張ヘッダリストによる参照”とする。これは,対象DOと拡張ヘッダの最初のヘッ

ダとが一致しなければならないことを強調している。すなわち,空でないバイト列を参照するために,同

じタグをもっている。 

“A1 37” 

値1= 

“82 03” 

“21 22 23” 

“A3 1C” 

値3= 

“84 04” “40 41 42 43” 

“86 02” 

“61 62” 

“A5 10” 

値5= 

“88 03” 

“81 82 83” 

“88 03” 

“84 85 86” 

“88 04” “87 88 89 8A” 

“82 04” “24 25 26 27” 

“8E 03” 

“E0 E1 E2” 

“A3 07” 

値3'= 

“84 01” 

“46” 

“86 02” 

“63 64” 

図F.2−この細分箇条の全拡張ヘッダ展開時の対象DO 

“A1 0C” 

値1= 

“A3 06” 

値3= 

“A5 04” 

値5= 

“88 00” 

“88 02” 

“8E 00” 

“A3 80” 

図F.3−基本DOの割愛されない一致を含む拡張ヘッダデータ要素1 

background image

158 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

“A1 1B” 

値1= 

“A3 0B” 

値3= 

“A5 09” 

値5= 

“88 03” “81 82 83” 

“88 02” 

“84 85” 

“8E 03” “E0 E1 E2” 

“A3 07” 

値3'= 

“84 01” 

“46” 

“86 02” “63 64” 

図F.4−拡張ヘッダデータ要素1をDO“A1”に適用した結果のサブツリー 

図F.4は,図F.2の最初の二つのDO“88”が,図F.3のDO“88”と一致したことを示す。拡張ヘッダ

がタグ“4D”配下にある場合,1番目を含まずに2番目のDO“88”を含むことはできない。2番目の基本

DO“88”の値フィールドは,図F.3の“88 02”によって短縮されている。参照するバイト列は,次のいず

れかとする。 

− データオブジェクトフォーマット 

{88 03 81 82 83}{88 02 84 85}{8E 03 E0 E1 E2}{A3 07{84 01 46}{86 02 63 64}} 

− データ要素フォーマット 

“81 82 83 84 85 E0 E1 E2”{84 01 46}{86 02 63 64} 

図F.5は,2番目のDO“A3”だけを含む場合を示す。 

“A1 04” 

値1= 

“8E 00” 

“A3 80” 

図F.5−構造化DO上の一致を暗黙的に除外した拡張ヘッダデータ要素2 

“A1 0E” 

値1= 

“8E 03” “E0 E1 E2” 

“A3 07” 

値3= 

“84 01” 

“46” 

“86 02” “63 64” 

図F.6−拡張ヘッダデータ要素2をDO“A1”に適用した結果のサブツリー 

8.4.7に従い,参照する最初のDOがDO“8E”であるため,図F.2においてそれよりも前にあるDOへ

の参照が除外されるので,最初のDO“A3”は参照されない。図F.7は,図F.5の拡張ヘッダと同じ結果が

得られる拡張ヘッダを示している。 

“A1 06” 

値1= 

“A3 00” 

“8E 00” 

“A3 80” 

図F.7−拡張ヘッダデータ要素2と等価の冗長な符号化 

図F.5,図F.6,及び図F.7で示されるケースでは,参照するバイト列は,次のいずれかとする。 

background image

159 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

− データオブジェクトフォーマット 

{8E 03 E0 E1 E2} {A3 07{84 01 46}{86 02 63 64}} 

− データ要素フォーマット 

“E0 E1 E2”{84 01 46} {86 02 63 64} 

“A1 04” 

値1= 

“A3 00” 

“A3 80” 

図F.8−構造化DO上の割愛される一致を含む拡張ヘッダデータ要素3 

“A1 09” 

値1= 

“A3 07” 

値3'= 

“84 01” 

“46” 

“86 02” “63 64” 

図F.9−拡張ヘッダデータ要素3をDO“A1”に適用した結果のサブツリー 

図F.8及び図F.9によって示されたケースでは,二つのDO“A3”との間で一致が現れないかもしれない

ため,1番目のDO“A3”との突合せを割愛するという指示が必要となる,参照するバイト列は,次のい

ずれかとする。 

− データオブジェクトフォーマット 

{A3 07{84 01 46} {86 02 63 64}} 

− データ要素フォーマット 

{84 01 46} {86 02 63 64} 

“A1 08” 

値1= 

“A3 06” 

値3= 

“A5 04” 

値5= 

“88 00” 

“88 80” 

図F.10−基本DO上の割愛された一致を含む拡張ヘッダデータ要素4 

“A1 09” 

値1= 

“A3 07” 

値3= 

“A5 05” 

値5= 

“88 03” “84 85 86”

図F.11−拡張ヘッダデータ要素4をDO“A1”に適用した結果のサブツリー 

図F.10及び図F.11のケースでは,2番目のDO“88”だけが一致したことを示す。拡張ヘッダデータ要

素4の構文は,タグ“4D”配下ではあり得ない。参照するバイト列は,次のいずれかとする。 

− データオブジェクトフォーマット 

{88 03 84 85 86}。拡張ヘッダは,タグ“5F 61”を用いる。 

− データ要素フォーマット 

“84 85 86”。拡張ヘッダは,タグ“5F 60”を用いる。 

background image

160 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

F.3 

UPDATE DATAコマンドの使用 

この例は,DO“B1”がVA内に一つしか存在しないものと仮定している。二つ以上のDO“B1”が存在

している場合,それらのうちの一つの更新は,次のいずれかで実行できる。 

− SELECT DATA C-RPによって,いずれかのDO“B1”を選択して,次世代中のDOを更新する。 

− 一つ以上のGET NEXT DATA C-RPでこのDO“B1”にポインタを設定して,次世代中のDOを更新す

る。 

図F.12は,UPDATE DATA C-RPによって更新される前のDO“B1”を示す。そのツリー構造は,次の構

成である。 

基本DO“82”(第二世代),及び構造化DO“B2”(第二世代)。 

構造化DO“B2”(第二世代)は,二つの基本DO“90”及び“91”(第三世代)並びに一つの構造

化DO“B3”(第三世代)を入れ子にする。 

構造化DO“B3”(第三世代)は,二つの基本DO“84”及び“86”(第四世代)を入れ子にする。 

“B1 1C” 

値1= 

“82 04” “21 22 23 24”24'V2 

“B2 14” 

値2= 

“90 03”  “01 02 03” 

“91 04” “11 12 13 14” 

“B3 07” 

値3= 

“84 01” 

“46” 

“86 02” “63 64” 

図F.12−更新前のDO“B1” 

図F.13は,UPDATE DATAコマンドの引き数(DO“B1”を基底とするDO)を示す。それは,サブツリ

ーで,更新前のDO“B1”に対して, 

− 複数の分岐(DO)が存在していてもよいが,それらは更新される。 

− あるDOは欠けていてもよいが,それらは更新されない。したがって,更新前のDO“B1”の内容が

保たれる。 

− あるDOは加えられてもよいが,それらは新設される。 

“B1 10” 

値1'= 

“B2 09” 

値2'= 

“B3 07” 

値3'= 

“84 00” 

“86 04” “65 66 67 68” 

“8E 03” “E1E2E3”

図F.13−UPDATE DATAコマンドの引き数 

図F.14は,UPDATE DATA C-RPの成功後のDO“B1”の内容を示す。 

第二世代では,DO“82”は影響を受けず,DO“B2”は更新され,DO“8E”が新設される。 

第三世代では,基本DO“90”及び“91”は影響を受けず,DO“B3”は更新される。 

第四世代では,基本DO“84”は,空になり,DO“86”は更新される。コマンドで伝えられたDO

“86”の新しい値(図F.13参照)は,前の値(図F.12参照)を置換する。 

background image

161 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

“B1 22” 

値1"= 

“82 04” “2122 23 24” 

“B2 15” 

値2"= 

“90 03” 

“01 02 03” 

“91 04” “11 12 13 14” 

“B3 08” 

値3"= 

“84 00” 

“86 04” “65 66 67 68” 

“8E 03” “E1 E2 E3” 

図F.14−変更又は追加されたDOを太文字で示した更新後のDO“B1” 

F.4 

一つのDOのセキュリティ属性 

“UV”L 

値 

// 構造化DO 

 “XY”L1 

V1 

// DO'UV'配下のDO 

“62”L2 

値2 

// データ制御パラメタDO  

“A0”L3 

値3 

// DOのセキュリティ属性 

“9C”L4 

V4 

//セキュリティテンプレート#1を 

参照しているセキュリティ属性 

“5C01” “XY” 

// DO“XY”を参照しているタグリスト 

 “AD”L5 

値5 

//セキュリティパラメタテンプレート 

“80 01” “01” //セキュリティパラメタテンプレート番号 

“A1”L6 

値6 

//保護は,プライベート鍵に使用する 

“63”L7 

値7 

//鍵を参照しているラッパ 

図F.15−DO“XY”のカレントテンプレート及びそのセキュリティ属性 

(一般的なレイアウト) 

図F.15は,DO“UV”に入れ子にされたDO“XY”のセキュリティ属性の符号化を例示している。セキ

ュリティ属性DO“A0”は,制御パラメタDO“62”に入れ子にされている。また,DO“62”は,セキュ

リティパラメタテンプレートDO“AD”を入れ子にしている。DO“62”は,この例で無関係であるため

に図に表さなかった他のCP DOを含んでもよい。 

セキュリティ属性DO“A0”に入れ子にされたタグリストで与えられたタグは,重要で,DO“UV”配

下のDO,いい換えればDO“UV”が選択された場合の第一世代のDO(DO“XY”)を指している。番号

によって参照されるDO“AD”は,DO“UV”配下のDO“62”配下に存在しなければならない。 

background image

162 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

F.5 

自己制御DO内の鍵参照の例 

第一 第二 第三 第四 

<世代 

62 

制御パラメタテンプレート 

A0 

DOのセキュリティ属性テンプレート 

90 

AMF||SCB(ref#1)||SCB(ref#2)||SCB(ref#3) 

拡張形式を使用する場合,タグ“AB”配下
で,タグ“9D”もここで使用することがで
きる。 

5C 

タグリスト,内容はこの表の中では詳述しない。 

73 

BER-TLVの中で符号化された個別利用情報 

AC 

暗号メカニズム識別子テンプレート 

8A 

LCS(ライフサイクル状態) 

AD 

上記で参照しているセキュリティパラメタテンプレート#1 

06 

例えば,アルゴリズ及び個別利用情報の使用の記述を指すOID 

80 

値=“01”,DO“AD”の連続番号 

A0 

認証オブジェクト用のセキュリティ属性拡張 

8C 

SEを参照しているコンパクト形式のセキュリティ属性 

いずれか
を選択す
る。 

AB SPTを参照している拡張形式のセキュリティ属性 

9C 

SPTを参照しているコンパクト形式のセキュリティ属性 

5C 

タグリスト。内容はこの表の中では詳述しない。 

AD 

セキュリティパラメタテンプレート。内容はこの表の中では詳述しない。 

… 

この表の中では詳述しない他のDO,第三世代 

B3 

BER-TLVの中で符号化されたOID関連の情報 

63 

ラッパ。内容はこの表の中では詳述しない。 

AD 

上記で参照しているセキュリティパラメタテンプレート#2 

80 

値=“02”,DO“AD”の連続番号 

A4 

秘密鍵用のセキュリティ属性拡張 

“IJ”コンパクト(“IJ”=“8C”)又は拡張(“IJ”=“AB”)形式中のSEを参照するセキュリテ

ィ属性 

63 

ラッパ。内容はこの表の中では詳述しない。 

AD 

上記で参照しているセキュリティパラメタテンプレート#3 

06 

例えば,アルゴリズム及び個別利用情報の使用の記述を指すOID 

80 

値=“03”,DO“AD”の連続番号 

A1 

プライベート鍵用のセキュリティ属性拡張 

“ZT”コンパクト(“ZT”=“90”)又は拡張(“ZT”=“AB”)形式中のセキュリティ属性 

63 

ラッパ。内容はこの表の中では詳述しない。 

73 

BER-TLVの中で符号化されたOID関連の情報 

図F.16−3個の鍵を参照するセキュリティ属性を備えた自己制御DO“XY”の値 

注記1 図F.16は,長さはささいな情報であるので,DOの長さフィールドを示していない。太線の

左側は,構造化DOのタグを示し,右側は,その中に入れ子にされたDO群のタグ群を示す。 

図F.16は,DO“XY”内のセキュリティ属性の符号化を例示している。セキュリティ属性DO“A0”は,

制御パラメタDO“62”に入れ子にされ,また,三つのセキュリティパラメタテンプレートDO“AD”を

入れ子にしている。DO“XY”及びDO“62”は,この例で無関係であるために図に表さなかった他のCP 

DOを含んでもよい。 

セキュリティ属性DO“A0”に入れ子にされた空でないタグリスト(“5C”)で与えられたタグは,重要

で,DO“XY”配下のDO,いい換えれば,第一世代のDO(この図では省略しているDO)を指している。

セキュリティパラメタテンプレートDO“AD”は,DO“AD”を参照するセキュリティ属性DO“A0”と

163 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

同じ世代に属している。 

注記2 セキュリティ属性DO“A0”は,DO“62”に入れ子にされている。セキュリティ属性拡張

DO“A0”は,DO“AD”に入れ子にされている。それらの構文は,異なっている。 

background image

164 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

附属書G 
(参考) 

タグ付ラッパによるテンプレート拡張 

G.1 

共通事項 

タグ付ラッパによる拡張は,カードが,特定のVA中で,実際のVAに属さない一つ以上の“遠方のDO”

を模倣することを可能にする(8.2.2,8.4.8及び8.4.9参照)。セキュリティ状態は,GET DATA C-RPで“遠

方のDO”を読むことを許可していると仮定する。図G.1は,(例えば,PUT DATAコマンドによって)基

礎テンプレート内に生成されたタグ付ラッパ,及びテンプレート拡張中のこのタグ付ラッパの結果を示す。

タグだけで示す。 

第n世代 

第n+一世代 

意味 

“63” 

基礎テンプレート中のタグ付ラッパ 

“XY”(空) 

タグ“XY”によって局所的に参照されるDO 

“5C”又は“4D”一時的VA中のDO“ZT”への間接参照。次の1)参照。 

“4F” 

一時的VA中のcurDF参照 

タグ付ラッパの自動解決は,DO“ZT”の参照が有効で
ある一時的VAを設定するこれらのDOを使用する。次
の2)及び3)参照。 

“51” 

一時的VA中のcurEF参照 

“XY” 

テンプレート拡張中のDO“ZT”の模倣 

図G.1−タグ付ラッパの構文及び結果 

1) 他のタグは,DOを参照するために利用可能(8.4.8参照)。 

2) 一時的なVAを設定するための他の手段がある(8.4.8参照)。 

3) 一時的なVAの要素がカレントVAに属するとき,タグ付ラッパ中でそれらを繰り返す必要性はなく,

それらが両方とも存在しないとき,それらを確認する必要は全くない(以降の箇条を参照)。 

G.2 

カレントEF内の参照 

次の例は,アプリケーションDF“A0 01 02 03 04”(アプリケーション識別子)配下のカレントEF“1234”

(ファイル識別子)の内容を示す。この図G.2は,タグ及び長さフィールドを16進数で符号化している。

タグ付ラッパの値フィールド以外,基本DOの値フィールドは重要ではない。 

background image

165 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

第一世代 

第二世代 

第三世代 

第四世代 

第五世代 

“62 0E”

値 

“A0 0C”

値 

“5C00”  

“8B08” “B1 B2 B3 B4 B5 B6 B7 B8”  

“80 01” “XY” 

“A2 13”

値 

“B2 11” 

値 

“8004” “11 12 13 14” 

“8102” “21 22” 

“8203” “31 32 33” 

“630B” 

値 

“91 00” 

“4D05” 

値 

“7F 70 02 80 00” 

“51 00” 

“9101” “XY” 

注記 太文字のイタリック体のフォント“9101XY”は,上(タグ付ラッパ)のDO“63”の中で符号化したテンプレ

ート拡張の一部であることを示す。 

図G.2−“A0 01 02 03 04”と呼ぶアプリケーションDF配下のEF“12 34”の内容 

DO“A2”配下のDO“B2”の値フィールドは,タグ付ラッパDO“63”が拡張ヘッダによって第一世代

(一番左の欄)のDO“80”を参照するので,基礎テンプレート(DO“80”,“81”,“82”,及び“63”)及

びテンプレート拡張(DO“91”)で構成する。このDO“80”は,ここで別の参照可能なタグ“80”との

重複を避けるために,拡張されたテンプレート内のタグ“91”によって参照される。タグ“80”は,太文

字で,第一世代(基礎テンプレートに属すDO)及び第五世代(拡張ヘッダデータ要素)に現れる。値フ

ィールド“XY”は,(定義している)第一世代及び第三世代(DO“91”の値フィールド)に,太文字で現

れる。タグ“91”は,(定義している)第四世代及び第三世代(DO“91”がテンプレート拡張に属す。)に,

太文字で現れる。 

空のファイル参照DO“51”は,間接参照がDO“63”を入れ子にするDO“B2”を参照するVAにおい

て有効となっている。したがって,一時的VAがアプリケーション“A0 01 02 03 04”及びEF“12 34”を

参照することを確認する。カレント構造化DOがDO“B2”であるとき,DO“80”は,タグ“91”によっ

て局所的に指定されてもよい。 

− コマンドAPDU“00 CA 00 91 00”は,“XY 90 00”を返す。 

− コマンドAPDU“00 CB 00 00 03”{5C 01 91}“00”は,{91 01XY}“90 00”を返す。 

background image

166 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

G.3 

カレントアプリケーションDF中の参照,1番目の例 

第一世代 

第二世代 

第三世代 

第四世代 

“62 0E”

値 

“A0 0C”

値 

“5C00”  

“8B 08”“B1 B2 B3 B4 B5 B6 B7 B8” 

“80 01” “XY”  

“A2 13”

値 

“B2 11” 

値 

“80 04” “11 12 13 14” 

“81 02” “21 22” 

“82 03” “31 32 33” 

図G.3−“A0 01 02 03 04”と呼ぶ,アプリケーションDF配下のEF“12 34”の代替内容 

図G.3において,EF“12 34”の内容は,タグ付ラッパを含まない。タグ付ラッパは,EF“12 34”では

なく,アプリケーションDF“A0 01 02 03 04”を参照するVAに(有効の場合)存在してもよい。G.2と同

じDOを参照するタグ付ラッパの構文は,次の図G.4のとおりになる。 

“6309”  

“92 00”  

この例では,DOは局所的にタグ“92”で参照される。 

“5C 01” “80” 

EF“1234”中の第一世代DOのDO“80”を間接的に参照する。 

“51 02” “1234” 

カレントアプリケーション配下のEF“1234”を参照する。 

図G.4−タグリストを使用する,EFを参照しているタグ付ラッパの構文 

図G.2と比べて, 

− EFの明白な参照は,EF“12 34”で間接参照が有効であると述べている。 

− DO“80”がEF“12 34”の第一世代に属すので,拡張ヘッダをタグリストで置き換えてもよい。 

アプリケーション“A0 01 02 03 04”及び上記タグ付ラッパの親を参照しているVAから発行された次の

コマンドは,タグ“92”によってDO“80”を局所的に指定してもよい, 

− コマンドAPDU“00 CA 00 92 00”は,“XY 90 00”を返す。 

− コマンドAPDU“00 CB 00 00 03”{5C 01 92}“00”は,{92 01 XY}“90 00”を返す。 

類似(同じではない)の機能は,別のGET DATA C-RPによって提供されてもよい。同じVAから発行さ

れるとき,コマンドAPDU“00 CB 12 34 03”{5C 01 80}“00”は,{80 01 XY}“90 00”を返す。上記C-RP

の違いは,太文字で示す。この代替案を使用するために,カードの外部世界は,ファイル識別子“12 34”,

DOのタグ“80”及びその世代を知らなければならない。この全ては,実装に依存できる。 

G.4 

カレントアプリケーションDF中の参照,2番目の例 

DO“62”配下のDO“A0”を指定したい場合の例を示す。拡張ヘッダが必要であり,このDO“A0”は

EF内の第二世代に属する。タグ付ラッパは,次の図G.5のとおりになる。 

background image

167 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

“630C”  

“A000”  

この例では,DOはタグ“A0”で局所的に参照される。 

“4D04” “6202A080” 

DO“62”配下の第二世代DOのDO“A0”を間接的に参照する。 

“5102” “1234” 

カレントアプリケーション配下のEF“1234”を参照する。 

図G.5−拡張ヘッダを使用する,EFを参照しているタグ付ラッパの構文 

DO“62”配下のDO“A0”のタグは,DOに対するセキュリティ属性の標準の意味をもっている。別の

DO“62”配下で,同じタグで局所的に指定することは,このセキュリティ属性の重複を避ける。例えば,

アプリケーションDFの内の複数のEFがDOに対して同じ省略時セキュリティ属性を使用する場合。 

アプリケーション“A0 01 02 03 04”及び上記のタグ付ラッパを参照しているVAから,発行されたとき, 

− コマンドAPDU“00 CA 00 A0 00”は,{5C 00} {8B 08 B1 B2 B3 B4 B5 B6 B7 B8}“90 00”を返す。 

− コマンドAPDU“00 CB 00 00 03”{“5C 01 A0”}“00”は,{A0 0C {5C 00} {8B 08 B1 B2 B3 B4 B5 B6 

B7 B8}}“90 00”を返す。 

G.5 

カレントアプリケーションDFの外部参照 

カレントVAは,アプリケーションDF“A0 01 02 03 04”を参照していない。したがって,アプリケー

ション及びEFを参照する必要がある。G.3の最初の例と同じDOを参照しているタグ付ラッパの構文は,

次の図G.6のようになる。 

“6310”  

“9200”  

この例では,DOはタグ“92”で局所的に参照される。 

“5C01” “80” 

第一世代DOのDO“80”を間接的に参照する。 

“4F05” “A0 01 02 03 04” 

アプリケーション“A0 01 02 03 04”を参照する。 

“5102” “12 34” 

参照しているアプリケーション配下のEF“1234”を参照する。 

図G.6−タグリストを使用する,アプリケーションDF及びEFを参照しているタグ付ラッパの構文 

上記のタグ付ラッパを含むVAから,発行したとき, 

− コマンドAPDU“00 CA 00 92 00”は,“XY 90 00”を返す。 

− コマンドAPDU“00 CB 00 00 03”{5C 01 92} 00”は,{92 01 XY}“9000”を返す。 

G.6 

警告 

テンプレート拡張に属すDOの間接的参照は,(無限ループの)循環の参照になる可能性がある。 

タグ付ラッパの使用は,コマンドの複雑さをデータにおける複雑さに交換している。したがって,遠方

のDOを局所的に見てもよいタグを選択するとき,次のことを避けるために,注意しなければならない。 

− 基本DOを示すタグによって構造化DOに対処する。これは,扱いづらいが可能である。 

− 構造化DOを示すタグによって基本DOに対処する。これは,無効な構文のDO又はテンプレートに

なる。 

− 定義されたタイプの規格DOをこのタイプを示さない別のタグによって対処する。これは,これを用

いる仕様又は規格が,タイプについて言及することを意味する。 

− DOを,インスタンスの複製を意識せずに,タグ付ラッパとして同じテンプレートで既に使用された

タグによって対処する。 

168 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

附属書H 
(参考) 

対象DOに対する拡張ヘッダの分析 

この附属書に記載する手続きは,拡張ヘッダの次の三つのユースケース(適用例)について説明する。 

− 参照された構造化DOを知って,8.4.5に従って,完全な拡張ヘッダを構築する。 

− 8.4.5に従って,参照したDO(更新された)の前の値フィールドを知って,構築する。これは,結果

として拡張ヘッダ及びその対象DOの異なる構造になってもよい。 

− 拡張ヘッダを短くして,割愛するDOに対する余分な参照なしに構築する。 

手順に従うために,附属書F(ヘッダテーブルの各線上に一つのヘッダ,DOテーブルの各線上に一つ

のDO)のように拡張ヘッダ及び対象DOを表示する。線の順序は,ヘッダ及びDOの順序を示し,世代

は欄の移動として示す。次の規則は,“…の処理へ進む。”と言及しない場合,連続して適用しなければな

らない。 

1) 少なくとも一つのテーブルが空の場合,手順は,完了している。 

2) 拡張ヘッダが一つのDOだけを参照する場合で,基本DOで割愛されない一致(ヘッダ中でL≠“80”),

又は構造化DOで完全一致(ヘッダ中でL=“80”)が達成されている場合は,手順は,完了している。 

3) ヘッダテーブルの最初(最上)の線上を読み,DOテーブルでヘッダの一致を検索する。もし他の方

法[8)参照]で記載がない場合,検索は,DOテーブルの最初(最上)の線上で行われなければなら

ない。 

4) 一致(同じタグ,同世代で)が達成される場合,10)の処理へ進む。 

5) DO世代がヘッダ世代よりも下位の場合,7)の処理へ進む。 

6) 検索がDOテーブルの最終の線に達していない場合,検索は,次の線に続き,1)の処理へ進む。 

注記 テンプレートを検索するとき,より上位の世代又は間違ったタグのDOは無視する。 

7) 検索した一致が基本DOに存在した場合,ヘッダテーブルから線を削除し,1)の処理へ進む。 

注記 参照されたDOは,検索したテンプレートに決して存在はしていなかった,又は一致の後で

削除された[10)参照]。 

8) 検索した一致が構造化DOに存在した場合,割愛(ヘッダのL=“00”)又は完全(ヘッダのL=“80”)

のいずれかで,ヘッダテーブルから横線を削除する。1)の処理へ進む。 

注記 参照したDOは,検索されたテンプレートに決して存在はしていなかった,又は一致の後で

削除された[10)参照]。 

9) ヘッダテーブルから,構造化DO及びその内容を参照している横線を削除し,1)の処理へ進む。 

注記 参照した構造化DOは,検索されたテンプレートに決して存在はしていなかった,又は一致

の後で削除された[10)参照]。内容の参照は,役に立たない。 

10) 8.4.6を適用する。両方のテーブルから一致する横線を削除する。DOテーブルでは,もし存在すれば,

上の全ての横線を削除する。 

注記 バイト列に対するそれら削除されたDOの寄与は,拡張ヘッダによって指示された順序に一

致していない。 

11) 基本DOとの一致が達成された場合,1)の処理へ進む。 

12) 構造化DOで,割愛された一致(ヘッダのL=“00”)又は完全一致(ヘッダのL=“80”)が達成され

169 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

た場合,DOテーブルから一致しているDOの値の全ての横線を削除する。1)の処理へ進む。 

13) 構造化DOで別の一致が達成された場合,1)の処理へ進む。 

注記 構文解析及び検索は,次の世代で行う。 

background image

170 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

参考文献 

[1] EN 14890-1:2008,Application Interface for smart cards used as Secure Signature Creation Devices−Part 1: 

Basic services 

[2] EN 14890-2:2012,Application Interface for smart cards used as Secure Signature Creation Devices−Part 2: 

Additional Services 

[3] JIS X 0304:1999 国名コード 

注記1 対応国際規格:ISO 3166-1:1997,Codes for the representation of names of countries and their 

subdivisions−Part 1: Country codes(IDT) 

注記2 ISO 3166-1は,2013年版が最新版である。また,JIS X 0304は,2011年版(対応国際国際

規格の2006年に対応)が最新版である。 

[4] JIS X 6301:2005 識別カード−物理的特性 

注記 対応国際規格:ISO/IEC 7810:2003,Identification cards−Physical characteristics(IDT) 

[5] ISO/IEC 7812-1:2000,Identification cards−Identification of issuers−Part 1: Numbering system 

[6] JIS X 6320規格群 識別カード−ICカード 

注記1 対応国際規格:ISO/IEC 7816 (all parts),Identification cards−Integrated circuit cards 

注記2 ISO/IEC 7816は,第1部〜第13部及び第15部によって構成されているが,対応JISは,

第1部〜第6部,第8部,第9部,第11部,第13部及び第15部での部編成となっている。 

[7] ISO/IEC TR 9577:1999,Information technology−Protocol identification in the network layer 

[8] ISO/IEC 9796 (all parts),Information technology−Security techniques−Digital signature schemes giving 

message recovery 

注記 ISO/IEC 9796は,第2部及び第3部で構成している(第1部はない。)。ISO/IEC 9796:1991

に対応してJIS X 5054:1996(セキュリティ技術−メッセージ復元を可能にするディジタル署

名方式)があったが,対応国際規格での部編成とする改訂に伴い2000年に廃止された。 

[9] ISO/IEC 9797 (all parts),Information technology−Security techniques−Message Authentication Codes 

(MACs) 

注記 ISO/IEC 9797は,第1部〜第3部で構成している。対応JISとして,JIS X 5055-1[セキュ

リティ技術−メッセージ認証符号(MACs)−第1部:ブロック暗号を用いる機構]及びJIS 

X 5055-2[セキュリティ技術−メッセージ認証符号(MACs)−第2部:専用ハッシュ関数を

用いる機構]があったが,いずれも2015年に廃止された。 

[10] ISO/IEC 9798 (all parts),Information technology−Security techniques−Entity authentication 

注記 ISO/IEC 9798は,第1部〜第6部で構成している。対応JISとして,JIS X 5056-1〜JIS X 5056-5

(セキュリティ技術−エンティティ認証)があったが,JIS X 5056-1〜JIS X 5056-3は2012

年に,JIS X 5056-4及びJIS X 5056-5は2015年に廃止された。 

[11] ISO/IEC 9979:1999,Information technology−Security techniques−Procedures for the registration of 

cryptographic algorithms 

注記 この規格は2006年に廃止となっている。対応国際規格の1991年版に対応したJIS X 

5060:1994(データ暗号技術−暗号アルゴリズムの登録手続)も,2009年に廃止された。 

[12] ISO 9992-2:1998,Financial transaction cards−Messages between the integrated circuit card and the card 

background image

171 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

accepting device−Part 2: Functions, messages (commands and responses), data elements and structures 

[13] JIS X 5053 セキュリティ技術−nビットブロック暗号の利用モード 

注記 対応国際規格:ISO/IEC 10116:1997,Information technology−Security techniques−Modes of 

operation for an n-bit block cipher(IDT) 

[14] ISO/IEC 10118 (all parts),Information technology−Security techniques−Hash-functions 

注記 ISO/IEC 10118は,第1部〜第4部で構成している。対応JISとして,JIS X 5057-1〜JIS X 

5057-4(セキュリティ技術−ハッシュ関数)があったが,いずれも2015年に廃止された。 

[15] ISO/IEC 10536 (all parts),Identification cards−Contactless integrated circuit(s) cards−Close-coupled cards 

注記 ISO/IEC 10536は,第1部〜第3部で構成している。対応JISとして,JIS X 6321-1〜JIS X 

6321-3(外部端子なしICカード−密着型)があったが,JIS X 6321-1は2012年に,JIS X 6321-2

及びJIS X 6321-3は2010年に廃止された。 

[16] JIS X 0221 国際符号化文字集合(UCS) 

注記1 対応国際規格:ISO/IEC 10646,Information technology−Universal Coded Character Set (UCS) 

注記2 対応国際規格は,2014年版が最新版であるが,JIS X 0221は,対応国際規格の2012年版

に対応したものが最新版である。 

[17] JIS X 5058規格群 セキュリティ技術−かぎ管理 

注記1 対応国際規格:ISO/IEC 11770 (all parts),Information technology−Security techniques−Key 

management 

注記2 ISO/IEC 11770は,第1部〜第6部によって構成されているが,対応JISは,第1部及び

第2部での部編成となっている。両JIS共に対応国際規格の1996年版に対応した規格で,

対応国際規格の最新版(第1部は2010年版,第2部は2008年版)には対応していない。 

[18] JIS X 6322規格群 識別カード−非接触(外部端子なし)ICカード−近接型 

注記1 対応国際規格:ISO/IEC 14443 (all parts),Identification cards−Contactless integrated circuit 

cards−Proximity cards 

注記2 対応国際規格及びJIS共に第1部〜第4部での構成であるが,JISは,対応国際規格の最

新版(いずれも2016年版が最新である。)には対応していない。 

[19] ISO/IEC 14888 (all parts),Information technology−Security techniques−Digital signatures with appendix 

注記 ISO/IEC 14888は,第1部〜第3部で構成している。対応JISとして,JIS X 5061-1〜JIS X 

5061-3(セキュリティ技術−添付型ディジタル署名)があったが,いずれも2012年に廃止さ

れた。 

[20] JIS X 6323規格群 識別カード−非接触(外部端子なし)ICカード−近傍型 

注記1 対応国際規格:ISO/IEC 15693 (all parts),Identification cards−Contactless integrated circuit 

cards−Vicinity cards 

注記2 対応国際規格及びJIS共に第1部〜第3部での構成であるが,JISの第3部(最新は,対

応国際規格の2009年版に対応した2011年版)は,対応国際規格の最新版には対応してい

ない。対応国際規格の第3部では,2009年版に対しAmd 2:2015及びAmd 3:2015が発行さ

れている。 

[21] ISO/IEC 18033 (all parts),Information technology−Security techniques−Encryption algorithms 

[22] JIS X 5211 システム間の通信及び情報交換−近距離通信用インタフェース及びプロトコル

(NFCIP-1) 

172 

X 6320-4:2017 (ISO/IEC 7816-4:2013) 

注記 対応国際規格:ISO/IEC 18092,Information technology−Telecommunications and information 

exchange between systems−Near Field Communication−Interface and Protocol (NFCIP-1)(IDT) 

[23] ISO/IEC 24727 (all parts),Identification cards−Integrated circuit card programming interfaces 

[24] ISO/IEC 24727-2,Identification cards−Integrated circuit card programming interfaces−Part 2: Generic card 

interface 

[25] ISO/IEC 24727-3,Identification cards−Integrated circuit card programming interfaces−Part 3: Application 

interface 

[26] IETF RFC 1738:1994,Uniform resource locators (URL) 

[27] IETF RFC 2396:1998,Uniform resource locators (URL): General syntax