第5回 電子署名導入プラン
クライアント編
吉川 満広 ネットマークス 2002/2/9 |
|
前回まではサーバ側の電子書名導入について扱った。今回はクライアント側の導入についてその使い方を含めて考えていきたい。クライアント側で電子署名を使用する場合、認証局から証明書を発行してもらう形となる。
| 電子申請などのクライアントアプリケーションに “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の基本的な機能としては、
- 暗号化
- 電子署名
- 否認防止
- その情報が漏れてはいけない
- 作成者、発行者と受取者の間で改ざんされてはいけない
- 文書の作成者および発行者を受取者が確認できる
- 特定の相手しか復号できない文書を送る
- 文書に署名したことを事後否認できない
このような機能を使用する場面をすぐに思い付く範囲で想定してみたい。代表的なものは以下のようなものである。
| 組織内での使用 | 文書の決済 | 一般的な稟議書など |
| 重要な書類への署名 | 重要な意味を持つ文書 | |
| 組織間での使用 | 契約書 | 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通信を開始する。しかし、このセキュリティの警告が出た場合にユーザーは可能な限りそのまま［はい］を選択せず証明書の表示を行い内容を確認したい。
|
 |
| 図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では、
- 文書の作成時点から改ざんがされていない
- 証明書を参照することにより作成者を特定
- 複数者の署名
- 署名の問い合わせ検証
ここでは、Word 2002を例にして実際に署名を行うところを説明しよう。
- まず、文書を作成する。文書を作成したら［ツール］-［オプション］の［セキュリティ］タブ-［デジタル署名］を選択する。
 |
| 図8 ［デジタル署名］ダイアログボックス（拡大） |
- 続いて、［追加］を選択し、［証明書の選択］ダイアログボックスを表示する。
 |
| 図9 ［証明書の選択］ダイアログボックス |
- この中から、署名を行う証明書を選択し、［OK］を押す。
 |
| 図10 ［秘密交換キーを使ってデータの署名をします］ダイアログボックス |
- 続いて、［秘密交換キーを使ってデータの署名をします］ダイアログボックスが表示され、署名を行う動作に入るので、［OK］を押す。
 |
| 図11 [デジタル署名]ダイアログボックス |
［デジタル署名］ダイアログボックスが表示され、デジタル署名が行われた。
 |
| 図12 デジタル署名が行われた文書。文書名の横に（署名済み）が表示されている |
- 続けて、署名済みの文書を変更し保存する操作を行った場合、以下のダイアログボックスが表示されデジタル署名が破棄される。
 |
| 図13 デジタル署名破棄画面 |
これにより、署名後変更があった場合、署名が破棄される機能によって改ざんの防止を行っている。
●電子メール
電子メールで暗号化や電子署名が使える。以前の掲載記事（S/MIMEでセキュアな電子メール環境をつくる！
）で詳細に説明しているのでそちらを参照していただきたい。
●Accelio Capture FormFlow
Accelio Capture FormFlow（2001年9月にジェットフォームから社名および製品名が変更）では、FormFlowから出力されたXMLに対しての署名およびその検証が行える。以前の掲載記事（PKI対応アプリケーションを検証する）で詳細に説明しているのでそちらを参照していただきたい。
●Adobe Acrobat 5
Adobe Acrobat 5は、
- 電子署名と暗号化の両方が行える
- 複数の署名が1つの文書内で可能
- 電子署名を可視化できる
- Entrustを使用すると電子署名の有効性を問い合わせられる
| 証明書の入手方法 |
●クライアント証明書の入手
ここでは、VeriSignのクラス1デジタルIDを取得する。クラス1デジタルIDは有料で取得する方法と試用版として60日間無料で使用できる証明書を取得する方法の2つある。どちらも比較的容易にデジタルIDが取得できる。
米国ベリサインからのブラウザ用クラス1デジタルID
取得方法についてのページから取得する。
 |
| 図14 取得したデジタルIDの画面(試用版なので有効期限が60日となっている) |
・VeriSignのサービスの種類
VeriSignのデジタルIDにはその用途によってクラスが分けられている。それぞれのクラスは以下のとおり。
|
|||||||
| 証明書のクラスに対応する製品サービス |
- クラス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記事一覧 |
|
||||||||||||
- Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ （2017/7/24）
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。 - WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に （2017/7/11）
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。 - Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは （2017/7/10）
代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する - 侵入されることを前提に考える――内部対策はログ管理から （2017/7/5）
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃（APT：Advanced Persistent Threat）対策の観点から考える。
 |
|
|
|
|
