第5回 電子署名導入プラン クライアント編


吉川 満広
ネットマークス
2002/2/9
 連載ロードマップ

第1回 電子署名で何が変わる?
第2回 導入プランを立てよう!
第3回 電子署名導入プラン サーバ編その1
第4回 電子署名導入プラン サーバ編その2
第5回 電子署名導入プラン クライアント編

 前回まではサーバ側の電子書名導入について扱った。今回はクライアント側の導入についてその使い方を含めて考えていきたい。クライアント側で電子署名を使用する場合、認証局から証明書を発行してもらう形となる。

   電子申請などのクライアントアプリケーションに
 “PKI”は不可欠

 従来は証明書を使用した運用に関してはあまり現実的に語られることもなく、実際にPKIの証明書を利用した運用はそれほど普及していなかった。

 これにはいくつかの要因があると思われるが1つの大きな要因は証明書を使用できるアプリケーションが圧倒的に少なかったからではなかろうか。もう一つの要因として考えられるのはその証明書の有効範囲である。認証局から発行された証明書は、その認証局との信頼関係が成り立つサイトでしか使用できなかった。もちろん、何かトラブルが起きても法的な後ろ盾は少なかった。

 昨年5月の電子署名法施行により特定の認証局から発行された証明書には法的な責任が発生し、従来の紙での運用と同様に、電子媒体での責任範囲が明確である文書の運用も可能となってきた。

 さらに昨年より少しずつ話題が盛り上がってきている電子政府をはじめとしたe-Japan構想によりGPKI(Government PKI:政府認証基盤)が運用を開始し、その基盤の上で地方自治体や各種のアプリケーションが稼働を目標として検討が始まりつつある。そのアプリケーションにPKIが使用されるので導入された時点から個人ユーザーも含めた形で爆発的に普及すると思われる。そうなると電子申請をはじめとしたアプリケーションにPKIは不可欠となる。

 PKIを使用したクライアントアプリケーションは大きく分けると以下の2つになる。

汎用パッケージソフト(Adobe Acrobatなど)
電子申請ソフトをはじめとした専用ソフト(各組織のイントラネットで使用するシステム)

 また、汎用パッケージソフトには以下のようなものがある。

Webブラウザ(Internet Explorer、Netscape)
電子メール(Outlook、Outlook Express、 Netscape、Eudoraなど)
Office XP(Word 2002、Excel 2002、PowerPoint 2002)
Accelio Capture FormFlow
Adobe Acrobat 5

 

   クライアントで証明書を利用する場面

どのような目的で使用するか?

 クライアント側でPKIの証明書を使用する場合の目的についてあらためて触れておきたい。PKIの基本的な機能としては、

  • 暗号化
  • 電子署名
  • 否認防止
がある。いわばPKIが必要な理由は、以下のようなものである。

  • その情報が漏れてはいけない
  • 作成者、発行者と受取者の間で改ざんされてはいけない
  • 文書の作成者および発行者を受取者が確認できる
  • 特定の相手しか復号できない文書を送る
  • 文書に署名したことを事後否認できない

 このような機能を使用する場面をすぐに思い付く範囲で想定してみたい。代表的なものは以下のようなものである。

組織内での使用 文書の決済 一般的な稟議書など
重要な書類への署名 重要な意味を持つ文書
組織間での使用 契約書 NDAなど
金銭が絡む文書 見積書、発注書など
役所に提出する申請書 図1参照

図1 役所への届け出申請の流れ


 このような文書に関しては現在は紙に出力して印鑑を押す運用が主であろう。これから、GPKIの運用が拡大されて電子政府や電子自治体が実現し、法的に電子署名が現在の印鑑と同じレベルに扱われるようになれば、申請・届け出などの業務がインターネット上で行われるようになっていき、提出文書には現在の印鑑に代わるものとして電子署名が求められてくるであろう。

   使用できるアプリケーション

 以下にPKIの証明書が利用できるアプリケーションを紹介しよう。

Webブラウザ

 Webブラウザで証明書を使用する場合の一般的な方法は、第3回 電子署名導入プラン サーバ編その1で紹介したWebブラウザ側でWebサーバの証明書の発行元が存在しているかをチェックしてからSSL通信(暗号化通信)を行うというものである。このSSL通信によりWebブラウザで入力されるデータは通信経路が暗号化された状態で通信が行われる。

・信頼されたルート証明機関の場合
 信頼されたルート証明機関として一般的なものについては、Webブラウザにインストールされた時点で下記に示すように証明書がインポートされている。

図2 Webブラウザにインポートされているルート証明機関の一覧(Windows XPでのInternet Explorer 6)

図3 Webブラウザにインポートされているルート証明機関の一覧(Windows 2000でのNetscape 6.2)

 Webサーバ証明書の発行機関がWebブラウザにインポートされている証明機関の一覧に存在する場合は、自動的にサーバとクライアントの間でSSL通信が行われる。従ってユーザーは特に意識することなくSSL通信を行っていることになる。SSL通信を行っているサイトにはほとんどの場合、セキュリティについてのページがあり説明がされている。

図4 SSL通信を行っているときのInternet Explorer 6の画面(アドレスがhttpsから始まり、右下に鍵のマークが表示される)

図5 SSL通信を行っているときのNetscape 6.2の画面(アドレスがhttpsから始まり、右下に鍵のマークが表示される)

・未知のルート証明機関の場合
 信頼されたルート証明機関に含まれていないWebサーバ証明書を受け取った場合はどのようになるか見てみたい。信頼されたルート証明機関に含まれていない場合Webブラウザ側では自動的にSSL通信は始めず、ユーザーにその証明機関を信頼するかの警告を出してくる。

図5 セキュリティ警告の画面

 ここで[はい]を選択した場合、信頼されたと見なされてSSL通信を開始する。しかし、このセキュリティの警告が出た場合にユーザーは可能な限りそのまま[はい]を選択せず証明書の表示を行い内容を確認したい。

注意 組織内や関連のプライベートな認証機関で発行されたWebサーバ証明書などの場合もこの警告が表示される。

図6 証明書の情報確認画面

 ここでは、ネットマークス社内の認証局でテスト用に発行した証明書を使って実験を行った。一般的にはこの警告が出る原因としてWebサーバのなりすましなどの不正などが考えられるために注意したい。

・SSL通信のサーバ、クライアント相互認証

 SSL通信は前回(第4回 電子署名導入プラン サーバ編その2)説明している。現在一般的に使用されているSSL通信では、サーバ側に証明書がありクライアントは証明書を持っていない。しかし、クライアントが証明書を持つことにより、サーバ側でもユーザーの認証がクライアント証明書で行えるようになる。これにより認証を証明書で相互に行うため、ユーザーIDやパスワードの入力による認証に比べて格段に認証の精度が高まることになる。一般的にこれらの証明書は、各アプリケーションやシステムのアクセスコントロールとして使われることが多い。

  SSL通信に関しては認証だけに証明書を使用し、暗号化通信自体はお互いの公開鍵を使用しての暗号化ではなく、共通鍵を使用した通常のSSL通信となる。

参考 ベリサイン社のパブリック証明サービスの各水準(クラス)について

●Windows XP & Office XP

 オペレーティングシステムがWindows XPであればマイクロソフトオフィス製品の最新バージョンであるOffice XPの、

  • Word 2002
  • Excel 2002
  • PowerPoint 2002

で電子署名を行うことができる。Office XPで署名を行う場合には、署名を行う証明書をInternet Explorerにインポートしておく必要がある。

図7 インポートされた証明書の画面

 Office XPでは、

  • 文書の作成時点から改ざんがされていない
  • 証明書を参照することにより作成者を特定
という目的に使用する。署名は1名しか行えない。アドビのAcrobat 5との比較になるがAcrobat 5で行えた、

  • 複数者の署名
  • 署名の問い合わせ検証
は行えない。

 ここでは、Word 2002を例にして実際に署名を行うところを説明しよう。

  1. まず、文書を作成する。文書を作成したら[ツール]-[オプション]の[セキュリティ]タブ-[デジタル署名]を選択する。 
図8 [デジタル署名]ダイアログボックス(拡大
  1. 続いて、[追加]を選択し、[証明書の選択]ダイアログボックスを表示する。
図9 [証明書の選択]ダイアログボックス
  1. この中から、署名を行う証明書を選択し、[OK]を押す。
図10 [秘密交換キーを使ってデータの署名をします]ダイアログボックス

  1. 続いて、[秘密交換キーを使ってデータの署名をします]ダイアログボックスが表示され、署名を行う動作に入るので、[OK]を押す。
図11 [デジタル署名]ダイアログボックス

    [デジタル署名]ダイアログボックスが表示され、デジタル署名が行われた。

図12 デジタル署名が行われた文書。文書名の横に(署名済み)が表示されている

  1. 続けて、署名済みの文書を変更し保存する操作を行った場合、以下のダイアログボックスが表示されデジタル署名が破棄される。 
図13 デジタル署名破棄画面

 これにより、署名後変更があった場合、署名が破棄される機能によって改ざんの防止を行っている。

●電子メール

 電子メールで暗号化や電子署名が使える。以前の掲載記事(S/MIMEでセキュアな電子メール環境をつくる! )で詳細に説明しているのでそちらを参照していただきたい。

●Accelio Capture FormFlow

 Accelio Capture FormFlow(2001年9月にジェットフォームから社名および製品名が変更)では、FormFlowから出力されたXMLに対しての署名およびその検証が行える。以前の掲載記事(PKI対応アプリケーションを検証する)で詳細に説明しているのでそちらを参照していただきたい。

Adobe Acrobat 5

 Adobe Acrobat 5は、

  • 電子署名と暗号化の両方が行える
  • 複数の署名が1つの文書内で可能
  • 電子署名を可視化できる
  • Entrustを使用すると電子署名の有効性を問い合わせられる
など電子署名アプリケーションの中ではかなりよくできたアプリケーションである。これを使用するとPKIのアプリケーションというのはどのようなものかがよく分かる製品になっている。詳細はこちらも以前の掲載記事(Acrobat 5.0のセキュリティ)で紹介してあるので参照していただきたい。

   証明書の入手方法

●クライアント証明書の入手

 ここでは、VeriSignのクラス1デジタルIDを取得する。クラス1デジタルIDは有料で取得する方法と試用版として60日間無料で使用できる証明書を取得する方法の2つある。どちらも比較的容易にデジタルIDが取得できる。
 米国ベリサインからのブラウザ用クラス1デジタルID 取得方法についてのページから取得する。

図14 取得したデジタルIDの画面(試用版なので有効期限が60日となっている)


・VeriSignのサービスの種類
 VeriSignのデジタルIDにはその用途によってクラスが分けられている。それぞれのクラスは以下のとおり。

クラス1
クラス2
クラス3
個人ユーザー向けデジタル証明書 主にクライアント証明書(VeriSign OnSiteより発行)

Webサーバ証明書

コードサイニング証明書
証明書のクラスに対応する製品サービス

  • クラス1
    個人ユーザー向けデジタルID。Web上で取得できるデジタルIDで電子メールやAcrobat 5、Office XPなどで使用できる。メールアドレスがあれば発行されるために厳密な本人確認は行っていない。
  • クラス2
    主にクライアント証明書(VeriSign OnSiteより発行)。企業ユースとして複数で使用する場合に使うクライアント証明書。「企業認証局」を構築・運用するためのシステムとサービスを統合したソリューション。Webサーバとのクライアント認証などに使用しアプリケーションなどのアクセスコントロールにも使用できる。
  • クラス3
    Webサーバ証明書。第4回 電子署名導入プラン サーバ編その2で紹介した証明書。
    コードサイニング証明書。コードサイニング証明書は、コードやコンテンツを電子的に“シュリンク・ラップ”(包装)して、ActiveXコントロールやJavaアプレット、DLL(ダイナミック・リンク・ライブラリ)、.cab ファイル、HTMLページを安全に、しかも改変されたり、壊されたりしていないことを利用者に保証することを可能とする。

●証明書の保存

 取得したデジタル証明書は、その証明書の用途や対象となる業務によっては従来の実印と同じような効力を発揮する。従ってその証明書の保管は運用上、管理者やシステムのセキュリティポリシーにより規定される。ここでは、証明書の保存について簡単に説明したい。

・ハードディスク内
 本記事内でご紹介したVeriSignのデジタル証明書などWebで取得できるものは、その鍵の生成およびその保存媒体までは厳密に指定できない。従って、通常何も持たないでデジタルIDを取得した場合は秘密鍵はハードディスク内で生成され保存される。通常のファイルと同じ扱いになる。

 しかし、これはいつでもだれでも使えるように机の上に実印を置いているのと同じで悪意を持った第三者などにコピーされて盗用される恐れがある。デジタル証明書の用途が限定されており、あまり実害が無いもの以外はハードディスク内で秘密鍵の生成と保存を行うべきではない。

・ハードウェアトークン
 ハードディスク内の危険性はすでに述べた。ここでは、現在使用されているハードウェアトークンで比較的多く使用されている代表的なものをご紹介しよう。これらは、秘密鍵をトークン内で生成するのでトークンの管理を厳密にしておけば、盗用されたり悪用されたりすることはない。

  • ICカード
    ICカードは、GPKIにおいても秘密鍵を配布する方法で最も現実的な方法として検討されており、一部では使用され始めている。また、昨年あたりから一部のクレジットカードではICカードが標準になってきている。ICカードは、カードとカードリーダーがペアである環境が必要。
    図15 ICカード
  • USBモジュール
    USBのトークンモジュールは、基本的にはICカードと同じである。しかし、ICカードと異なりカードリーダーなどのデバイスが必要なくUSB搭載のPCであれば使用できる。また、その形状から一般的な鍵と一緒に持ち歩くことができる。

    図16 USBトークン


  • 生体認証とICカードの組み合わせ
    ICカードに生体認証を組み合わせたトークンも発売されている。証明書を格納する部分はICカードと同じである。秘密鍵を使用する場合に通常はパスワードを入力して使用するが、生体認証(この製品では指紋認証)をパスワードの代わりにして使用することも可能である。より正確な個人認証を行う場合に有効である。さらに、この製品の接続はUSBで行えるため、ICカードとUSBモジュールとを一緒にした形状になっている。
    図17 ICカードに生体認証を組み合わせたトークン

   今後のクライアントでのPKIの使用

 今回紹介してきた使用方法は、クライアントに証明書を持った場合の使用方法である。正直いって、まだ使用できるパッケージソフトも専用のアプリケーションも多いとはいえない。しかし、これからGPKIの普及などが期待され、PKIが使用できる場面は広がっていくと思われる。今のうちから情報には、敏感になっておく必要があるだろう。

 今回で、連載「電子署名導入指南」は終了致します。今後、ますますPKIの役割はクローズアップされることと思われます。また、これから注目されるGPKIなどをテーマとした企画も検討いたしますので、ご期待ください。


Security&Trust記事一覧

Index

 

第1回 電子署名で何が変わる?
  第2回 導入プランを立てよう!
  第3回 電子署名導入プラン サーバ編その1
  第4回 電子署名導入プラン サーバ編その2
第5回 電子署名導入プラン クライアント編


Security&Trust フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Security & Trust 記事ランキング

本日 月間