企業のためのPKI導入ガイド – 相互認証

相互認証とは、複数のドメインに存在する第三者認証機関(認証局)の信頼関係を拡張するものです。例えば、自分の認証局をもっている2つの取引企業は、それぞれお互いの認証局で発行された証明書が、確実なものであることを確かめたいと思っています。一方、大企業ではさまざまな地域で複数の認証局が必要になります。相互認証では、異なる認証局のドメイン同士であっても、信頼できる電子通信を確立させることができます。相互認証という言葉は、2つのオペレーションを意味します。

相互認証モデル

Bさんは①②③の信頼の道(鎖)を辿ってAさんの署名文書に付けられた証明書を確認します。

一番目のオペレーションは、一般的に稀れなことですが、2つの認証局における信頼関係の確立です。両社の相互認証を行なう場合、2つの認証局はお互いの確認キーを交換します。これらは、証明書に含まれている認証局の署名を確認するために利用されます。この作業を完了するために、それぞれの認証局が、”相互認証”と書かれた証明書にお互いの認証局の確認キーで署名します。

二番目のオペレーションは、クライアント側のソフトウェアによって行なわれます。このオペレーションは、相互認証された認証局で、署名されるユーザーの証明書が、信頼できるものかどうかを確認する機能が含まれており、”信頼の道を辿る”と呼ばれています。すなわち、一連の相互認証を確認する”鎖”が、ユーザーを確認する認証局のキーから他のユーザーの証明書を確認する認証局の鍵までを”辿って”確認するというものです。相互認証の鎖を辿ることで、それぞれの相互認証が、信頼できるものであるかどうかがチェックされます。ユーザーの証明書は破棄されることがあるので、なおさら相互認証される必要性があります。この項目は、相互認証の討議においてよく見落とされています。

第三者認証機関と相互認証についての詳細は、Entrust 社のWhite Paperの”The Concept Of Trust In Network Security”に掲載されています。このWhite Paperは当社のWebサイトでもご覧いただけます。


PKIに必要な要求事項について討議される際、クライアント側のソフトウェアの必要事項は、しばしば、忘れられがちです。(例えば、PKIが議論されるときに認証局の機能のみが注目されてしまうなど)しかしながら、最終的なPKIの価値とは、ユーザーが暗号やデジタル署名をいかに使いこなすかという点に集約されます。このことから、PKIはデスクトップ上のアプリケーション(例えば、電子メール、Webブラウザ、電子フォーム、ファイル、フォルダー、暗号化など)を終始一貫して、簡単に操作できるクライアント側のソフトウェアを含んでなければなりません。

これでPKIの費用対効果を向上させることが可能になります。さらに、クライアント側のソフトウェアは、冒頭で説明したPKIの技術的核心のすべてを技術的にサポートできなければなりません。クライアント側のソフトウェアの必要事項を要約した下記のリストは、使いやすく、わかりやすいPKI環境を獲得したい、というユーザーの要求を確実に満たすものです。

公開鍵証明書

PKI準拠の全アプリケーションは、信頼のおける第三者認証機関を信用するため、終始一貫した信頼できる方法で証明書を利用しなければなりません。クライアント側のソフトウェアは、証明書に記載された認証局の署名の信頼性を確認し、その証明書が有効であるかどうかを確認できなければなりません。

鍵のバックアップと復元

データ消失からユーザーを守るためにPKIは、復号キーのバックアップや復元を行なうシステムをサポートする必要があります。それぞれのアプリケーションが、それ自身のバックアップ・キーや復元キーを提供することは、運用コストの面から決して適切とはいえません。

それに引き換え、PKI準拠の全クライアント・アプリケーションは、一つのキーでシステムのバックアップや復元を行なうことができます。クライアント側のソフトウェアと鍵のバックアップやシステムの復旧における安全性は、確保されるべきものであり、その対応方法は、PKIに準拠する全アプリケーションと一貫していなければなりません。

否認防止機能への対応

基本的な否認防止機能をサポートするには、クライアント側のソフトウェアが、デジタル署名に利用されるキーペアを生成する必要があります。さらに、クライアント側のソフトウェアは、その署名キーが二度とバックアップされないようにして、常時ユーザーの管理下に置かれなければなりません。この種のサポートは、すべてのPKI準拠の全アプリケーション上で一貫して行なわれなければなりません。

キーペアの自動更新

ユーザーにとって使いやすい機能であるためには、クライアント側のアプリケーションは、その企業のセキュリティ・ポリシーに従って、自動的にユーザーのキーペアを更新する必要があります。ユーザー側が、いつキーが更新されるのかを知らなければならないような状態は好ましくありません。 クライアント側のソフトウェアは、PKIに準拠する全アプリケーションの要求に見合うようキーペアの更新を終始一貫して、簡単に行なわれなければなりません。

キー履歴の管理

ユーザーが暗号化データに簡単にアクセス(そのデータがいつ暗号化されたかどうかにかかわらず)できるようにするためには、PKIに準拠するアプリケーションが、ユーザーのキーの履歴にアクセスできなければなりません。クライアント側のソフトウェアは、ユーザーのキー履歴を確実に復元できる必要があります。

柔軟性のある証明書リポジトリ

証明書配信コストを最小限にするためには、PKIに準拠する全アプリケーションが、一般的で柔軟性のある証明書リポジトリを利用する必要があります。一般のリポジトリから証明書を回収できるわかかりやすいサポートにより、その有用性を向上させています。いちいち、異なる証明書リポジトリを要求するアプリケーションは、コストがかさむばかりで、大変に厄介です。

証明書の取消し

PKIに準拠するアプリケーションは、一般的で柔軟性のある証明書取消しシステムと互換性が取れていなければなりません。それは、証明書の取消しというものが、信頼性を管理する上での中核を成すためクライアント側のソフトウェアは、全アプリケーション上での終始一貫した方法によって、証明書の取消しシステムとの互換性が取れている必要があります。

相互認証への対応

終始一貫して、信頼性を管理するアプリケーションを守るには、PKIに準拠する全アプリケーションが、一般的な相互認証のモデルを適用する必要があります。前に、説明した”相互認証”では、相互認証をすることで、PKIが海外の認証局で発行された証明書の信頼性を決定付けることができることについて述べました。クライアント側のソフトウェアは、”信頼の連鎖”において、いかなる相互認証も破棄されていない、ということを確認する必要があります。

上記で取り上げられた各々の問題は、クライアント側のソフトウェアとPKIの構造要素の相互性と関連しています。クライアント側のソフトウェアには、その構造要素と独立した、もうひとつの要求事項があります。

クライアント側のソフトウェアは、例え、PKI構造から切り離された場合でも、ユーザーが情報を暗号化/復号化できるようになっています。有用性を拡大し、コストを縮小するためには、クライアント側のソフトウェアが複数のキー搭載機器(SmartCard、PC Card、Secure Fileなど)をサポートできなければなりません。ユーザーは一つのキー・ストレージで、PKIに準拠する全アプリケーショ上に署名キーで記載することができます。

ご質問・ご相談 お気軽にお問い合わせください

電話でのお問い合わせ

03-6738-6710

(平日9:00~18:00受付)

メールフォームからお問い合わせ

お問い合わせ カタログダウンロード

PKI導入ガイド

お問い合わせ カタログダウンロード

03-6738-6710

(平日9:00~18:00受付)

ページの先頭へ