セキュリティAPIに関する技術調査 2003年版 - IPA 独立行政法人情報

15 情経第 1516 号
セキュリティ API に関する技術調査
− Part 4 −
IC カードなどのハードウェアトークン API
2004 年 2 月
独立行政法人情報処理推進機構
登録商標について
Microsoft、MS、Windows、Windows 2000、Windows NT、Windows ロゴ、Internet Explorer、Outlook、
Visual C++などは、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標
である。
Sun Microsystems、Sun ロゴ、Java コーヒーカップロゴ、Solaris、Java、JDK、Solaris などは、米国 Sun
Microsystems の米国およびその他の国における登録商標または商標である。
その他、本文書に記載されている会社名、商品名、製品名などは、一般に各社の商標または登録商標
または商標である。
本書では、™、©、®などを記載しない。
―
目
次
―
1 はじめに.................................................................................................................. 1
2 ハードウェアトークンについて.............................................................................. 2
2.1 ハードウェアトークン ..................................................................................... 2
2.2 IC カード.......................................................................................................... 3
3 PKCS #11 ................................................................................................................ 7
3.1 PKCS #11 の概要 ............................................................................................. 7
3.1.1 PKCS #11 仕様の策定理由について ......................................................... 7
3.1.2 PKCS #11 の目的 ...................................................................................... 7
3.2 PKCS #11 の考え方.......................................................................................... 8
3.2.1 Cryptoki のシステムアーキテクチャ ........................................................ 8
3.2.2 PKCS #11 で規定される概念 .................................................................... 9
3.3 PKCS #11 の機能 ............................................................................................11
3.3.1 Cryptoki 関数一覧....................................................................................11
3.3.2 暗号メカニズム....................................................................................... 14
3.4 実装の留意点 ................................................................................................. 14
3.4.1 Cryptoki における留意点 ........................................................................ 14
3.4.2 動作環境における留意点 ........................................................................ 15
3.4.3 PKI ライブラリの実際 ............................................................................ 15
3.5 暗号処理アルゴリズムの一例 ........................................................................ 15
4 CSP (Cryptographic Service Provider) ................................................................ 17
4.1 CSP 概要 ........................................................................................................ 17
4.1.1 CryptoAPI について ............................................................................... 17
4.1.2 CSP について .......................................................................................... 17
4.1.3 CryptoAPI のシステムアーキテクチャ ................................................... 17
4.1.4 CryptoSPI と CryptoAPI の関係 ............................................................ 19
4.1.5 CryptoSPI について................................................................................ 20
4.1.6 CSP のプロバイダータイプについて ...................................................... 21
4.2 IC カードを使った CSP の開発留意点 ........................................................... 22
4.2.1 暗号ロジックの実装方法 ........................................................................ 22
4.2.2 マルチアプリケーション環境での利用................................................... 23
4.2.3 PIN のキャッシュ ................................................................................... 24
4.2.4 証明書のキャッシュ ............................................................................... 25
4.2.5 証明書の登録 .......................................................................................... 25
4.2.6 証明書の利用 .......................................................................................... 25
4.2.7 レジストリ登録情報 ............................................................................... 26
4.2.8 仕様書、参考資料 ................................................................................... 26
i
5 PKCS #11 と CSP の相互運用............................................................................... 27
5.1 IC カード内のファイル構造共通化................................................................. 27
5.2 キャッシュされた PIN の共有化 ................................................................... 27
5.3 データの差異の吸収....................................................................................... 29
5.4 属性証明書の扱い .......................................................................................... 29
6 PKCS #15.............................................................................................................. 30
6.1 PKCS #15 の背景・目的 ................................................................................ 30
6.2 PKCS #15 の考え方 ....................................................................................... 30
6.2.1 オブジェクトについて............................................................................ 31
6.2.2 ファイル構造のモデル............................................................................ 32
6.3 PKCS #15 の機能 ........................................................................................... 34
6.3.1 オブジェクトの管理について ................................................................. 34
6.3.2 オブジェクトの追加 ............................................................................... 34
6.3.3 オブジェクトの削除 ............................................................................... 36
7 GSC-IS (Government SmartCard Interoperability Specification) ..................... 37
7.1 成立した背景 ................................................................................................. 37
7.2 GSC-IS の構成 ............................................................................................... 37
7.3 Access Control ............................................................................................... 40
7.4 BasicServiesInterface ................................................................................... 41
7.5 Virtual Card Edge Interface ......................................................................... 43
7.6 Card Capabilities Container......................................................................... 45
7.7 DataModel ..................................................................................................... 47
8 まとめ ................................................................................................................... 48
9 参考文献................................................................................................................ 50
10 用語（参考）....................................................................................................... 51
ii
―
図目次
―
図
図
図
図
図
図
図
図
図
図
図
2-1 専用 OS の論理ファイル構成例 ............................................................... 3
2-2 マルチアプリケーション OS 型 IC カードの構成 .................................... 4
3-1 Cryptoki のモデル例 ................................................................................ 8
4-1 CryptoAPI のシステムアーキテクチャ .................................................. 18
4-2 CryptoAPI と CryptoSPI の関係 ........................................................... 19
4-3 プリインストールされている CSP をコール ......................................... 22
4-4 共有、排他モードで IC カードと接続 ................................................... 23
4-5 PIN をキャッシュして自動的に Verify 実行 .......................................... 24
5-1 PIN キャッシュ共有と不正プログラム排除 ........................................... 28
5-2 アプリケーション毎に PIN キャッシュ................................................. 28
6-1 カードのファイル構造 ........................................................................... 32
図
図
図
図
図
図
図
図
図
6-2 PKCS #15 Application Directory .......................................................... 33
6-3 オブジェクト追加の例：STEP1 ............................................................ 34
6-4 オブジェクト追加の例：STEP2 ............................................................ 35
6-5 オブジェクト削除の例：削除前............................................................. 36
6-6 オブジェクト削除の例：削除後............................................................. 36
7-1 IS アーキテクチャモデル ....................................................................... 38
7-2 GSC-IS の動作 ....................................................................................... 39
7-3 CCCEF 配置場所.................................................................................... 45
7-4 T-Buffer、V-Buffer ................................................................................ 47
iii
―
表目次
―
表
表
表
表
表
表
表
表
表
表
表
2-1 鍵および証明書の処理に必要なコマンド例 ............................................. 5
2-2 IC カードの不正利用を防止するために必要なコマンド例 ....................... 6
3-1 オブジェクトの代表例 ............................................................................. 9
3-2 オブジェクトの属性の代表例 ................................................................ 10
3-3 Cryptoki 関数一覧...................................................................................11
3-4 処理手順 ................................................................................................ 16
4-1 CryptoAPI 関数群 .................................................................................. 17
4-2 CSP がエクスポートすべき関数（必須） .............................................. 20
4-3 CSP がエクスポートすべき関数（オプショナル） ................................ 20
7-1 Access Control Rules ............................................................................. 40
7-2 BSI Application Interface...................................................................... 41
表
表
表
表
7-3 ファイルシステム用 APDU ................................................................... 43
7-4 VM カード APDU .................................................................................. 44
7-5 CCC フィールド ..................................................................................... 46
7-6 firstTLV(ファイルシステムカード) ........................................................ 47
iv
1 はじめに
本報告書では、ハードウェアトークンを利用するための API の標準化動向につい
て解説する。
一般的には、トークン（token）という英単語は「しるし、象徴、証拠」という意
味をもつが、IT セキュリティ分野では身許（identity）を証明するための証拠という
意味で身許トークン（identity token）とうように使われる。LAN の規格にトークン
リング（token ring）と呼ばれるものがあるが、この場合のトークンは LAN 上への
データ送出権を表彰する「証拠」としてのデータを指しているのも、同じ用語の使い
方の類例である。
本報告書で述べるハードウェアトークンとは、トークンリングにおけるようなデー
タ（ソフトウェア）としてのトークンではなく、身許トークンとして利用しうる物理
的な装置（device）のことである。
1
2 ハードウェアトークンについて
2.1
ハードウェアトークン
ハードウェアトークンは身許トークンとしての用途から一般に携帯に便利な小型
の装置として作られ、IC カード（キャッシュカード大のプラスチック製カードに半
導体集積回路（IC チップ）を埋め込み、情報を記録／処理できるようにしたもの）
や USB プラグ形態をした USB キー型トークン等がある。本章ではハードウェアト
ークンの中でも、クレジットカードなどの金融系用途、交通系用途、携帯電話の USIM
などとして広く利用されている IC カードについて主に述べる。
PKI システムの構築において留意しなければならないことは、プライベート鍵の漏
洩を防ぐことである。PKI システムで行われているプライベート鍵の管理方法には、
端末のハードディスクドライブ内にプライベート鍵を格納する、厳重にアクセス制御
されたサーバーで管理する等の方法があるが、ハードウェアトークンをプライベート
鍵の格納に用いることには二つのメリットがある。
第一に、プライベート鍵の所有者本人がプライベート鍵を携帯することが可能とな
る。公開鍵暗号におけるプライベート鍵は、その所有者を識別するためのデータであ
り、デジタル署名を生成する際の必須データである。プライベート鍵の携帯を可能と
するハードウェアトークンは、ユーザが必要なときに必要な場所で（必ずしもコンピ
ュータキーボードの前ではなく）、自分の身許を証明することを可能にし、電子商取
引など PKI の適用範囲を著しく拡大する。
第二に、IC カードのように CPU（演算処理装置）を具えたハードウェアトークン
では、デジタル署名の生成をハードウェアトークン内で行うことができ、プライベー
ト鍵の秘匿性はさらに高まる。たとえば、ハードウェアトークン内からプライベート
鍵を外に出さずにデジタル署名を生成することができるので、不正なサーバーやホス
トプログラムに対して、プライベート鍵を開示する危険を冒すことなく、身許の証明
を実行できる。
「プライベート鍵の格納場所」として使われるハードウェアトークンには、外部か
らの攻撃に対する耐タンパー性が要求される。
CPU を内蔵する IC カードでは、OS や IC カードアプリケーションに、利用者の
認証やファイルへのアクセス制御などのセキュリティ機能を搭載することにより、プ
ライベート鍵のような秘密情報へのアクセス権を持たない第三者による読出しを禁
止する耐タンパー性を実現している。IC カードのセキュリティ機能は、コマンドイ
ンターフェイスを経由した通常のアクセス経路に対しては、上述のように認証機能や
アクセス制御機能で対応している。
2
近年では通常のアクセス経路以外に、IC チップそのものへの物理的な直接攻撃や、
CPU での処理中の消費電力などのリーク情報を利用した DPA（Differential Power
Attack）などの攻撃が知られているが、金融系用途で使われる IC カードでは、これ
らの攻撃にも十分に耐えられる対策が施されている。
2.2
IC カード
現在、IC カードは金融系、交通系を中心として多く利用されている。金融系では
接触型の IC カード、交通系では非接触型の IC カードが主に使われている。近年では、
接触型と非接触型のチップそれぞれを 1 枚のカードに加工したハイブリッド型の IC
カードや、接触型と非接触型のチップが一体化して１つのメモリを共有しているデュ
アルインターフェイス型の IC カードも出始めている。インターフェイスを 2 種類持
つことで、IC カードの利便性が向上する。特に、デュアルインターフェイス型の IC
カードは１つのメモリを 2 つのインターフェイスで共有しているため、ハイブリッド
型に比べコストメリットもあり、今後更に利用が広まっていくと考えられる。
現状、PKI アプリケーション用で主に使われる IC カードは、Co-Processor が搭載
された高機能な接触型の IC カードである。
IC カードを OS で大別すると、専用 OS と呼ばれているものとマルチアプリケーシ
ョン OS と呼ばれているもの２種類に分けられる。
専用 OS では、OS と IC カードアプリケーションが ROM に焼きこまれた状態にな
っており、データのみが書き換え可能な EEPROM に格納される。データ部の論理フ
ァイル構成が図 2-1のような構成になっているため、ファイルシステム OS とも呼ば
れている。
図 2-1 専用 OS の論理ファイル構成例
一方、マルチアプリケーション OS では、汎用の基本処理を行うための OS が ROM
に焼きこまれた状態になっており、IC カードアプリケーションはデータとともに
EEPROM に格納される。書き換え可能な領域に IC カードアプリケーションが書き
3
込まれるため、IC カードを発行した後でも、新たな IC カードアプリケーションを IC
カード内に追加することが可能となる。また、不要となった IC カードアプリケーシ
ョンを削除することも可能である。
マルチアプリケーション OS は、図 2-2のように、IC カードアプリケーションの共
通の実行環境である Virtual Machine（VM）が、ハードウェアに依存性がある個別
の OS の差異を隠蔽するため、VM カードと呼ばれることもある。
現在、マルチアプリケーション OS 型の IC カードの代表的なものとして、Java
Card と MULTOS の 2 種類があげられる。
図 2-2 マルチアプリケーション OS 型 IC カードの構成
IC カードがもつ携帯性や耐タンパー特性、更には、マルチアプリケーション OS
の拡張性などの特徴を生かして、PKI 機能を持った IC カードアプリケーションが搭
載された IC カードへクレジットカード、キャッシュカード、ポイントカード、交通、
医療、入退出管理等、さまざまな機能が搭載された IC カードが今後多く利用されて
いくと考えられる。
確かに、IC カードの高機能化・高性能化が進んでいるが、IC カードの基本機能や
IC カードアプリケーションの開発には、以下に述べるような点を考慮する必要もあ
る。
1. 携帯可能なサイズにするために格納できるデータの容量が制限されることも事
実である。利便性があがるからといって、いたずらに IC カードアプリケーシ
ョンを搭載したり、多くのデータを格納しようとすると、大容量のチップが必
要になり、コスト的な問題や技術的な問題をクリアしなければならなくなる。
そのため、IC カードアプリケーションを作成する際は、必要なコマンドのみを
搭載し、スリム化を行うことも重要な点となる。
2. IC カードは、通信方式、OS の特性などで数種類に分類することができるが、
カードの形状、物理特性、端子、伝送プロトコル、APDU などは、国際標準規
格で決められている。IC カードの互換性を保つためには、標準規格に準じたコ
マンドを実装する必要がある。
3. プライベート鍵の秘匿という観点からは、プライベート鍵を IC カード外部に
取り出さず IC カード内部でデジタル署名作成のための演算行うだけではなく、
プライベート鍵自身の生成も IC カード内で実行されることが望ましい。この
4
ように、PKI に関連する重い演算処理が求められるため、利便性を損なわない
処理速度を提供できる性能も IC カードと IC カードアプリケーションに求めら
れる。
4. プライベート鍵を外部の暗号モジュールで生成し、IC カードに格納する方法も
あるが、その場合、鍵生成から格納までセキュアな環境を、IC カードもサポー
トしなければならない。特に、証明書を読み書きするためのコマンドも必要と
なる。
接触型 IC カードの国際標準規格である ISO/IEC7816 での鍵および証明書の処理
に必要なコマンド例を表 2-1に示す。
表 2-1 鍵および証明書の処理に必要なコマンド例
用途
コマンド
GENERATE PUBLIC KEY
IC カード内で公開鍵ペア作成
IC カード内でプライベート鍵の演算 COMPUTE DIGITAL SIGNATURE
（デジタル署名の生成）
READ BINARY
IC カードから証明書の読み出し
(バイナリーデータの読み出し）
READ RECORD
（レコードの読み出し）
WRITE BINARY
(バイナリーデータの初期書き込み）
UPDATE BINARY
(バイナリーデータの更新）
WRITE RECORD
(レコードの初期書き込み）
APPEND RECORD
(レコードの追記）
UPDATE RECORD
(レコードの更新）
CHANGE REFERENCE DATA
IC カードへの証明書の書き込み
IC カードへの鍵の書き込み
また、PKI 機能だけでなく、IC カードを不正な利用から守るためのコマンドも必
要となってくる。
例えば、IC カード所有者の本人確認を行うことは必須だろう。IC カードは、内部
に記録されているデータへアクセスするための条件を設定することができ、この条件
が満たされているかどうかがそのファイルのセキュリティステータスとして保持さ
れている。セキュリティステータスが満たされている時、そのファイルへアクセス可
能となる。現時点では、セキュリティステータスを満たすための条件として PIN 入
力を行い、IC カード内に格納してある PIN との比較を行うことにより認証を行う方
5
法が一般的である。バイオメトリクスと組み合わせた方法として、指紋データ、声紋
データの認証による本人確認が行える IC カードも存在し始めている。
更に、PIN を IC カードへ送信する際に、PIN の値を秘匿して渡すためのコマンド
や、IC カードの特徴を生かして、外部接続装置と IC カードのお互いがそれぞれを認
証させるために、乱数を生成してそのデータの暗号化、復号を行うことにより IC カ
ードおよび接続装置の正当性認証を行うことが必要な場合もある。
IC カードの不正利用を防止するために必要なコマンド例を表 2-2に示す。
表 2-2 IC カードの不正利用を防止するために必要なコマンド例
用途
コマンド
ICカード所有者認証
VERIFY
送信コマンドの秘匿
ENVELOPE
乱数の生成
GET CHALLENGE
ICカードの正当性認証
INTERNAL AUTHENTICATE
接続装置の正当性認証
EXTERNAL AUTHENTICATE
IC カードを利用した PKI アプリケーションを開発する場合、PKI アプリケーショ
ンからこれらのコマンドを IC カードへ直接送信して処理を行わせる方法もあるが、
この様な PKI アプリケーションを開発するためには、PKI に関する知識はもちろん
のこと、IC カードの中身まで熟知している必要がある。
また、独自のコマンドを搭載している IC カードを利用する場合には、IC カードに
直接干渉するアプリケーションは、その特定の IC カードでしか動作しない。
このような、アプリケーション開発上のオーバーヘッドを取り除き、互換性を向上
させて適用範囲を広げるために、標準化された API が必要となってくる。
実際、PKI アプリケーションや IC カードも互換性を持たせるために、PKCS #11
や CryptoAPI の等標準化された API を利用したアプリケーションの開発が多く行わ
れている。また、PKCS #15 による IC カード内部のファイル構造に関する標準化や
GSC-IS による IC カードのコマンドインターフェイスの標準化も進んでいる。
今後、PKI アプリケーションや IC カードなどのハードウェアトークンの互換性を
得るために、これらのハードウェアトークン用の標準規格の利用がますます進んでい
き、整備されていくだろう。
6
3 PKCS #11
3.1
PKCS #11 の概要
3.1.1 PKCS #11 仕様の策定理由について
PKCS とは「Public Key Cryptography Standards」
（公開鍵暗号における標準）
の略であり、RSA Laboratories を中心として策定された規格セットである。PKCS
#11 は「Cryptographic Token Interface Standard」（暗号処理におけるトークンイン
ターフェイスの標準）といわれており、トークンに対して、証明書の呼び出し／格納、
プライベート鍵／公開鍵を使用したデジタル署名／検証などの暗号演算を行うため
の API が規定されている。
次に、PKCS #11 が策定された背景を記す。暗号関連製品の利用を促進させるには、
暗号技術が様々なトークンやアプリケーションで利用される必要がある。しかし各ベ
ンダー（トークンベンダーや R/W ベンダー、アプリケーションベンダー等）がそれ
ぞれ独自仕様の製品を開発し市場に参入すれば、製品間の互換がとれない可能性がで
てくる。そのためベンダー側は、トークン∼アプリケーションに至るまで全てを網羅
しなければいけないことから、暗号関連製品の開発が難しくなる。仮に独自仕様の製
品が販売されても、エンドユーザは自由に製品(トークン、R/W、アプリケーション
など)を選べなくなる。よって暗号関連製品の利用が促進される可能性は低い。その
ため RSA Laboratories は、公開鍵暗号技術における標準仕様を策定した。
PKCS #11 仕様は、1996 年 7 月から検討され、最新のバージョンは 2.11 である。
また現在、バージョン 2.20 が検討され、Draft4 が公開されている。
バージョン 2.11 までは、様々なトークンやアプリケーションで利用されることを
考慮して、必須項目を規定することはなかったが、バージョン 2.20 では必須項目を
規定している。必須項目を規定した理由として、昨今様々なモバイルデバイスが市場
に登場しており、必須項目が規定されないと互換性を損ねる危険性があるためと考え
られる。
本章では、バージョン 2.11 に基づき記述していく。
3.1.2 PKCS #11 の目的
PKCS #11 の主な目的としては、公開鍵暗号技術の実装間での互換性（トークン∼
アプリケーション間での互換性）が挙げられる。目標として、『特定の機種に依存し
ない暗号製品の開発促進』と『複数アプリケーションから複数トークンへのアクセス
7
可能化』を挙げる。これらの目標を達成すべく、PKCS #11 では「Cryptoki（クリプ
トキー）」と呼ばれる標準 API を規定し、アプリケーションに対してトークンへの共
通の論理的視点を与えた。
3.2
PKCS #11 の考え方
Cryptoki の一般的なモデルを記し、PKCS #11 の考え方について説明する。
3.2.1 Cryptoki のシステムアーキテクチャ
PKCS #11 の目標として『複数アプリケーションから複数トークンへのアクセス可
能化』を挙げた。そのため、PKCS #11 では「スロット」と呼ばれる概念を導入して
実現を図っている。アプリケーションがトークンにアクセス（暗号処理など）する際
に「スロット」を経由すると規定している。アプリケーションはトークンにアクセス
可能なスロットを事前に検出し、トークンへのアクセスを行う。スロットの数に上限
は設けていないため、複数トークンへのアクセスが可能な仕様である。
図 3-1にモデル例を示す。
図 3-1 Cryptoki のモデル例
8
3.2.2 PKCS #11 で規定される概念
PKCS #11 の考え方を簡単に箇条書きで記す。また3.5 では、Cryptoki ライブラ
リの使用例を記した。
1. Cryptoki を通してアクセスできるトークン内のデータは、「オブジェクト」と
見なされる。
2. トークンにアクセスができる者を、「ユーザ」として規定している。また、アク
セスした者が「ユーザ」か否かを判断するために「PIN」の概念を規定してい
る。
3. アプリケーションがトークンにアクセスする際は「スロット」を経由するが、
「セッション」と呼ばれる接続を確保してアクセス(暗号処理など)が可能とな
る。
以上を踏まえ、PKCS #11 で使用されている用語・概念のうち主な７項目を説明す
る。
(1) オブジェクト
「オブジェクト」とは、トークンに格納されるデータである。オブジェクトとし
て格納されるデータの内容（「クラス」と呼ばれる）は主に表 3-1に記した 4 種類
があり、それぞれのオブジェクトにアクセスするための関数が PKCS #11 では規定
されている。
表 3-1 オブジェクトの代表例
クラス
Data
Key
Certificate
Hardware Feature
説明
任意のデータ
鍵。公開鍵、プライベート鍵、共通鍵の 3 種が定義でき
る。
証明書。公開鍵用証明書と属性証明書の 2 種が定義でき
る。
IC カード等のデバイスが保持しているユーザ表示用の
データ。時計オブジェクトなどがある。
9
(2) オブジェクトの属性
オブジェクトには、「属性」が設定できる。主な属性を表 3-2に記す。
表 3-2 オブジェクトの属性の代表例
属性
Object Identifier
一般的な属性(例)
（オブジェクト ID）
Value（値）
種別を表セッションに Token（永続的）
わす属性おける種別
Session（一時的）
説明
トークン内でユニークとす
るオブジェクトの ID
オブジェクト内のデータ
セッションが終了しても存
在する
セッションが終了すると破
棄される
アクセス権に Public（公開）
アクセス権フリー
おける種別
Private（秘密）
アクセスに PIN が必要
クラス特鍵オブジェク ID（ID）
鍵の ID
有の属性ト特有の属性 Start Date（開始日）鍵の有効開始日
(例)
(例)
発行者の名前
証明書オブジ Issuer（発行者）
ェクト特有の
属性(例)
(3) ユーザ
「ユーザ」とは、トークンにアクセスできる者である。SO（セキュリティオフ
ィサー）ユーザと一般ユーザの 2 種類を規定している。
1. SO ユーザ：トークンの初期化、一般ユーザの PIN の設定が可能
2. 一般ユーザ：プライベートオブジェクトへのアクセスが可能
(4) PIN
PKCS #11 では、ユーザ識別（ユーザログイン）のために、PIN が規定されてい
る。
プライベートオブジェクト（Private 属性を有するオブジェクト）にアクセスし
たい場合には、一般ユーザでログインが必要になる。以下の手順となる。
1. セッションを開く。
2. 一般ユーザの PIN をアクセス者に入力させる。
3. PIN の認証を行い、成功した場合に限り、プライベートオブジェクトへのア
クセスが可能になる。
10
(5) セッション
「セッション」とは、暗号処理アプリケーションのトークンアクセス用の接続で
ある。アクセス用に確保されたメモリと考えてもよい。つまり、アプリケーション
がトークンにアクセスするには、必ずセッションを使用する必要がある。セッショ
ンの役割として、ログイン管理、オブジェクト管理、暗号処理の 3 項目に大きく分
かれる。
セッションの種類として、読み書き可能と読み出しのみの 2 種ある。
Cryptoki は複数のセッションをサポートすることが可能である。
(6) スロット
「スロット」とは、アプリケーションがトークンにアクセスする際に経由するコ
ンポーネント群である。
(7) トークン
「トークン」とは、認証用データが格納されたデバイスの総称である。具体的に
は、IC カードが挙げられる。
3.3
PKCS #11 の機能
Cryptoki が規定している関数の一覧と、PKCS #11 で実装可能な暗号メカニズム
について簡単に記す。
3.3.1 Cryptoki 関数一覧
Cryptoki が規定する関数は、表 3-3で記す 68 個である。
表 3-3 Cryptoki 関数一覧
分類
一般関数
関数名
C_Initialize
C_Finalize
C_GetInfo
C_GetFunctionList
説明
Cryptoki ライブラリを初期化する
Cryptoki ライブラリを終了する
Cryptoki の一般情報を取得する
Cryptoki ライブラリ関数のエントリ
ポインタを返す
システム内のスロット一覧を取得す
る
システム内の特定のスロットの情報
を取得する
スロットとト C_GetSlotList
ークン管理関
数
C_GetSlotInfo
11
分類
関数名
C_GetTokenInfo
C_WaitForSlotEvent
C_GetMechanismList
C_GetMechanismInfo
C_InitToken
C_InitPIN
C_SetPIN
セッション管 C_OpenSession
理関数
C_CloseSession
C_CloseAllSessions
C_GetSessionInfo
C_GetOperationState
C_SetOperationState
オブジェクト
管理関数
C_Login
C_Logout
C_CreateObject
C_CopyObject
C_DestroyObject
C_GetObjectSize
C_GetAttributeValue
C_SetAttributeValue
C_FindObjectsInit
暗号関数
復号関数
C_FindObjects
C_FindObjectsFinal
C_EncryptInit
C_Encrypt
C_EncryptUpdate
C_EncryptFinal
C_DecryptInit
12
説明
システム内の特定のトークンの情報
を取得する
スロットのイベント(トークンの挿抜
など)の発生を待つ
トークンで使用可能なメカニズム一
覧を取得する
トークンで使用可能なメカニズムの
情報を取得する
トークンを初期化する
一般ユーザ PIN の初期化を行う
現在ログイン中のユーザの PIN 変更
を行う
セッションを開く
セッションを閉じる
あるトークンへの全セッションを閉
じる
セッション情報を取得する
セッションの暗号処理状態をバイト
列化して取得する
セッションの暗号処理状態を設定す
る
トークンへのログインを行う
トークンからのログアウトを行う
新規オブジェクトの生成を行う
オブジェクトをコピーして新規オブ
ジェクトを作成する
オブジェクトの廃棄を行う
オブジェクトサイズをバイト単位で
取得する
オブジェクトの属性値を取得する
オブジェクトの属性値を変更する
オブジェクト検索処理の初期設定を
行う
オブジェクト検索処理を実行する
オブジェクト検索処理を終了する
暗号処理の初期設定を行う
単数ブロックの暗号化を行う
複数ブロックの暗号化を継続する
複数ブロックの暗号化を終了する
復号処理の初期設定を行う
分類
関数名
C_Decrypt
C_DecryptUpdate
C_DecryptFinal
メッセージダ C_DigestInit
イジェスト関
数
C_Digest
C_DigestUpdate
C_DigestKey
C_DigestFinal
署名と MAC
関数
C_SignInit
C_Sign
C_SignUpdate
C_SignFinal
C_SignRecoverInit
C_SignRecover
署名と MAC C_VerifyInit
の検証関数
C_Verify
C_VerifyUpdate
C_VerifyFinal
C_VerifyRecoverInit
C_VerifyRecover
目的暗号関数
C_DigestEncryptUpdate
C_DecryptDigestUpdate
C_SignEncryptUpdate
C_DecryptVerifyUpdate
鍵管理関数
C_GenerateKey
C_GenerateKeyPair
C_WrapKey
13
説明
単数ブロックの復号を行う
複数ブロックの復号を継続する
複数ブロックの復号を終了する
メッセージダイジェスト化処理の初
期設定を行う
単数ブロックのデータをメッセージ
ダイジェスト化する
複数ブロックのメッセージダイジェ
スト化を継続する
複数ブロックのメッセージダイジェ
ストを継続する
複数ブロックのメッセージダイジェ
スト化を終了する
署名処理の初期設定を行う
単数ブロックの署名を行う
複数ブロックの署名を継続する
複数ブロックの署名を終了する
データ復元可能な署名の初期設定を
行う
復元可能な単数ブロックデータの署
名を行う
検証処理の初期設定を行う
単数ブロックの署名検証を行う
複数ブロックの署名検証を継続する
複数ブロックの署名検証を終了する
データ復元可能な署名検証の初期設
定を行う
復元可能な単数ブロックデータの署
名検証を行う
複数ブロックの同時ダイジェスト化
と暗号化を継続する
複数ブロックの同時復号とダイジェ
スト化を継続する
複数ブロックの同時署名と暗号化を
継続する
複数ブロックの同時復号と検証を継
続する
プライベート鍵を生成し、新規オブジ
ェクトを作成する
公開・プライベート鍵ペアを生成する
鍵のラップを行う
分類
乱数生成関数
関数名
C_UnwrapKey
C_DeriveKey
C_SeedRandom
C_GenerateRandom
並列関数の制 C_GetFunctionStatus
御関数
C_CancelFunction
説明
ラップ化された鍵のアンラップを行
う
基本鍵から鍵を導出する
トークンの乱数生成器に、初期化用の
値を設定する
乱数または擬似乱数を生成する
並列実行中の関数状態を取得するた
めの関数
（以前のバージョンで使用された関
数。現在は、常に戻り値
CKR_FUNCTION_NOT_PARALLE
L である）
並列実行中の関数を停止する関数
（以前のバージョンで使用された関
数。現在は、常に戻り値
CKR_FUNCTION_NOT_PARALLE
L である）
3.3.2 暗号メカニズム
PKCS #11 で実装可能な暗号メカニズムは、177 個と多い。ただし、注意として、
Diffie-Hellman 演算のように、鍵ペア生成に使用される暗号メカニズム
(CKM_DH_PKCS_KEY_PAIR_GEN) と、鍵導出に使用される暗号メカニズム
(CKM_DH_PKCS_KEY_DRIVE)とを、別のメカニズムと規定する演算もある。
3.4
実装の留意点
PKCS #11 準拠のライブラリを使用してライブラリを実装する場合、以下の点を留
意すべきである。また、以下の点はアプリケーションを作成する場合でも留意すべき
事項に挙げられる。
3.4.1 Cryptoki における留意点
Cryptoki を利用する場合の留意点をいくつか挙げる。
1. Cryptoki で扱えるスロットは、C_Initialize 関数の実行時に確定される。その
ため、C_Initialize 関数実行後に R/W をマシンにつないでも、Cryptoki では認
識されない。認識させるには、再度 C_Initialize 関数を実行する必要がある。
R/W と IC カードが一体化したトークンを利用する場合、注意が必要である。
14
2. 暗号処理用の関数は、初期化用（Init 関数）
・実行用・終了用（Final 関数）の
3 種類が規定されている。ただし、単数ブロックを暗号処理する場合は、終了
用（Final）の関数を実行する必要はない。
3. C_GetSlotList 関数や暗号用の関数（例えば、C_Encrypt 関数）において、関
数実行後に取得できる値が複数個の場合がある。そのためにそれらの関数にお
いて、初めに個数のみを取得し、取得する領域を確保した後、値を取得するよ
う規定されている。
3.4.2 動作環境における留意点
PKCS #11 の目標として、『特定の機種に依存しない暗号製品の開発促進』が挙げ
られる。そのため、PKCS #11 準拠のライブラリの実装には、動作対象 OS の知識が
必要で、それらの OS 上で正常動作することを考慮している。また、PIN のキャッシ
ュ等、エンドユーザへの利便性を考慮した設計もライブラリの特長として挙げられる
だろう。
3.4.3 PKI ライブラリの実際
PKCS #11 の仕様は、セキュリティフレームワークで十分発揮できるものであり、
PKCS #11 準拠のライブラリを利用できれば十二分にセキュリティ機能が満たせる。
しかし前述したように、ライブラリを実装するには OS の知識等が必要なため、実装
完了まで長期間を有すると予想される。ただ、一部の実装で PKI ライブラリの役割
を果たせる場合が多いため、ライブラリ開発サイドの目的意識や相互運用性への配慮
等に、実装される機能は依存されるだろう。そのためアプリケーションベンダーは、
利用する PKI ライブラリの実装機能（製品仕様など）に留意する必要がある。また
PKCS #11 では、ライブラリのファイルについて規定がない（推奨しているのみ）た
め、ファイル名などにも留意が必要である。
一般的に Windows が使われる環境が多いため、Windows にプレインストールされ
る Internet Explorer やスマートカードログオンの利用者が多いと予想される。
Internet Explorer やスマートカードログオンは CryptoAPI を PKI ライブラリとして
使用するため、１つのトークンを利用して、CryptoAPI 仕様のアプリケーションと
の相互運用が可能であることを特長に挙げる PKI ライブラリも存在している。
3.5
暗号処理アルゴリズムの一例
PKCS #11 に基づいた暗号処理アルゴリズムの一例として、データオブジェクトを
トークン内に作成し、既に格納されている鍵オブジェクトで暗号化を行う場合の例を
表 3-4に示す。
15
表 3-4 処理手順
順番
処理内容
1 Cryptoki の初期化
2 スロットに挿入されているトークンを検出し、
それらのスロットを ID として取得する。
3 新しいセッションを開き、セッションハンドル
を取得する。
4 ログイン処理を行う。その際、取得したセッシ
ョンハンドルと、PIN を引数として指定する。
5 データオブジェクトの作成。その際、セッショ
ンハンドルと、オブジェクトの属性を引数とし
て指定する。
6 トークン内の鍵オブジェクトを検出するに当た
り、そのオブジェクトの属性（例えば、Object
Identifier）を指定する。その際、セッションハ
ンドルも引数として指定する。
7 指定された属性のオブジェクトを検出する。そ
の際、セッションハンドルと、検出する最大個
数を引数として指定すると、オブジェクトのハ
ンドルが取得される。
8 検出の Finalize。その際、セッションハンドル
を引数として指定する。
9 暗号化の初期化。その際、セッションハンドル
と、検出した鍵オブジェクトのハンドルと、使
用する暗号メカニズムを引数として指定する。
10 作成したオブジェクトの Value 属性（データ）
に対し、暗号化を行う。その際、セッションハ
ンドルも引数として指定する。
11 ログアウト。その際、セッションハンドルを引
数として指定する。
12 セッションハンドルを引数として指定し、セッ
ションを閉じる。
13 Cryptoki の Finalize
16
使用する関数
C_Initialize
C_GetSlotList
C_OpenSession
C_Login
C_CreateObject
C_FindObjectsInit
C_FindObjects
C_FindObjectsFinal
C_EncryptInit
C_Encrypt
C_Logout
C_CloseSession
C_Finalize
4 CSP (Cryptographic Service Provider)
4.1
CSP 概要
4.1.1 CryptoAPI について
CryptoAPI は Microsoft 社が定めた暗号機能を提供する API で、暗号化や復号演
算、デジタル署名の生成と検証などの機能を提供するものである。CryptoAPI は
Microsoft 社が 1996 年に発表した「MISF: Microsoft Internet Security Framework」
のベースとなる技術であった。アプリケーション、システム、CSP の三層から成る構
造をしており、CSP によって暗号化機能が提供される仕組みをとっているため、暗号
技術の進化や輸出規制への対応を容易に行うことが可能である。
4.1.2 CSP について
CSP（Cryptographic Service Provider）は暗号機能やデジタル署名生成機能がモ
ジュール化されたソフトウェアである。Windows にはデフォルトで数種類のタイプ
の CSP がインストールされており、CryptoAPI 経由でその機能を呼び出すことがで
きる。また、CSP は開発ツールである CSPDK（CSP Development Kit）を Microsoft
社より入手することにより、ベンダーが独自に開発することも可能である。IC カー
ドの持つ暗号機能を利用した、IC カード用の CSP が数多く開発されている。CSP は
実装すべきインターフェイスが規定されているだけであり、その実装方法はソフトウ
ェア、ハードウェアを問わず自由である。
4.1.3 CryptoAPI のシステムアーキテクチャ
CryptoAPI は暗号関連の操作に関する機能を提供しており、機能別に分類すると表
4-1のようになる。これらの関数と CSP との関係について説明する。
表 4-1 CryptoAPI 関数群
関数群
Base
cryptograp
hic
functions
Certificate
encode/dec
関数の接頭辞
Crypt
Crypt
説明
CSP に接続するための関数である。アプリケーシ
ョンは CSP 名を指定することで、接続する CSP
を決定することが可能である。
証明書のエンコード、デコードを行うための関数
である。
17
関数群
ode
functions
Certificate
store
functions
Simplified
message
functions
Low-level
message
functions
関数の接頭辞
説明
Store
証明書のコレクションを管理するための関数で
ある。
Message
メッセージやデータを暗号化/復号、デジタル署名
生成、デジタル署名の検証を行うための関数であ
る。
Simplified message functions で呼び出される関
数である。低レベル関数であるためフレキシブル
であるが、まとまった機能を実現するためにはよ
り多くのファンクションコールを必要とする。
Msg
図 4-1に示す通り、アプリケーションはこれらの CryptoAPI 関数を呼び出して利
用することが可能であるが、CSP の関数をダイレクトにコールすることはできない。
CSP と通信する際には必ず Base cryptographic functions を経由することになる。
Base cryptographic functions には、使用する CSP を指定するパラメータが用意され
ており、接続先 CSP を指定して CSP と通信を行うことになる。このパラメータが省
略された場合は、デフォルトの CSP が選択されることになる。
図 4-1 CryptoAPI のシステムアーキテクチャ
18
4.1.4 CryptoSPI と CryptoAPI の関係
本節では4.1.3節の仕組みをより詳しく説明する。
主にセキュリティ面での理由により、アプリケーションはダイレクトに CSP と通
信することはできない仕組みになっている。このため、アプリケーションは OS のフ
ァイルである Advapi32.dll と Crypt32.dll でエクスポートされた関数をコールし、間
接的に CSP を呼び出す仕組みを提供している。OS はアプリケーションからのファン
クションコールをフィルタリングし、適切な CSP へパスすることによって、アプリ
ケーションからは間接的にアクセスされることになる。
CSP が実装してエクスポートする関数である CryptoSPI と CryptoAPI は１対１に
対応している。対応関係にある関数は、関数名の接頭辞（CryptoSPI の接頭辞は「CP」
であり、CryptoAPI の接頭辞は「Crypt」である）を除いた名称が一致している。
例えば CryptoAPI の CryptAcquireContext()に対応する CryptoSPI 関数は
CPAcquireContext()である。
図 4-2 CryptoAPI と CryptoSPI の関係
19
4.1.5 CryptoSPI について
表 4-2に示す 23 の関数は、CSP で実装しエクスポートしなければならない関数で
ある。
表 4-2 CSP がエクスポートすべき関数（必須）
CryptoSPI
CPAcquireContext
CPCreateHash
CPDecrypt
CPDeriveKey
CPDestroyHash
CPDestroyKey
CPEncrypt
CPExportKey
CPGenKey
CPGenRandom
CPGetHashParam
CPGetKeyParam
CPGetProvParam
CPGetUserKey
CPHashData
CPHashSessionKey
CPImportKey
CPReleaseContext
CPSetHashParam
CPSetKeyParam
CPSetProvParam
CPSignHash
CPVerifySignatur
e
説明
指定されたコンテナに対する鍵ハンドルを取得する
ハッシュオブジェクトを生成する
データの復号を行う
ハッシュデータを使ってセッション鍵を生成する
ハッシュオブジェクトを破棄する
鍵オブジェクトを破棄する
データを暗号化する
暗号鍵をエクスポートする
鍵を生成する
乱数を生成する
ハッシュオブジェクトのパラメータを取得する
鍵オブジェクトのパラメータを取得する
プロバイダーオブジェクトのパラメータを取得する
不揮発な鍵ペアのハンドルを取得する
ハッシュオブジェクトにデータをセットする
ハッシュオブジェクトに鍵をセットする
鍵をインポートする
CPAquireContext で生成したコンテキストを破棄する
ハッシュオブジェクトにパラメータをセット
鍵オブジェクトにパラメータをセット
プロバイダーオブジェクトにパラメータをセット
ハッシュオブジェクトにデジタル署名する
デジタル署名データの検証を行う
表 4-3に示す 2 つの関数はオプショナルであり、CSP のプロバイダータイプが
PROV_RSA_SCHANNEL か PROV_DH_SCHANNEL の場合に実装しなければならない。
表 4-3 CSP がエクスポートすべき関数（オプショナル）
CryptoSPI
説明
CPDuplicateHash ハッシュオブジェクトのコピーを生成する
CPDuplicateKey 鍵オブジェクトのコピーを生成する
20
4.1.6 CSP のプロバイダータイプについて
CSP には、サポートするアルゴリズムや用途に応じてプロバイダータイプが用意さ
れている。
プロバイダータイプは以下に示す 10 種類が予め定義されているが、CSP 開発者が
新しいプロバイダータイプを定義してもよい。
1. PROV_RSA_FULL
2. PROV_RSA_AES
3. PROV_RSA_SIG
4. PROV_RSA_SCHANNEL
5. PROV_DSS
6. PROV_DSS_DH
7. PROV_DH_SCHANNEL
8. PROV_FORTEZZA
9. PROV_MS_EXCHANGE
10. PROV_SSL
21
4.2
IC カードを使った CSP の開発留意点
4.2.1 暗号ロジックの実装方法
IC カードを使った CSP を開発するに当たり、IC カードで利用不可能な暗号機能を
ホスト側で動作するソフトウェアから調達することとし、必ずしもサポート予定のア
ルゴリズム全てを開発する CSP 自身で実装する必要はない。
この場合は図 4-3に示すように、Windows にプリインストールされている CSP を
呼び出すような構成としてもよい。また、ホスト側で実行しても安全な暗号演算（ハ
ッシュ値の生成など）は、たとえ IC カードで実装されていたとしても、存在するな
らば、プレインストールされているホスト上の CSP をコールして処理させることで
実行効率が向上する場合もある。
このように、ホスト上の CSP を利用することでサポートするアルゴリズムを増や
すことが可能になるが、暗号鍵の管理など IC カード外での処理となるためセキュリ
ティ面で問題がないか注意する必要がある。
図 4-3 プリインストールされている CSP をコール
22
4.2.2 マルチアプリケーション環境での利用
複数のアプリケーションから同時に IC カードが利用されることを想定する必要が
ある。例えば、Internet Explorer でセキュリティにより保護された Web ページを SSL
で閲覧しつつ、Outlook Express で S/MIME を行うなど、ごく普通に行われる。こ
のため、仮に CSP が他の IC カードとの接続を許さないいわゆる排他モードで接続す
るように実装されていると、他のアプリケーションから IC カードを利用できなくな
る可能性がある（図 4-4参照）。
利用される環境によって、排他モードで接続する／しないを決める必要性がある。
排他処理を行わない場合、他のアプリケーションが IC カードの状態をどのように変
更するかが不明である。よって IC カードの状態が前回のアクセス終了時から変化し
ていないと想定して動作させるような実装では正常に動作しないため、注意が必要で
ある。
図 4-4 共有、排他モードで IC カードと接続
23
4.2.3 PIN のキャッシュ
複数のアプリケーションから IC カードにアクセスされると、セキュリティステー
タスなどのセッションごとのセキュリティ情報が変更される可能性がある。このため、
セキュリティフリーでないコマンドを実行するためには PIN による認証がその都度
必要になってしまい、ユーザが何度も PIN を入力しなければならなくなってしまう。
ユーザの PIN 入力回数を少なくするために、例えばユーザが入力した PIN を CSP
がキャッシュしておき、必要に応じて自動的に IC カードに対して Verify コマンドを
実行するような仕組みが必要となる（図 4-5参照）。
ただし、共有モードで IC カードに接続している状態で特定のアプリケーションが
Verify コマンドに成功すると、他の CSP を呼び出すアプリケーションも同じセキュ
リティレベルで IC カードにアクセスできてしまうことに注意しなければならない。
これを防ぐためには、上位アプリケーションが PIN を開錠したアプリケーションか
どうかを判断するなどのロジックを入れる必要がある。
図 4-5 PIN をキャッシュして自動的に Verify 実行
24
4.2.4 証明書のキャッシュ
PKI 技術を使ったシステムやアプリケーションでは、公開鍵を使ったデジタル署名
検証を行うために、IC カードから証明書データを読み出すことがよくある。X.509
形式の証明書データサイズは特殊なオブジェクトを含まなければ通常 1~2KByte 程
度である。ISO 準拠の IC カードの場合、デフォルトの通信速度は 9600bps であるた
め、単純計算で証明書の読み出しに 1~2 秒要することになる。さらに R/W ドライバ
や APDU 変換などのソフトウェアの処理、環境によっては、証明書データを複数回
に分けて読み出すこともあるため、実際には 3~4 秒程度を要することが多い。
IC カード内の証明書を読み出す場合は、利便性を損なわない様に工夫することも
必要となってくる。
4.2.5 証明書の登録
Internet Explorer や Outlook Express で SSL や S/MIME を行うためには、証明
書がローカルストア（レジストリ）に登録されていなければならない。つまり、IC
カード内に証明書とプライベート鍵が格納されていて、CSP が正しくインストールさ
れていたとしても、その証明書がローカルストアにコピーされていなければ利用でき
ないことになる。このため IC カード用の CSP を開発する場合には、証明書取得時に
レジストリにも証明書が登録されるような実装とするなどの工夫が必要である。
しかし、証明書を取得した PC と異なる PC で IC カードを利用する場合、ローカ
ルストアには証明書が登録されていない。この場合、何らかのツールを利用してカー
ド内の証明書を読み出してレジストリへ登録する仕組みが必要である。例えば常駐プ
ログラムが IC カードの挿入を検知して、自動的に証明書を登録する方法などが考え
られる。
4.2.6 証明書の利用
Internet Explorer や Outlook Express の機能を利用すると、ローカルストアに登
録された証明書の内容確認や削除を行うことができる。この時、IC カードを R/W に
挿入していたとしても、IC カード内に格納された証明書は表示されない。これは IC
カード用の CSP 等、追加インストールした CSP を Internet Explorer が呼び出さな
いためである。このため、IC カード用の CSP をインストールしただけでは、IC カー
ドのメンテナンスができないため、専用のツールをあわせて用意する必要がある。
25
4.2.7 レジストリ登録情報
CSP や IC カード、R/W に関する情報はレジストリに登録しておく必要がある。こ
の処理は通常 CSP のインストーラーによって行われる。
a) HKLM¥SOFTWARE¥Microsoft¥Cryptography¥Calais¥SmartCards にはカ
ードの ATR、ATR マスク、対応する CSP 名を登録する。
CSP 名は CryptoAPI で CSP を呼び出す際に指定する CSP の名称である。
b) HKLM¥SOFTWARE¥Microsoft¥Cryptography¥Defaults¥Provider には
CSP 名、CSP のプロバイダータイプ、CSP の格納場所（パス）、署名が登録さ
れる。
以下にこれらのレジストリ情報を利用して、カード挿入時に自動的に対応した CSP
が選択され呼び出される手順の一例を示す。
1. カードが R/W に挿入されると ATR がカードから出力される。
2. この ATR 情報をキーにして上記a)のレジストリ情報を検索し、挿入されたカー
ドに対する CSP 名を決定する。
3. この CSP 名を指定して CryptoAPI を呼び出せば、挿入されたカードにマッチ
した CSP が起動される。
4. この際、上記b)のレジストリ情報から CSP の実体とその署名データが得られ、
CSP の正当性もシステムによって検証される。
4.2.8 仕様書、参考資料
CSP で実装する関数については MSDN に全て記載されている。しかし、サポート
すべきフラグなどの情報に関しては MSDN で全て網羅されていないのが現状である。
最新の Platform SDK に含まれているヘッダファイル等を参考にしつつ情報を取得
することも必要である。また、CSP の開発についての不明点は CryptoAPI のメーリ
ングリストへ投げかけてみるのもよい方法である。
（http://discuss.microsoft.com/archives/cryptoapi.html）
26
5 PKCS #11 と CSP の相互運用
5.1
IC カード内のファイル構造共通化
CSP で利用する IC カードには、コンテナの情報、プライベート鍵、証明書が関連
付けられて保管され、これらの情報が CSP から容易にアクセスできるようになって
いることが望ましい。一方、PKCS #11 ではデータオブジェクトに対するアクセスが
容易であることが重要である。
容易かつ高速にアクセスするためには、極力不要なデータにアクセスすることなく
目的のデータを取り出したり書き込んだりできなければならない。しかし、両ライブ
ラリからのアクセス性だけを考えると、占有するメモリ領域が増大することになって
しまうため、IC カード内のファイル構造を設計する際には注意する必要がある。
5.2
キャッシュされた PIN の共有化
CSP や PKCS #11 を使って IC カードにアクセスする場合、マルチアプリケーショ
ン環境で動作させることが前提となる。CSP 開発留意点で述べたように、他のアプリ
ケーションが IC カードの状態を変化させる可能性があるため、CSP や PKCS #11 で
PIN をキャッシュしておき、必要に応じて IC カードに対して Verify コマンドを実行
しなければならない。
利用者の利便性のみを考えれば、IC カードに対して一度 PIN による本人確認が行
われたら、以後 IC カードが引き抜かれるまでは、どのアプリケーションで IC カード
を利用しても PIN 入力を要求されないことが望ましい。
しかし、仮に CSP や PKCS #11 をアクセスするような不正なプログラムがインス
トールされていたならば、キャッシュされた PIN を使われて、勝手にデジタル署名
が実行されるといったことも起こり得る。このようなことを防止するために、例えば
キャッシュされた PIN にアクセス可能なアプリケーションを予め登録しておき、そ
れ以外のアプリケーションからのアクセスは排除するなどの仕組みをあわせて実装
する必要があるだろう（図 5-1参照）。
また、このような構成とすると、一部 CSP と PKCS #11 で共通のモジュールを使
用することになるため、例えばコマンド伝送ロジックなど共通で利用可能な機能をこ
のレイヤで実装すれば開発工数を短縮できるといったメリットがある。
27
図 5-1 PIN キャッシュ共有と不正プログラム排除
また、PIN をキャッシュする単位はアプリケーション毎にという考え方もある。こ
れは IC カードを利用するアプリケーションに対して、最初の１回だけは PIN を入力
するというものである。この場合、ユーザは利用するアプリケーション毎に PIN を
入力する必要があるが、不正なアプリケーションが勝手にキャッシュされた PIN を
使用することはできなくなる。また、利用可能なアプリケーションなどを予め登録し
ておく必要もない。この場合、PIN を CSP に送ってきたアプリケーション（つまり
ユーザが PIN を入力したアプリケーション）の情報を PIN のキャッシュとともに記
憶しておけばいいだろう。
図 5-2 アプリケーション毎に PIN キャッシュ
いずれの場合においても、キャッシュする PIN は平文のままメモリに展開してお
くと、メモリダンプを行う不正プログラムによって容易に盗聴されてしまう可能性が
28
ある。PIN は暗号化して保管し、使用後はクリアするなどの対策が必要である。
5.3
データの差異の吸収
CSP 固有の概念として「コンテナ」と「鍵のスペック」がある。コンテナはプライ
ベート鍵と証明書を格納するための論理的な器であり、鍵のスペックはその鍵の用途
に応じてつけられるフラグである。鍵のスペックには鍵交換用とデジタル署名用の 2
種類が用意されている。
コンテナ名は PKCS #11 を使ったアプリケーションからは指定されることはない
ので、CSP を実装する上では指定されない場合の発生方法に注意する必要がある。鍵
のスペックも同様に、指定されないため CSP 自身で鍵交換用／デジタル署名用のい
ずれかを決定する必要がある。
コンテナ名は基本的にはユニークであれば問題ないため、UUID などを生成して設
定しておけばいいだろう。鍵のスペックについては、証明書の Key Usage をチェッ
クすることで、証明書の用途を判断するといったことも可能である。
5.4
属性証明書の扱い
PKCS #11 には属性証明書として利用するための識別子が予め用意されている。よ
って独自拡張することなく、属性証明書に対応した PKCS #11 を開発することが可能
となる。一方、CSP は暗号鍵と公開鍵証明書を扱うことに特化したライブラリであり、
属性証明書を扱うための仕組みは提供されていない。CSP では未定義のデータや汎用
データを扱うことや上記に挙げた固有の概念があるため、属性証明書に対応させるこ
とは難しい。
29
6 PKCS #15
3∼5章では、IC カードと PKI アプリケーション間の互換を担うミドルウェアにつ
いて説明した。本章では、IC カード内のファイル構造に関する標準化について、PKCS
#15 を説明する。
6.1
PKCS #15 の背景・目的
PKCS #15 は「Cryptographic Token Information Format Standard」（トークン
情報のフォーマットの標準）といわれており、IC カード内のファイル構造の標準フ
ォーマットを規定する。策定背景について以下に記す。
本人認証に利用されるデバイスとして IC カードが代表に挙げられ、カードベンダ
ーは開発を進めている。しかし認証機能の向上に注力が注がれたため、互換性の面で
懸念事項が挙がっている。まず 1 点目として、証明書（credential）を格納するため
の共通フォーマットの標準化がされていない。そのため、ベンダー独自の仕様で開発
を進める必要がある。2 点目として、証明書（credential）を多数のアプリケーショ
ンに適用するメカニズム（共有化のメカニズム）がまだ固定されていない。そのため、
証明書を利用できるサービスが限定され、利用者にとっては不便な場合がある。
これらの懸念事項を背景に、証明書利用の観点から、ベンダーとエンドユーザ双方
の利益を考慮した上で、PKCS #15 では以下の項目を目標に挙げ、
「トークン上のセ
キュリティ情報格納先のファイル／ディレクトリの標準フォーマット」を規定する。
1. 様々なプラットフォームで動作すること
2. 多くのベンダーが作成したアプリケーションで利用できること
3. 環境に応じてアプリケーションを作成し直さなくても良いこと
4. 関連する標準規格などに応じて整合性が取れるように整備できること
現在の最新バージョンは 1.1 である。そしてこのバージョンの PKCS #15 を元に国
際規格の ISO/IEC 7816-15「Cryptographic information application」が現在作成中
である。
本章では、バージョン 1.1 に基づき記述していく。
6.2
PKCS #15 の考え方
PKCS #15 の考え方を記すにあたり、IC カード内のファイル構造について簡単に
述べる。IC カード内では、IC カード内のファイルと、鍵や証明書といった概念との
関連付けが行われる。そこで PKCS #15 では、IC カード内のデータを「オブジェク
ト」として、実際のファイルと関連付けている。具体的には、ASN.1 でファイル／デ
ィレクトリを記述することを提案する。
30
また、様々なメディアに対応できるよう動的なファイル構造にする等の特徴のため、
PKCS #15 では「Directory File」を宣言する。「Directory File」とは、カード内の
オブジェクトと実際のフォーマット（ファイルやディレクトリ）をつなぐレイヤであ
る。「Directory File」も ASN.1 で記述される。
以下、オブジェクトとファイル構造のモデルの説明を行う。
6.2.1 オブジェクトについて
(1) オブジェクトのクラス
一般的な 4 種類のクラス：鍵オブジェクト、証明書オブジェクト、認証用オブジ
ェクト、データオブジェクトを定義する。そして、4 つのクラスはそれぞれサブク
ラスを持つ。そのサブクラスの実体が、カード内のファイルに相当する。
(2) 属性のタイプ
全てのオブジェクトは多くの属性を持つまた、親のクラスから属性タイプを継承
する。
(3) アクセスの管理
オブジェクトの属性として、プライベートかパブリックを指定する。IC カード
の場合、プライベートオブジェクトへのアクセス制限（読み書きなどの制限）は、
認証用オブジェクトによって判断される。認証用オブジェクトの具体例としては、
PIN やバイオメトリクスのユーザ情報が挙げられる。
31
6.2.2 ファイル構造のモデル
一般的なファイル構造として、MF と呼ばれる最上位のディレクトリが存在する。
PKCS #15 では、MF 下に「PKCS #15 Application Directory」と呼ばれる、
Directory File を格納するディレクトリを規定する（図 6-1、図 6-2を参照）
。
また、「EF(DIR)」と呼ばれる、アプリケーション情報を保持するファイルもオ
プションとして規定できる。
図 6-1 カードのファイル構造
また前述したように、PKCS #15 Application Directory 下に Directory File を格
納する。
32
図 6-2 PKCS #15 Application Directory
33
6.3
PKCS #15 の機能
6.3.1 オブジェクトの管理について
オブジェクトの追加や削除が実行された場合、Directory File にも影響が及ぶため、
留意が必要である。
また、オブジェクト追加・削除が可能か否か、PIN 認証が必要な場合に正しく実施
されているかなども留意が必要である。
6.3.2 オブジェクトの追加
オブジェクトが追加される場合の一例を図 6-3、図 6-4に示す。
1. 適切な EF(Unused Space)ファイルを探す。
図 6-3の証明書ファイルを格納するエリア「Elementary files」を指し示す
EF(Unused Space)ファイル「Free space #1」である。
2. 探した EF(Unused Space)ファイルが指し示す場所に、追加するオブジェクト
を書き込む。
図 6-3の「Free space #1」が指し示す「Empty area」に書き込む。
図 6-3 オブジェクト追加の例：STEP1
3. EF(Unused Space)ファイルの内容（ポインタ）を更新し、また該当する
Directory File に、追加したオブジェクトのポインタを追加する。
34
図 6-4の「Free space #1」の指し示す場所を更新し、また「EF(CDF)」に「Cert2」
へのポインタを追加する。
図 6-4 オブジェクト追加の例：STEP2
35
6.3.3 オブジェクトの削除
オブジェクトが削除された場合は、Directory File 自体は削除されずに、更新され
るだけである。つまり、’00’の値に置き換わるか、もしくは Directory File の全体を
更新することで実現する。図 6-5、図 6-6に例を示す。
図 6-5のようなファイル構成の時に、「Cert 2」が削除された場合、以下の操作が
必要である。また以下の操作は、更新のコマンドで実現できる。
1. 「Cert 2」を指し示す「Cert 2 Info」の値を’00’にする。
2. 「Cert 2」を指し示した場所を空のエリアと見なすため、そのエリアを指す
「EF(Unused Space)」を追加する。
図 6-5 オブジェクト削除の例：削除前
図 6-6 オブジェクト削除の例：削除後
36
7 GSC-IS (Government SmartCard Interoperability Specification)
7.1
成立した背景
IC カードとコンピュータを利用した一般的なシステムは、ISO/IEC7816-4、
ISO/IEC7816-8 で規定されているような APDU を用いて通信を行っている。クライ
アントアプリケーションは低レベルなソフトウエアドライバを通して通信を行う。
IC カードはさまざまな APDU をもっており、そのクライアントアプリケーション
は、利用する IC カードに特化した実装となることが多い。
それゆえクライアントアプリケーションがサポートしない IC カードでは、動作が
不定となったり、動作しなくなる。また、IC カードを利用したクライアントアプリ
ケーションを実装するには、IC カード技術やカードがサポートする複雑な APDU を
熟知しなければならないと認識されている。
このような背景をもとに、IC カードを用いたシステムの相互互換のソリューショ
ンとして、GSA（General Services Administration）、NIST（National Institute of
Standards and Technology）によって、GSC-IS が策定されている。
本章では、2003 年 7 月に策定されたバージョン 2.1 に基づき記述していく。
7.2
GSC-IS の構成
GSC-IS はサービスコールレベルとカードコマンドレベルの 2 つのレベルで、互換
性を提供している。
1. ServiceCallLevel：
このレベルはカードの持つ機能(暗号、認証、デジタル署名)を抽象化し、
BSI(BasicServicesInterface)とよばれる API を定義している。
クライアントアプリケーションに対してサービスを提供する下位のレイヤは、
まとめて SPM(ServiceProviderModule)と呼んでいる。
これらのサービスはユーティリティ、セキュアデータストレージ、暗号サー
ビスの３つに論理的に分けられる。
SPM は IC カードと R/W のハードウェアとカードと通信するためのソフト
ウェアで成り立つ。特に SPM のソフトウェアにあたる部分を
SPS(ServiceProviderSoftware)と呼んでいる。
37
2. CardCommandLevel:
このレベルは、カードへ送る APDU を定義している。GSC-IS ではこのレベ
ルの互換性を保つために、VCEI （VirtualCardEdgeInterface）を定義してい
る。
これはカードとは独立したスタンダードな APDU からなる。
図 7-1 IS アーキテクチャモデル
BSI と VCEI によって提供される互換性を保つためには、GSC-IS では特定のデー
タセットをカードに格納することになる。これらを DM(DataModel)と呼ぶ。
データセットはコンテナとよぶストレージに格納する。
GSC-IS ではコンテナ単位でデータを管理する。それらコンテナのうちの一つは、
カード情報を識別する CCC(CardCapabilityContainer)を格納するコンテナを存在さ
せている。
この CCC を用いて、IC カード上の実装されているネイティブな APDU と GSC-IS
で VCEI を定義するスタンダードな APDU の差異を吸収している。
CCC を格納することで GSC-IS 準拠の IC カードとなる。GSC-IS では、このよう
38
に BSI と VCEI により統一的なカードデータへのアクセスを実現している。
図 7-2に GSC-IS の動作の概要を示す。
図 7-2 GSC-IS の動作
このように、CCC 内部にあるネイティブ APDU セットと GSC−IS のスタンダー
ド APDU セットを変換することで各ベンダーの IC カード間の互換性を保つようにな
っている。さらに API や IC カードの機能の利用に対し、認証を設けることも可能で
あるよう仕様が策定されている。認証については7.3 節で述べる。
なお、GSC-IS での仕様の範囲外として IC カードの初期化方法や、鍵管理、IC カ
ードと R/W の間の通信、R/W とホストコンピュータの通信としている。
39
7.3
Access Control
IC カードと SPM によって提供されるコンテナは ACR(Access Control Rules)の影
響をうける。GSC-IS 準拠の IC カードが初期化されるとき、ACR を各々のカードサ
ービスとデフォルトコンテナに対して定義する。カードレベルのサービスプロバイダ
ーはこれらの ACR を強制する責任があり、クライアントアプリケーションがアクセ
スコントロール要求を満足するまではサービスを提供してはならない。GSC-IS はク
ライアントアプリケーションに特定のサービスプロバイダーかコンテナに対する
ACR を定義することを許可している。
PIN やその他の暗号を用いてクライアントアプリケーションと IC カード間の認証
データのシーケンスを SPS が処理する。セキュリティコンテキスト確立の際に、最
初に SPS がやるべきは、BSI のレベルでの認証の構造と VCEI レベルの APDU の置
換となる。
表 7-1に BSI で利用できる ACR の定義を記載する。
表 7-1 Access Control Rules
定義
ルール
Always
Never
ExternalAuthenticate
制約事項なし
提供しない
APDU の GET CHALLENGE と EXTERNAL
AUTHENTICATE の確立が必要
PIN Protected
カレントセッション中の PIN による認証
PIN Always
PIN を常に要求する
ExternalAuthenticate or PIN
ExternalAuthenticate か PIN のどちらか一方利
用する
ExternalAuthenticate then PIN
PIN 認証後、ExternalAuthenticate を利用する
ExternalAuthenticate and PIN
PIN と ExternalAuthenticate の両方を利用する
順序は問わない
PIN then ExternalAuthenticate
ExternalAuthenticate の次に PIN 認証を行う
Secure Channel(Global Platform) Global Platform 仕様の Secure Channel 利用
UpdateOnce
オブジェクトの更新時のみ
Secure Channel(ISO)
ISO 仕様の SecureChannel 利用
これらのルールで、BSI で実装される API で利用することとなる。例えば、一般
的に利用されている PIN による CHV（CardHolderVerification：IC カード所有者認
証）の場合、クライアントアプリケーションは次の順序で IC カードとの通信にてセ
40
キュリティコンテキストを確立する。
1. gscBsiUtilConnect()を使って、論理的にカードとの接続を確立する。
2. gscBsiGcGetContainerProperties(), gscBsiGetCryptoProperties()のいずれか
を使ってカードから ACR を受け取る。
3. gscBsiUtilAcquireContext()を使って確立する。その際、BSIAuthenticator 構
造体にスマートカードサービスの ACR に基づいた設定を行う。PIN の場合、
authValue に PIN 値を、accessMethodType に PIN 認証をセットする。
4. 実際の処理をおこなう。
5. gscBsiUtilReleaseContext()で解放する。
このように IC カードに設定されている ACR を読み出して接続を確立する。その
際、別の認証方法であれば、ルールを拡張する。例えば、バイオメトリクス認証が必
要であるなら、そのようなルールを定義することになる。ACR の認証方法の中には、
PIN による認証以外にも IC カードで一般的に行なわれている ExternalAuthenticate
を用いた手法や、IC カードが Global Platform 準拠である場合に、Global Platform
の SecureMessaging を使って、セキュアに接続する方法も規定されている。
7.4
BasicServiesInterface
SPM は BSI を提供することとなっており、クライアントアプリケーションはこの
インターフェイスを介して SPM と通信を行う。BSI は以下の 23 個の API でなりた
ち、３つのカテゴリに分けられている。
表 7-2 BSI Application Interface
API
SmartCard Utility Provider Module
gscBsiUtilAcquireContext()
説明
IC カード上のターゲットコンテナ
とセッションを確立するその際、コ
ンテナの ACR に従った認証を行う
必要がある
R/W に挿入済みの IC カードとの接
続を確立する
IC カードとの接続を終了する
IC カードとの排他的なトランザク
ションを開始する
IC カードとの排他的なトランザク
ションを終了する
BSI のバージョンを返す
CardCapabilityContainerID と IC
カードの情報を取得する
gscBsiUtilConnect()
gscBsiUtilDisConnect()
gscBsiUtilBeginTransaction()
gscBsiUtilEndTransaction()
gscBsiUtilGetVersion()
gscBsiUtilGetCardProperties()
41
API
gscBsiUtilGetCardStatus()
gscBsiUtilGetExtendedErrorText()
gscBsiUtilGetReaderList()
gscBsiUtilPassthru()
gscBsiUtilReleaseContext()
説明
接続中のカードの状態を返す
他の API のエラーの詳細を取得する
利用できる R/W を取得する
生の APDU を送信する
ターゲットコンテナとのセッション
を終了する
SmartCard Generic Container Provider Module
gscBsiGcDataCreate()
選択中のコンテナに新しいアイテム
を生成する
gscBsiGcDataDelete()
あるコンテナのアイテムを削除する
gscBsiGcGetContainerProperties()
あるコンテナのプロパティを取得す
る
gscBsiGcReadTagList()
選択したコンテナのタグリストを取
得する
gscBsiGcReadValue()
あるタグの Value を取得する
gscBsiGcUpdateValue()
あるタグの Value を更新する
SmartCard Cryptographic Provider Module
gscBsiGetChallenge()
IC カードが生成する乱数を取得す
る
gscBsiSkiInternalAuthenticate()
challenge に基づいて、共通鍵暗号を
演算する
gscBsiPkiCompute()
ある AID に紐づくプライベート鍵を
用いた演算
gscBsiPkiGetCertificate()
証明書の読取
gscBsiGetCryptoProperties()
PKI プロバイダーモジュールから
ACR の受取
表 7-2の API はすべて実装することが GSC-IS では必須となっている。これ以外に
API の拡張を認めており、それらは XSI(Extended Service Interface)と呼ばれている。
様々なベンダーが実装した様々な XSI は無論互換性はない。拡張した API の例とし
て、バイオメトリクス認証を用いた API が検討されている。
42
7.5
Virtual Card Edge Interface
VCEI は 2 つの APDU コマンドのセットを持っている。一つはファイルシステム
カード用の ISO/IEC7816-4、ISO/IEC7816-8 準拠の GSC-IS セットで、もう一つは
VM カード用の VM APDU である。また VCEI は GSC-IS 準拠カードに格納されて
いる CCC と、GSC-IS APDU のマッピングを行う。
GSC-IS のスタンダード APDU は GSC-IS 準拠カード（GSC-IS 準拠ファイルシス
テムカードと VM カード）であるなら直接に実装される。いくつかのファイルシステ
ムカードは GSC-IS のスタンダード APDU とは異なるベンダー独自の APDU である
だろう。この場合、SPS がカードベンダー独自の APDU に合致するように APDU を
修正しなければならない。これを VCEI 内部で APDU をマッピングすることで解決
する。 APDU マッピングは、CCC に格納されているネイティブ APDU の記述を利
用して行う。
GSC-IS のファイルシステムカード用の APDU は、表 7-3の通りとなる。この
APDU はセキュアメッセージをサポートしていない。セキュアメッセージは
gscBsiUtilPassthru()にて利用することができる。そのときのセキュアメッセージは
Global Platform か ISO 準拠となるだろう。
表 7-3 ファイルシステム用 APDU
コマンド
Generic File Access APDUs
GET RESPONSE
READ BINARY
SELECT DF
SELECT EF UNDER SELECT DF
SELECT FILE
SELECT MASTER FILE(Root)
UPDATE BINARY
Access Control APDUs
EXTERNAL AUTHENTICATE
GET CHALLENGE
INTERNAL AUTHENTICATE
VERIFY
説明
直前に実行した APDU の結果の取得
選択済みの透過型ファイルの読取
選択中の DF の子 DF の選択
選択中の DF 内の EF の選択
ファイルの選択
ディレクトリ構造のルートか、MF ファイ
ルの選択
選択済みの透過型ファイルの更新
GET CHALLENGE と組み合わせて使う
クライアントアプリケーションをカード
内で認証する
EXTERNAL AUTHENTICATE と組み
合わせて使う challenge を生成する
クライアントアプリケーションがスマー
トカードを認証する
認証データを比較する
43
Public Key Operations APDUs
MANAGE SECURITY ENVIROMENT
PERFORM SECURITY OPERATION
セキュリティ環境の管理（設定）
セキュリティ命令の実行
VM カードの場合、表 7-3の APDU ではなく表 7-4の APDU を実装することにな
る。
表 7-4 VM カード APDU
コマンド
説明
Common Intercase Methods VM APDUs
SELECT APPLET
AID をつかってアプレットを選択する
SELECT OBJECT
アプレットの管理するオブジェクトを選
択する
GET PROPERTIES
選択済みのアプレットからプロパティの
取得
GET ACR
ACR の取得
GET RESPONSE
直前に実行した APDU の結果の取得
VERIFY PIN
globalPIN で認証する
globalPIN は root レベルの鍵である
Generic Container Provider VM APDUs
READ BUFFER
バッファを更新する
UPDATE BUFFER
バッファを読み取る
Symmetric Key Provider VM APDUs
GET CHALLENGE
EXTERNAL AUTHENTICATE と組み
合わせて使う
challenge を生成する
EXTERNAL AUTHENTICATE
GET CHALLENGE と組み合わせて使う
クライアントアプリケーションをカード
内で認証する
INTERNAL AUTHENTICATE
challenge-response 認証を行う
Public Key Procider VM APDUs
PRIVATE SIGN/DECRYPT
RSA 署名もしくはデータ暗号化を行う
44
7.6
Card Capabilities Container
IC カードの APDU の差異を吸収するために、CCC は GSC-IS 準拠カードであれば
必ず存在しなければならないものとしている。CCC は IC カードで実装されたネイテ
ィブ APDU と GSC-IS のスタンダード APDU との構文の違いを吸収できるようにな
っており、これにより、BSI と IC カードの APDU の互換性を保つ。
CCC は国際的な AID を付番しておく。
VM カード上の CCC アプレットの CCC はデフォルトコンテナとなるよう規定され
ており、ファイルシステムカードの場合は、バイナリーファイルとして CCC を実装
する。MF 直下の特定の FID をもった EF として配置する。
図 7-3 CCCEF 配置場所
CCC の探索手順についても、GSC-IS にて規定されている。ATR 直後に、VM カ
ード向けの CCC 取得方法を試みて、失敗するとファイルシステムの CCC 取得方法
を試みる。CCC が取得できない場合、コンテナがないか、GSC-IS 準拠カードでない
と判断する。
ファイルシステムカードでは Card Capability Container は EF でなければならな
い。ファイルはエンコードなしの SIMPLE-TLV データオブジェクトで構成され、構
造化シンプル TLV を使用する例外（Application CardURL と Access Control Rule
Table フィールド）がある。
45
VM カードの場合、Card Capability Container は CCC アプレットによって管理さ
れるデフォルトコンテナ（バッファ）になっていなければならない。
表 7-5 CCC フィールド
DataElement
Card Identifier
Capability Container version number
Capability Grammar version number
Applications CardURL
PKCS #15
Registered Data Model number
AccessControlRuleTable
CARD APDUs
Redirection Tag
Capability Tuples(CTs)
StatusTuples(STs)
Next CCC
Option Issuer Defined Objects
Error Detection Code
46
7.7
DataModel
コンテナのデータ要素は SIMPLE-TLV 形式で格納される。それぞれのデータオブ
ジェクトはタグと、レングス(長さ)とバリュー(値)となる。VM カードの場合、
SIMPLE-TLV 形式は、T-Buffer と V-Buffer に分かれる。
図 7-4 T-Buffer、V-Buffer
ファイルシステムカードの場合、単一のファイルで構成されたコンテナ内に
SIMPLE-TLV で格納する。ただし先頭の TLV は表()に示すような構造で格納するこ
とになっている。
表 7-6 firstTLV(ファイルシステムカード)
firstTLV
0
Tag(0xEE)
1
Length(0x02)
2
LSB(コンテナサイズの 1 桁目)
3
MSB(コンテナサイズの 2 桁目)
4
次タグ
47
8 まとめ
本報告書では、ハードウェアトークン、特に IC カードと、IC カードを利用した標
準的な API である CryptoAPI および PKCS #11 について解説した。そして米国で標
準化の検討がなされている GSC-IS の概要について触れた。また、ハードウェアトー
クン内で用いることもできるファイル構造の PKCS #15 について解説した。
各々の仕様には長所・短所があるが、それは利用されるシステムでの利便性を考え、
それぞれの仕様を実装したライブラリが選択されることになるだろう。PKCS #11 の
場合、IC カードというよりハードウェアトークン全般を包含することを狙った仕様
であり、CryptoAPI は、Windows 系 OS 上でいかに便利に利用できるかに焦点に当
てられている仕様である。例えば、Internet Explorer を利用すれば、CSP をラップ
するようなアプリケーション(ライブラリ）なしに CSP を直接呼び出せるというメリ
ットがある。対象 OS が限定されるならば、ラップするアプリケーションの開発は必
要ないため、CSP を IC カード用 API として導入したときのコストメリットが考えら
れる。PKCS #11 の場合、既存システムがこの仕様で構築されているケースがままあ
り、システム開発時の敷居が低い、という開発メリットが考えられる。証明書のハン
ドリングだけでないなら、個別データ全般を扱える仕様になっている PKCS #11 ライ
ブラリ用いたほうがよいと考えられる。電子政府等で広く利用されるのであれば、プ
ラットフォームが限定されてしまうよりも、広範囲に仕様化されている PKCS #11 の
ほうが得策であるかもしれない。
多くの場合、CSP および PKCS #11 ライブラリは、特定の IC カードおよびファイ
ル構造にそったものでしか扱えず、IC カード間での互換性が図れていない。そのた
め、このベンダーの IC カードを利用するなら、このライブラリ、逆にこのライブラ
リならこの IC カードというような、紐付けがなされているのが現状である。
GSC-IS の場合、そのような現状にある各々のレイヤの互換性をすすめるために、
IC カードをあつかうミドルウエアおよび、IC カードまで踏み込んだ仕様化がなされ
ている。レイヤの互換性の向上により、ミドルウエア開発ベンダーはビジネスチャン
スを広げるために､工夫が必要となっていく。ミドルウエア開発ベンダーは GSC-IS
で拡張が認められている拡張 API で特色を出すことや､GSC-IS の互換性認定だけで
なく外部セキュリティ評価機関での認定を受けることで､差異を出すことになるだろ
う。
GSC-IS や今回あげた他のセキュリティ API では、IC カードの初期化の方法は規
定していない。しかし GSC-IS や他のミドルウエアに関わらず、IC カードのような
ハードウェアトークンを利用する上では初期化、いわゆるパーソナライズを事前に検
討しておくべきである。例えば、プライベート鍵を格納するならば、セキュアな環境
で格納することがあげられる。個人情報の書き込みは IC カードに書き込む時点のみ
だけでなく、デリバリーまで含めたフローを検討しておく。そうすることで IC カー
48
ドを利用するシステム全体のセキュリティ性がさらに向上するだろう。
すでに､電子政府として各団体のシステム構築が進んでおり､運用も開始されてい
る。IC カードやシステム構成のなかでサーバーやユーザインタフェイスは比較的着
目されがちであるが､さらに電子政府化を進めていくためには､各団体は今回あげた
ようなセキュリティ API の利用や標準化の策定および互換性の向上などを促進して
いくべきであるだろう。
49
9 参考文献
[PKCS #11]
[PKCS #15]
[PC/SC]
[COOKBOOK]
[GSC-IS]
[ISO/IEC7816]
[MSDN]
[GP]
PKCS #11 v2.11: Cryptographic Token Interface Standard,
http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/index.html
PKCS #15 v1.1 : Cryptographic Token Information Syntax Standard,
http://www.rsasecurity.com/rsalabs/pkcs/pkcs-15/
PC/SC Workgroup Specification1.0 (Interoperability Specification for
ICCs and Personal Computer Systems),
http://www.pcscworkgroup.com/
The Smart Card Cryptographic Service Provider Cookbook,
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnscard/ht
ml/smartcardcspcook.asp
Government Smart Card Interoperability Specification Version 2.1,
http://csrc.nist.gov/publications/nistir/
ISO/IEC7816 Information technology – Identification cards – Integrated
circuit(s) cards with contacts –
http://msdn.microsoft.com
Global Platform, http:// www.globalplatform.org
50
10 用語（参考）
AID
Application Identifier：IC カード内のアプリケーションを識別する識別子。
APDU
Application Protocol Data Unit： IC カードと機器間でやりとりされるメッ
セージの構造。
ATR
Answer To Reset：接続装置から受けるリセットに対して IC カードが行う初
期応答。ISO/IEC7816 で規定されている。
Co-Processor
暗号などの処理を高速に行うための処理装置。
DF
Dedicated File（専用ファイル）：アプリケーションやサービス毎に EF をま
とめるフォルダ。
Diffie-Hellman
プライベート鍵を安全に送受信するための鍵交換の方法。
DPA
Differential Power Analysis（電力差分解析）
：演算時の消費電力変化に着目
して、鍵等の秘密情報を解析する方法。
EEPROM
Electrically Erasable Programmable Read-Only Memory：書き換え可能な
不揮発性メモリ。
EF
Elementary File（基礎ファイル）：さまざまなデータを格納するファイル。
GSA
General Services Administration：米国連邦総務庁。
MF
Master File（主ファイル）：IC カード内のファイル構造の根幹(ルート)ディ
レクトリ。
NIST
National Institute of Standards and Technology：米国商務省標準技術局。
R/W
IC カードリーダー／ライター。
SSL
Secure Socket Layer：ネットワーク上で送受信されるデータの暗号化に関す
るプロトコル。通常の SSL は、サーバー側の正当性のみを認証するものである
51
が、SSL 相互認証は、サーバーの正当性と、クライアントの正当性をお互いに
認証する仕組み。
S/MIME
Secure Multipurpose Internet Mail Extensions：電子メール等を暗号化し、
デジタル署名を添付するインターネット規格。
TLV
Tag-Length-Value：タグ、データ長、値の順番で記述される符号化規則。
USIM
Universal Subscriber Identity Module：主に携帯電話会社が発行する加入者
情報を格納した小型の IC カード。
VM
Virtual Machine：ハードウェアに依存しない仮想プラットフォーム。
52

Download Report