3 認証技術の標準化動向
3.2. 暗号クレデンシャルとハードウェアトークン
3.1.12 FINEID
FINEID[103] は、フィンランドの市民カードであり、希望者に有料で発行
される。印刷された顔写真によって身分証明書代わりになるほか、官用及び民
用のオンライン取引におけるトークン、ヨーロッパ15ヶ国域内での地域パス ポートとしても機能する。FINEIDは1999年12月から運用が開始されている。
FINEIDは、証明書に対応する私有鍵の扱いや、カード内部のフォーマット
がPKCS#15に準拠することによるICカードの相互運用性やポータビリティ
を向上させたことなどの特徴がある。こうしたことから、欧州における身分証 明書ICカード関係の標準化の、ひとつの参照モデルになっていると思われる。
FINEIDの主な仕様書と、標準等との関係は表 3-9 FINEID仕様と標準 との関係のとおりである。
表 3‑ 9 FI NEI D 仕様と標準との関係
FINEID 仕様書 FINEID についてのコメント 参照している仕様書(標準)
FINEID S1 Framework for the Electronic ID application in the smart card.
PKCS#15 v1.0、 ISO/IEC 7816-4 and ISO/IEC FDIS 7816-8
FINEID S4-1 Implementation profile 1 of the FINEID S1 specification.
FINEID S1 and RFC 2459
FINEID S4-2 Implementation profile 2 (for organizational usage) of the FINEID S1 specification.
FINEID S1 and RFC 2459
上記の様に、ISO/IEC7816-4、 7816-8などのICカードの標準に、カード 内のクレデンシャルのフォーマットとしてPKCS#15、そして証明書のフォー マット、及び、証明書プロファイルとしてRFC2459 (RFC2459の最新版は、
RFC3280)に準拠している。
公的な用途のICカードの場合、PKCS#15などの標準化した暗号クレデンシ ャルのフォーマットを使うことは非常に意味がある。ICカード自体が標準化さ れたとしても、その中のフォーマットが標準化されなければ、多くのアプリケ ーションで使用されることは難しい。ICカードに関しては、色々なアプリケー ションに依存したデータも記録されるかもしれないが、暗号クレデンシャルに 関しては標準化されたフォーマットが採用されるべきである。
実際のアプリケーションは、直接、ICカードをアクセスするのはなく、
PKCS#11などの暗号クレデンシャルをアクセスするためにAPIを介してアク
セスする。そのため、ICカード内のクレデンシャルのフォーマットを知ってい るべきプログラムは、PKCS#11のドライバなどであったりする。そして多く の場合、ICカード内の暗号クレデンシャルのフォーマットは、独自のフォーマ ットがなされ、特定のPKCS#11のドライバのようなソフトを介さなければ使 用できないという構成になっている。これは、企業内などの使用においては、
大きく問題になることは少ないが、電子政府のような用途の場合には問題が多 い。そのため、PKCS#15は、FINEIDのような公的な目的のICカードや、
PC環境以外で使用されるICカード内のフォーマットとして使用される傾向に ある。
WWW browser WWW browser
PKCS #11
PKCS #11 Microsoft
CryptoAPI Microsoft CryptoAPI
PC/SC Resource Manager PC/SC Resource Manager
ISO/IEC 7816-4 7816-8
Proprietary API Proprietary API
MF
DF
EF DF EF
EF EF DF
EF
PKCS #15 file structure S/MIME eMail
S/MIME eMail Application XApplication X
PKCS#15 support PKCS#15 support PKCS#15 support
PKCS#15 support PKCS#15 support
PKCS#15 support
図 3‑ 20 1 枚のカードによる複数のホストアプリケーションの例(FI NEI D S1 より)
FINEIDのもうひとつの特徴に、ICカード保有者のためのふたつの種類のエ
ンドエンティティ証明書と、この証明書に対応したふたつの秘密鍵(私有鍵)、 そして、ICカード保有者の信頼点の証明書が格納されていることがある。
このふたつのエンドエンティティ証明書は、ひとつは、認証用・暗号用の証 明書であり、もうひとつは、否認防止の署名のための証明書である。そして、
それぞれの証明書はX.509証明書v3フォーマットの証明書であり、クリチカ ルな鍵使用目的(keyUsage)証明書拡張を持つが、その内容が異なる。そして、
この証明書に対応したふたつのRSAの鍵がICカードに格納されるが、この鍵 の使用に異なるプロテクションが施されている。
このふたつの鍵は、別々のPINでアクセスされる。以下にFINEIDのふた つのPINと鍵、対応する証明書の鍵使用目的拡張の内容を表 3-10に示す。
表 3‑ 10 PI N、鍵と対応する証明書の鍵使用目的拡張
PIN 番号
PIN の使用内容 X.509証明書拡張 鍵使用目的
ローカルPIN グローバルPIN
PIN 1 認証と暗号の鍵
PIN1は、他のアプリケーション でも使用することができる
digitalSignature keyEncipherment dataEncipherment
グローバルPIN
(PINは、セッションで1回 だけ比較される)
PIN 2 署名鍵
PIN 2 は、他のサービスやアプ
リケーションで使用してはなら ない
nonRepudiation ローカルPIN (The PKCS#15 v1.0 Amendment 1 Draft #1 element userConsent shall be used for the corresponding private key i.e. user interaction is required for each private key operation)
PIN1は、グロバールPINが使われる。すなわち、このICカードの認証に 使われる認証のPINが一致すれば、このセッション(ログイン中)で、この鍵 を使用した署名操作や、暗号操作を行うことができる。PIN1に対応した証明 書は、認証・暗号用の証明書であり、対応したRSAの鍵も、こうした用途で 使用される。
PIN2に対応した証明書は、否認防止用の証明書であり、対応するRSA鍵も 署名操作のみが許され暗号には使用できない。PIN2はローカルPINであり、
このRSA鍵の操作のためだけに使用される。
PIN2には、PKCS#15 v1.0の改訂版(ないし、PKCS#15 V1.1)で定義され ているuserConsentという属性が付与されている。こうした場合、PIN2の認 証は、PIN2に対応したRSA鍵の署名操作の毎に認証がリセットされる。これ は、否認防止のための署名に使われる鍵の保護のための仕様だと考えられる。