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の米国およびその他の国における登録商標または商標である。

その他、本文書に記載されている会社名、商品名、製品名などは、一般に各社の商標または登録商標

または商標である。

本書では、™、©、®などを記載しない。

i

― 目 次 ―

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

ii

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

iii

― 図目次 ―

図 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

iv

― 表目次 ―

表 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

1

1 はじめに

本報告書では、ハードウェアトークンを利用するための API の標準化動向について解説する。 一般的には、トークン（token）という英単語は「しるし、象徴、証拠」という意味をもつが、ITセキュリティ分野では身許（identity）を証明するための証拠という意味で身許トークン（identity token）とうように使われる。LANの規格にトークンリング（token ring）と呼ばれるものがあるが、この場合のトークンは LAN上へのデータ送出権を表彰する「証拠」としてのデータを指しているのも、同じ用語の使い

方の類例である。 本報告書で述べるハードウェアトークンとは、トークンリングにおけるようなデー

タ（ソフトウェア）としてのトークンではなく、身許トークンとして利用しうる物理

的な装置（device）のことである。

2

2 ハードウェアトークンについて

2.1 ハードウェアトークン

ハードウェアトークンは身許トークンとしての用途から一般に携帯に便利な小型

の装置として作られ、IC カード（キャッシュカード大のプラスチック製カードに半導体集積回路（IC チップ）を埋め込み、情報を記録／処理できるようにしたもの）や USB プラグ形態をした USB キー型トークン等がある。本章ではハードウェアトークンの中でも、クレジットカードなどの金融系用途、交通系用途、携帯電話の USIMなどとして広く利用されている ICカードについて主に述べる。

PKIシステムの構築において留意しなければならないことは、プライベート鍵の漏洩を防ぐことである。PKI システムで行われているプライベート鍵の管理方法には、端末のハードディスクドライブ内にプライベート鍵を格納する、厳重にアクセス制御

されたサーバーで管理する等の方法があるが、ハードウェアトークンをプライベート

鍵の格納に用いることには二つのメリットがある。 第一に、プライベート鍵の所有者本人がプライベート鍵を携帯することが可能とな

る。公開鍵暗号におけるプライベート鍵は、その所有者を識別するためのデータであ

り、デジタル署名を生成する際の必須データである。プライベート鍵の携帯を可能と

するハードウェアトークンは、ユーザが必要なときに必要な場所で（必ずしもコンピ

ュータキーボードの前ではなく）、自分の身許を証明することを可能にし、電子商取

引など PKIの適用範囲を著しく拡大する。 第二に、ICカードのように CPU（演算処理装置）を具えたハードウェアトークンでは、デジタル署名の生成をハードウェアトークン内で行うことができ、プライベー

ト鍵の秘匿性はさらに高まる。たとえば、ハードウェアトークン内からプライベート

鍵を外に出さずにデジタル署名を生成することができるので、不正なサーバーやホス

トプログラムに対して、プライベート鍵を開示する危険を冒すことなく、身許の証明

を実行できる。 「プライベート鍵の格納場所」として使われるハードウェアトークンには、外部か

らの攻撃に対する耐タンパー性が要求される。 CPU を内蔵する IC カードでは、OS や IC カードアプリケーションに、利用者の認証やファイルへのアクセス制御などのセキュリティ機能を搭載することにより、プ

ライベート鍵のような秘密情報へのアクセス権を持たない第三者による読出しを禁

止する耐タンパー性を実現している。IC カードのセキュリティ機能は、コマンドインターフェイスを経由した通常のアクセス経路に対しては、上述のように認証機能や

アクセス制御機能で対応している。

3

近年では通常のアクセス経路以外に、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 カードアプリケーションが書き

4

込まれるため、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 カード内で実行されることが望ましい。この

5

ように、PKIに関連する重い演算処理が求められるため、利便性を損なわない処理速度を提供できる性能も ICカードと ICカードアプリケーションに求められる。

4. プライベート鍵を外部の暗号モジュールで生成し、ICカードに格納する方法もあるが、その場合、鍵生成から格納までセキュアな環境を、ICカードもサポートしなければならない。特に、証明書を読み書きするためのコマンドも必要と

なる。 接触型 IC カードの国際標準規格である ISO/IEC7816 での鍵および証明書の処理

に必要なコマンド例を表 2-1に示す。

表 2-1 鍵および証明書の処理に必要なコマンド例

用途 コマンド

ICカード内で公開鍵ペア作成 GENERATE PUBLIC KEY

ICカード内でプライベート鍵の演算 （デジタル署名の生成）

COMPUTE DIGITAL SIGNATURE

READ BINARY (バイナリーデータの読み出し）

ICカードから証明書の読み出し

READ RECORD （レコードの読み出し） WRITE BINARY (バイナリーデータの初期書き込み） UPDATE BINARY (バイナリーデータの更新） WRITE RECORD (レコードの初期書き込み） APPEND RECORD (レコードの追記）

ICカードへの証明書の書き込み

UPDATE RECORD (レコードの更新）

ICカードへの鍵の書き込み CHANGE REFERENCE DATA また、PKI 機能だけでなく、IC カードを不正な利用から守るためのコマンドも必要となってくる。 例えば、ICカード所有者の本人確認を行うことは必須だろう。ICカードは、内部に記録されているデータへアクセスするための条件を設定することができ、この条件

が満たされているかどうかがそのファイルのセキュリティステータスとして保持さ

れている。セキュリティステータスが満たされている時、そのファイルへアクセス可

能となる。現時点では、セキュリティステータスを満たすための条件として PIN 入力を行い、ICカード内に格納してある PINとの比較を行うことにより認証を行う方

6

法が一般的である。バイオメトリクスと組み合わせた方法として、指紋データ、声紋

データの認証による本人確認が行える 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カードなどのハードウェアトークンの互換性を得るために、これらのハードウェアトークン用の標準規格の利用がますます進んでい

き、整備されていくだろう。

7

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の主な目的としては、公開鍵暗号技術の実装間での互換性（トークン～アプリケーション間での互換性）が挙げられる。目標として、『特定の機種に依存し

ない暗号製品の開発促進』と『複数アプリケーションから複数トークンへのアクセス

8

可能化』を挙げる。これらの目標を達成すべく、PKCS #11では「Cryptoki（クリプトキー）」と呼ばれる標準 APIを規定し、アプリケーションに対してトークンへの共通の論理的視点を与えた。

3.2 PKCS #11の考え方

Cryptokiの一般的なモデルを記し、PKCS #11の考え方について説明する。

3.2.1 Cryptokiのシステムアーキテクチャ

PKCS #11の目標として『複数アプリケーションから複数トークンへのアクセス可能化』を挙げた。そのため、PKCS #11では「スロット」と呼ばれる概念を導入して実現を図っている。アプリケーションがトークンにアクセス（暗号処理など）する際

に「スロット」を経由すると規定している。アプリケーションはトークンにアクセス

可能なスロットを事前に検出し、トークンへのアクセスを行う。スロットの数に上限

は設けていないため、複数トークンへのアクセスが可能な仕様である。 図 3-1にモデル例を示す。

図 3-1 Cryptokiのモデル例

9

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 鍵。公開鍵、プライベート鍵、共通鍵の 3種が定義でき

る。 Certificate 証明書。公開鍵用証明書と属性証明書の 2種が定義でき

る。 Hardware Feature IC カード等のデバイスが保持しているユーザ表示用の

データ。時計オブジェクトなどがある。

10

(2) オブジェクトの属性

オブジェクトには、「属性」が設定できる。主な属性を表 3-2に記す。

表 3-2 オブジェクトの属性の代表例

属性 説明 Object Identifier （オブジェクト ID）

トークン内でユニークとす

るオブジェクトの ID 一般的な属性(例)

Value（値） オブジェクト内のデータ Token（永続的） セッションが終了しても存

在する セッションに

おける種別 Session（一時的） セッションが終了すると破

棄される 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の認証を行い、成功した場合に限り、プライベートオブジェクトへのア

クセスが可能になる。

11

(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 Cryptokiライブラリを初期化する C_Finalize Cryptokiライブラリを終了する C_GetInfo Cryptokiの一般情報を取得する

一般関数

C_GetFunctionList Cryptoki ライブラリ関数のエントリポインタを返す

C_GetSlotList システム内のスロット一覧を取得す

る スロットとト

ークン管理関

数 C_GetSlotInfo システム内の特定のスロットの情報

を取得する

12

分類 関数名 説明 C_GetTokenInfo システム内の特定のトークンの情報

を取得する C_WaitForSlotEvent スロットのイベント(トークンの挿抜

など)の発生を待つ C_GetMechanismList トークンで使用可能なメカニズム一

覧を取得する C_GetMechanismInfo トークンで使用可能なメカニズムの

情報を取得する C_InitToken トークンを初期化する C_InitPIN 一般ユーザ PINの初期化を行う

C_SetPIN 現在ログイン中のユーザの PIN 変更を行う

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 復号処理の初期設定を行う

13

分類 関数名 説明 C_Decrypt 単数ブロックの復号を行う C_DecryptUpdate 複数ブロックの復号を継続する

C_DecryptFinal 複数ブロックの復号を終了する C_DigestInit メッセージダイジェスト化処理の初

期設定を行う C_Digest 単数ブロックのデータをメッセージ

ダイジェスト化する C_DigestUpdate 複数ブロックのメッセージダイジェ

スト化を継続する C_DigestKey 複数ブロックのメッセージダイジェ

ストを継続する

メッセージダ

イジェスト関

数

C_DigestFinal 複数ブロックのメッセージダイジェ

スト化を終了する C_SignInit 署名処理の初期設定を行う C_Sign 単数ブロックの署名を行う C_SignUpdate 複数ブロックの署名を継続する C_SignFinal 複数ブロックの署名を終了する C_SignRecoverInit データ復元可能な署名の初期設定を

行う

署名とMAC 関数

C_SignRecover 復元可能な単数ブロックデータの署

名を行う C_VerifyInit 検証処理の初期設定を行う C_Verify 単数ブロックの署名検証を行う C_VerifyUpdate 複数ブロックの署名検証を継続する C_VerifyFinal 複数ブロックの署名検証を終了する C_VerifyRecoverInit データ復元可能な署名検証の初期設

定を行う

署名と MACの検証関数

C_VerifyRecover 復元可能な単数ブロックデータの署

名検証を行う C_DigestEncryptUpdate 複数ブロックの同時ダイジェスト化

と暗号化を継続する C_DecryptDigestUpdate 複数ブロックの同時復号とダイジェ

スト化を継続する C_SignEncryptUpdate 複数ブロックの同時署名と暗号化を

継続する

目的暗号関数

C_DecryptVerifyUpdate 複数ブロックの同時復号と検証を継

続する C_GenerateKey プライベート鍵を生成し、新規オブジ

ェクトを作成する C_GenerateKeyPair 公開・プライベート鍵ペアを生成する

鍵管理関数

C_WrapKey 鍵のラップを行う

14

分類 関数名 説明 C_UnwrapKey ラップ化された鍵のアンラップを行

う

C_DeriveKey 基本鍵から鍵を導出する C_SeedRandom トークンの乱数生成器に、初期化用の

値を設定する 乱数生成関数

C_GenerateRandom 乱数または擬似乱数を生成する C_GetFunctionStatus 並列実行中の関数状態を取得するた

めの関数 （以前のバージョンで使用された関

数 。 現 在 は 、 常 に 戻 り 値

CKR_FUNCTION_NOT_PARALLELである）

並列関数の制

御関数

C_CancelFunction 並列実行中の関数を停止する関数 （以前のバージョンで使用された関

数 。 現 在 は 、 常 に 戻 り 値

CKR_FUNCTION_NOT_PARALLELである）

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カードが一体化したトークンを利用する場合、注意が必要である。

15

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に示す。

16

表 3-4 処理手順

順番 処理内容 使用する関数

1 Cryptokiの初期化 C_Initialize

2 スロットに挿入されているトークンを検出し、それらのスロットを IDとして取得する。

C_GetSlotList

3 新しいセッションを開き、セッションハンドルを取得する。

C_OpenSession

4 ログイン処理を行う。その際、取得したセッションハンドルと、PINを引数として指定する。

C_Login

5 データオブジェクトの作成。その際、セッションハンドルと、オブジェクトの属性を引数とし

て指定する。

C_CreateObject

6 トークン内の鍵オブジェクトを検出するに当たり、そのオブジェクトの属性（例えば、Object Identifier）を指定する。その際、セッションハンドルも引数として指定する。

C_FindObjectsInit

7 指定された属性のオブジェクトを検出する。その際、セッションハンドルと、検出する最大個

数を引数として指定すると、オブジェクトのハ

ンドルが取得される。

C_FindObjects

8 検出の Finalize。その際、セッションハンドルを引数として指定する。

C_FindObjectsFinal

9 暗号化の初期化。その際、セッションハンドルと、検出した鍵オブジェクトのハンドルと、使

用する暗号メカニズムを引数として指定する。

C_EncryptInit

10 作成したオブジェクトの Value 属性（データ）に対し、暗号化を行う。その際、セッションハ

ンドルも引数として指定する。

C_Encrypt

11 ログアウト。その際、セッションハンドルを引数として指定する。

C_Logout

12 セッションハンドルを引数として指定し、セッションを閉じる。

C_CloseSession

13 Cryptokiの Finalize C_Finalize

17

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 cryptographic functions

Crypt CSPに接続するための関数である。アプリケーションは CSP名を指定することで、接続する CSPを決定することが可能である。

Certificate encode/dec

Crypt 証明書のエンコード、デコードを行うための関数

である。

18

関数群 関数の接頭辞 説 明

ode functions Certificate store functions

Store 証明書のコレクションを管理するための関数で

ある。

Simplified message functions

Message メッセージやデータを暗号化/復号、デジタル署名生成、デジタル署名の検証を行うための関数であ

る。 Low-level message functions

Msg Simplified message functionsで呼び出される関数である。低レベル関数であるためフレキシブル

であるが、まとまった機能を実現するためにはよ

り多くのファンクションコールを必要とする。

図 4-1に示す通り、アプリケーションはこれらの CryptoAPI 関数を呼び出して利用することが可能であるが、CSPの関数をダイレクトにコールすることはできない。CSPと通信する際には必ず Base cryptographic functionsを経由することになる。Base cryptographic functionsには、使用する CSPを指定するパラメータが用意されており、接続先 CSPを指定して CSPと通信を行うことになる。このパラメータが省略された場合は、デフォルトの CSPが選択されることになる。

図 4-1 CryptoAPIのシステムアーキテクチャ

19

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の関係

20

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 CPAquireContext で生成したコンテキストを破棄するCPSetHashParam ハッシュオブジェクトにパラメータをセット CPSetKeyParam 鍵オブジェクトにパラメータをセット

CPSetProvParam プロバイダーオブジェクトにパラメータをセット CPSignHash ハッシュオブジェクトにデジタル署名する CPVerifySignature デジタル署名データの検証を行う

表 4-3に示す 2 つの関数はオプショナルであり、CSP のプロバイダータイプが

PROV_RSA_SCHANNELかPROV_DH_SCHANNELの場合に実装しなければならない。

表 4-3 CSPがエクスポートすべき関数（オプショナル）

CryptoSPI 説 明

CPDuplicateHash ハッシュオブジェクトのコピーを生成する CPDuplicateKey 鍵オブジェクトのコピーを生成する

21

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

22

4.2 ICカードを使った CSPの開発留意点

4.2.1 暗号ロジックの実装方法

ICカードを使った CSPを開発するに当たり、ICカードで利用不可能な暗号機能をホスト側で動作するソフトウェアから調達することとし、必ずしもサポート予定のア

ルゴリズム全てを開発する CSP自身で実装する必要はない。 この場合は図 4-3に示すように、Windowsにプリインストールされている CSPを

呼び出すような構成としてもよい。また、ホスト側で実行しても安全な暗号演算（ハ

ッシュ値の生成など）は、たとえ IC カードで実装されていたとしても、存在するならば、プレインストールされているホスト上の CSP をコールして処理させることで実行効率が向上する場合もある。 このように、ホスト上の CSP を利用することでサポートするアルゴリズムを増やすことが可能になるが、暗号鍵の管理など IC カード外での処理となるためセキュリティ面で問題がないか注意する必要がある。

図 4-3 プリインストールされている CSPをコール

23

4.2.2 マルチアプリケーション環境での利用

複数のアプリケーションから同時に IC カードが利用されることを想定する必要がある。例えば、Internet Explorerでセキュリティにより保護されたWebページをSSLで閲覧しつつ、Outlook Express で S/MIME を行うなど、ごく普通に行われる。このため、仮に CSPが他の ICカードとの接続を許さないいわゆる排他モードで接続するように実装されていると、他のアプリケーションから IC カードを利用できなくなる可能性がある（図 4-4参照）。 利用される環境によって、排他モードで接続する／しないを決める必要性がある。

排他処理を行わない場合、他のアプリケーションが IC カードの状態をどのように変更するかが不明である。よって IC カードの状態が前回のアクセス終了時から変化していないと想定して動作させるような実装では正常に動作しないため、注意が必要で

ある。

図 4-4 共有、排他モードで ICカードと接続

24

4.2.3 PINのキャッシュ

複数のアプリケーションから IC カードにアクセスされると、セキュリティステータスなどのセッションごとのセキュリティ情報が変更される可能性がある。このため、

セキュリティフリーでないコマンドを実行するためには PIN による認証がその都度必要になってしまい、ユーザが何度もPINを入力しなければならなくなってしまう。ユーザの PIN 入力回数を少なくするために、例えばユーザが入力した PIN を CSPがキャッシュしておき、必要に応じて自動的に ICカードに対して Verifyコマンドを実行するような仕組みが必要となる（図 4-5参照）。 ただし、共有モードで IC カードに接続している状態で特定のアプリケーションが

Verify コマンドに成功すると、他の CSP を呼び出すアプリケーションも同じセキュリティレベルで IC カードにアクセスできてしまうことに注意しなければならない。これを防ぐためには、上位アプリケーションが PIN を開錠したアプリケーションかどうかを判断するなどのロジックを入れる必要がある。

図 4-5 PINをキャッシュして自動的に Verify実行

25

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カードのメンテナンスができないため、専用のツールをあわせて用意する必要がある。

26

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）

27

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で共通のモジュールを使

用することになるため、例えばコマンド伝送ロジックなど共通で利用可能な機能をこ

のレイヤで実装すれば開発工数を短縮できるといったメリットがある。

28

図 5-1 PINキャッシュ共有と不正プログラム排除

また、PINをキャッシュする単位はアプリケーション毎にという考え方もある。これは ICカードを利用するアプリケーションに対して、最初の１回だけは PINを入力するというものである。この場合、ユーザは利用するアプリケーション毎に PIN を入力する必要があるが、不正なアプリケーションが勝手にキャッシュされた PIN を使用することはできなくなる。また、利用可能なアプリケーションなどを予め登録し

ておく必要もない。この場合、PINを CSPに送ってきたアプリケーション（つまりユーザが PINを入力したアプリケーション）の情報を PINのキャッシュとともに記憶しておけばいいだろう。

図 5-2 アプリケーション毎に PINキャッシュ

いずれの場合においても、キャッシュする PIN は平文のままメモリに展開しておくと、メモリダンプを行う不正プログラムによって容易に盗聴されてしまう可能性が

29

ある。PINは暗号化して保管し、使用後はクリアするなどの対策が必要である。

5.3 データの差異の吸収

CSP固有の概念として「コンテナ」と「鍵のスペック」がある。コンテナはプライベート鍵と証明書を格納するための論理的な器であり、鍵のスペックはその鍵の用途

に応じてつけられるフラグである。鍵のスペックには鍵交換用とデジタル署名用の 2種類が用意されている。 コンテナ名は PKCS #11 を使ったアプリケーションからは指定されることはないので、CSPを実装する上では指定されない場合の発生方法に注意する必要がある。鍵のスペックも同様に、指定されないため CSP 自身で鍵交換用／デジタル署名用のいずれかを決定する必要がある。 コンテナ名は基本的にはユニークであれば問題ないため、UUIDなどを生成して設定しておけばいいだろう。鍵のスペックについては、証明書の Key Usage をチェックすることで、証明書の用途を判断するといったことも可能である。

5.4 属性証明書の扱い

PKCS #11には属性証明書として利用するための識別子が予め用意されている。よって独自拡張することなく、属性証明書に対応した PKCS #11を開発することが可能となる。一方、CSPは暗号鍵と公開鍵証明書を扱うことに特化したライブラリであり、属性証明書を扱うための仕組みは提供されていない。CSPでは未定義のデータや汎用データを扱うことや上記に挙げた固有の概念があるため、属性証明書に対応させるこ

とは難しい。

30

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でファイル／ディレクトリを記述することを提案する。

31

また、様々なメディアに対応できるよう動的なファイル構造にする等の特徴のため、

PKCS #15では「Directory File」を宣言する。「Directory File」とは、カード内のオブジェクトと実際のフォーマット（ファイルやディレクトリ）をつなぐレイヤであ

る。「Directory File」も ASN.1で記述される。 以下、オブジェクトとファイル構造のモデルの説明を行う。

6.2.1 オブジェクトについて

(1) オブジェクトのクラス

一般的な 4種類のクラス：鍵オブジェクト、証明書オブジェクト、認証用オブジェクト、データオブジェクトを定義する。そして、4つのクラスはそれぞれサブクラスを持つ。そのサブクラスの実体が、カード内のファイルに相当する。

(2) 属性のタイプ

全てのオブジェクトは多くの属性を持つまた、親のクラスから属性タイプを継承

する。

(3) アクセスの管理

オブジェクトの属性として、プライベートかパブリックを指定する。IC カードの場合、プライベートオブジェクトへのアクセス制限（読み書きなどの制限）は、

認証用オブジェクトによって判断される。認証用オブジェクトの具体例としては、

PINやバイオメトリクスのユーザ情報が挙げられる。

32

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を格納する。

33

図 6-2 PKCS #15 Application Directory

34

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に、追加したオブジェクトのポインタを追加する。

35

図 6-4の「Free space #1」の指し示す場所を更新し、また「EF(CDF)」に「Cert2」へのポインタを追加する。

図 6-4 オブジェクト追加の例：STEP2

36

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 オブジェクト削除の例：削除後

37

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)と呼んでいる。

38

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では、このよう

39

に 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とホストコンピュータの通信としている。

40

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 カードとの通信にてセ

41

キュリティコンテキストを確立する。 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 に従った認証を行う必要がある

gscBsiUtilConnect() R/W に挿入済みの IC カードとの接続を確立する

gscBsiUtilDisConnect() ICカードとの接続を終了する gscBsiUtilBeginTransaction() IC カードとの排他的なトランザク

ションを開始する gscBsiUtilEndTransaction() IC カードとの排他的なトランザク

ションを終了する gscBsiUtilGetVersion() BSIのバージョンを返す gscBsiUtilGetCardProperties() CardCapabilityContainerID と IC

カードの情報を取得する

42

API 説明

gscBsiUtilGetCardStatus() 接続中のカードの状態を返す gscBsiUtilGetExtendedErrorText() 他のAPIのエラーの詳細を取得する gscBsiUtilGetReaderList() 利用できる R/Wを取得する gscBsiUtilPassthru() 生の APDUを送信する gscBsiUtilReleaseContext() ターゲットコンテナとのセッション

を終了する 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が検討されている。

43

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 直前に実行した APDUの結果の取得 READ BINARY 選択済みの透過型ファイルの読取 SELECT DF 選択中の DFの子 DFの選択 SELECT EF UNDER SELECT DF 選択中の DF内の EFの選択 SELECT FILE ファイルの選択 SELECT MASTER FILE(Root) ディレクトリ構造のルートか、MFファイ

ルの選択 UPDATE BINARY 選択済みの透過型ファイルの更新 Access Control APDUs EXTERNAL AUTHENTICATE GET CHALLENGEと組み合わせて使う

クライアントアプリケーションをカード

内で認証する GET CHALLENGE EXTERNAL AUTHENTICATE と組み

合わせて使う challengeを生成する INTERNAL AUTHENTICATE クライアントアプリケーションがスマー

トカードを認証する VERIFY 認証データを比較する

44

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署名もしくはデータ暗号化を行う

45

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フィールド）がある。

46

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

47

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 次タグ

48

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 カー

49

ドを利用するシステム全体のセキュリティ性がさらに向上するだろう。 すでに､電子政府として各団体のシステム構築が進んでおり､運用も開始されてい

る。IC カードやシステム構成のなかでサーバーやユーザインタフェイスは比較的着目されがちであるが､さらに電子政府化を進めていくためには､各団体は今回あげた

ようなセキュリティ API の利用や標準化の策定および互換性の向上などを促進していくべきであるだろう。

50

9 参考文献

[PKCS #11] PKCS #11 v2.11: Cryptographic Token Interface Standard, http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/index.html

[PKCS #15] PKCS #15 v1.1 : Cryptographic Token Information Syntax Standard, http://www.rsasecurity.com/rsalabs/pkcs/pkcs-15/

[PC/SC] PC/SC Workgroup Specification1.0 (Interoperability Specification for ICCs and Personal Computer Systems), http://www.pcscworkgroup.com/

[COOKBOOK] The Smart Card Cryptographic Service Provider Cookbook, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnscard/html/smartcardcspcook.asp

[GSC-IS] Government Smart Card Interoperability Specification Version 2.1, http://csrc.nist.gov/publications/nistir/

[ISO/IEC7816] ISO/IEC7816 Information technology – Identification cards – Integrated circuit(s) cards with contacts –

[MSDN] http://msdn.microsoft.com [GP] Global Platform, http:// www.globalplatform.org

51

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は、サーバー側の正当性のみを認証するものである

52

が、SSL相互認証は、サーバーの正当性と、クライアントの正当性をお互いに認証する仕組み。

S/MIME Secure Multipurpose Internet Mail Extensions：電子メール等を暗号化し、デジタル署名を添付するインターネット規格。

TLV Tag-Length-Value：タグ、データ長、値の順番で記述される符号化規則。

USIM Universal Subscriber Identity Module：主に携帯電話会社が発行する加入者情報を格納した小型の ICカード。

VM Virtual Machine：ハードウェアに依存しない仮想プラットフォーム。