セキュリティ

デジタル証明書を使用して電子メールをセキュリティで保護する

Matt Clapham and Blake Hutchinson

概要:

• 検証可能な ID を作成する
• 証明書の状態を更新する
• 証明書を取得および交換する
• S/MIME システムのトラブルシューティングを行う

数千年もの間、人類は、運送中 (送信中) の情報の秘匿、送信者の確認、およびメッセージの認証にさまざまな方法を使用してきました。文明の進化により、この 3 つの全作業を行う 1 つの方法が考案され、普及しました。それが Secure Multi-Purpose Internet Mail Extensions (S/MIME) です。

S/MIME は、暗号化とデジタル署名を使用して電子メールを安全に送信するための仕組みです。

現在の暗号化 (秘匿) 技術は 2 種類に分類できます。対称 (共通) キー アルゴリズムと非対称 (公開/秘密) キー アルゴリズムです。前者に該当するテクノロジは DES (Data Encryption Standard) や AES (Advanced Encryption Standard) で、RAS や ECC (Elliptical Curve Cryptography) は後者に該当するテクノロジです。送信者を確認する最新のツールでは、一意な署名を作成するハッシュという一方向の数学関数が採用されています。一般的に使用されるハッシュ関数は、MD5 (Message Digest Algorithm 5) と SHA (Secure Hash Algorithm) の 2 つです。コンピュータでは、これらの関数を使用して、各ソース テキストに対応する一意なハッシュを生成できます (ソース テキストが同じ場合は、生成されるハッシュも同じになります)。公開キー基盤 (PKI) システムは、このような単純なツールを組み合わせて実現されています。

検証可能な ID を作成する

証明機関の関連情報

• 暗号化ファイル サービスに証明機関を使用する
• 証明機関サーバーをリネームまたは削除できない
• ドメイン内のコンピュータから信頼された証明機関を削除する方法
• Windows エンタープライズ証明機関の使用を停止する方法と、Windows Server 2003 および Windows 2000 Server から関連するすべてのオブジェクトを削除する方法
• ドメイン コントローラで証明機関を新しいサーバーに移行する方法

PKI システムでは、ID はデジタル証明書を使用して管理されています。デジタル証明書は、大半の人が海外旅行をする際に携帯する政府が発行する身分証明書 (パスポート) とは異なります。デジタル証明書の世界でパスポートに相当する標準は X.509 形式です。この形式は、S/MIME、インターネット プロトコル セキュリティ (IPsec)、SSH (Secure Shell)、ワイヤレス ネットワーク セキュリティ、仮想プライベート ネットワーク (VPN)、セキュリティで保護されたサーバー通信 (たとえば、SSL を使用した Web サイト) などの署名テクノロジと暗号化テクノロジの両方で広く使用されています。

証明書は、非対称暗号化とハッシュをベースに作成されています。証明書を作成するには、要求側 (より信頼性の高い機関が署名したキーを必要としているエンティティ) が秘密キーを作成します。このキーは、キーの信頼性が問題になることがないように隔離します。この秘密キーと同時に対応する公開キーが生成されます。名前から推測できるように、このキー ペアの公開される側のキーは、このキーの信頼性が保証される方法で自由に配布することが可能です。

このキー ペアにより、2 つの基本的な操作が可能になります。1 つは、公開キーを使用した暗号化です (このような暗号化物の暗号化を解除するには対応する秘密キーが必要です)。もう 1 つは、秘密キーを使用した暗号化物の暗号化解除に公開キーを使用することです。これは、秘密キーを使用してでしか作成することができない署名を検証するうえで重要です。

証明機関への要求には、キーを使用するユーザーまたはコンピュータの ID、アルゴリズムの種類と強度、キー ペアの公開される側のキーなどの詳細情報が含まれます。証明機関 (CA) では、要求に含まれる情報を受信して検証し、ハッシュ アルゴリズムを使用して、その情報に対応する一意な ID を作成します。

CA では、対応する秘密キーを使用して、その情報のハッシュを暗号化し、標準的な形式 (X.509 など) にして、要求に対応する証明書を作成します。X.509 証明書には、証明書の ID (サブジェクト)、有効期間、公開キー、および許可されている証明書の目的など、権利の一覧が含まれています。作成された証明書は、要求側に返されます。証明書は、「発行元の CA は、ここに記載されたあらゆる用途に関して、この公開キーとそれに対応する秘密キーを保証します」ということを宣言している効力のある証です。

ルート CA の証明書は自己署名証明書です (ルート CA は、信頼チェーンにおける最上位レベルの CA です)。オペレーティング システムやアプリケーションには、実績のある大手の証明機関がルート CA として、あらかじめインストールされていますが、パッケージや企業の構成によって更新または変更されることがあります。ルート CA とリーフ ノード間には、1 つ以上の中間 CA が存在することがあります (通常、リーフ ノードという表現は、個人ユーザーやシステムを指して使用します)。

信頼チェーンは、すべてのノードとノードに組み込まれていて、ノードと同レベルの CA の署名が入っている上記の全証明書で構成されています。証明書を検証する必要がある第三者は、当該 CA またはユーザーの対応する公開キーを使用して証明書から暗号化解除したハッシュとローカルで計算されたハッシュを照合できます。検証に必要な作業は、それだけです。リーフからルートまでの信頼性が保証されている信頼チェーンでは、当然、ルート CA が信頼されます。

証明書の状態を更新する

優良な CA は、信頼されなくなった証明書の一覧を配布する手段を備えています。この証明書失効リスト (CRL) には、CA が明示的に失効させた証明書が記載されています。便利なことに、通常、CRL は CA 証明書のプロパティからアクセスできます。

CA では、2 つの基準で定期的に CRL を発行します。スケジュール (2 週間ごとなど) に基づいて発行する場合と、イベント (発行した証明書が信頼できなくなったことを示すイベントなど) が発生した場合に CRL を発行します。CA では、CRL の発行時に CRL に署名をします。証明書を受け取ったシステムが信頼チェーンの有効性を評価する際には、発行元 CA の CRL の取得を試行します (これには、証明書自体に含まれている詳細情報を使用するか、あらかじめ定義された信頼できる配布メカニズムを使用します)。CRL が利用できない場合、クライアント システムでは、正常にキャッシュされた最新のコピーを参照することがあります (ただし、指定された CRL 更新期間が過ぎていない場合に限ります)。この処理も行えない場合、通常、クライアント システムでは、証明書は有効であるように見えるが、失効状態を特定できないということを示すエラー メッセージが表示されます。

信頼チェーンまたは信頼チェーンの各ノードの CRL を検証できない場合、多くのアプリケーションでは、証明書の読み込みにかかる時間がかなり長くなります。証明書で保護している対象によっては、その証明書を信頼するかどうかをユーザーが判断しなければならない場合があります。定期的に更新され、広い範囲で使用できる CRL 配布ポイントは、すべての CA で必要です。特に、パブリックなルート CA では必要です。

ルート CA は証明書の信頼チェーンの基盤となり、信頼チェーンは全証明書の階層の基盤となります。多くのクライアント システムやアプリケーションでは、信頼チェーンが信頼されているルート CA まで続いている場合に限り、リーフ ノードの証明書が有効であると見なします。ルート CA は、その企業が所有して運用しているエンタープライズ CA である場合もあれば、パブリックなルート CA (VeriSign など) の場合もあります。

パブリックなルート CA の場合、完全性を保証するための専門的な運用技術が必要になります。ルート CA の信頼性は重要なので、エンタープライズ CA の運用においても同様のレベルの精度を実現するために最善の努力をする必要があります。最も強固な保護を実現するには、ルート CA は、オフラインにして、証明書の発行時と CRL の更新時にのみ使用することをお勧めします。CA の運用に関するベスト プラクティスについては、「証明書機関の関連情報」を参照してください。

キーの回復は、検討する必要がある重要事項です。企業で投資を有効活用し、データがユーザーによって回復できない状態に陥ることがないようにするには、ユーザーが発行したキーのバックアップ コピーを作成することをお勧めします。また、このようなバックアップ コピーは、安全なリポジトリに格納する必要があります。このような対策を講じると、たとえば、スマート カードをタクシーに置き忘れて、ユーザーがキーを紛失しても、そのキーで保護されているデータにアクセスすることができます。

優良な暗号化システムでは、ライフサイクル管理の概念が重要になります。コンピュータの処理速度が高くなるほど、アルゴリズムは脆弱になります。優良な暗号化システムは、時間の経過とともに、システムを更新して、新しいアルゴリズムとキーのサイズに移行する必要があります。また、CA は、暗号化アルゴリズムの脆弱性が明らかになったり、新しい関数が導入されたり、既存の関数が廃止されたりした場合には、適宜更新する必要があります。

S/MIME を実装する

S/MIME を使用して、署名または暗号化した電子メールをブートストラップ、構成、および送受信するには、いくつかの段階があります。ここでは S/MIME の一般的なシナリオを使用して、実装の詳細を説明し、実装に関する問題とその解決策を紹介します。2 つの異なる Active Direcroty® フォレストと 2 つの異なる証明機関の信頼チェーンに属している 2 人のユーザーが、Microsoft® Office Outlook® 2007 を使用して署名または暗号化した、あるいはその両方が行われた電子メールをやり取りしています (この 2 人のユーザーは同じ会社内で働いているかどうかに関係なく、運用上は別のエンティティからメールを送受信しているということになります)。

ここで説明する操作に必要なインフラストラクチャは既に整備されていることを前提としています。このシナリオでは、Active Directory に統合されたエンタープライズ CA サーバーを使用します。

証明書を取得する

まず、適切な証明書を取得する必要があります。これには、証明書マネージャ MMC (certmgr.msc) を起動し、[個人] フォルダを右クリックして、[すべてのタスク] をポイントし、[新しい証明書の要求] をクリックします。

この操作により、証明書の登録ウィザード (図 1 参照) が表示されます。既定では、企業向けのいくつかのオプションが表示されますが、ユーザー証明書が重要です。ユーザー証明書は、後で署名と暗号化の処理を有効にする際に使用します。証明書は、次の用途に使用できる必要があります。

図 1** 証明書の要求 **(画像を拡大するには、ここをクリックします)

• デジタル署名 (作成者の認証で封印されたメッセージを作成する)
• キーの暗号化 (暗号化ファイル システムなどのテクノロジで、キーを相互に保護する)
• 電子メールの保護 (対応する秘密キーを所有している然るべき受信者しか読むことができないようにメッセージを暗号化する)

S/MIME を使用して署名した電子メールを送信する場合、キーの暗号化は必要ありませんが、暗号化したメールを送受信する場合は、キーの暗号化が必要になります (ただし、デジタル署名は必要ありません)。既定では、Windows® 証明書サービスによって、この 3 つの用途が有効になっています。新しい証明書を要求することが許可されていない場合、ウィザードには何も表示されません。使用できるエンタープライズ CA がない場合、ドメインまたは CA にアクセスできないことを示すエラー メッセージが表示されます。このシナリオでは、署名と暗号化の両方を許可する単一の証明書を使用することをお勧めします。

証明書を交換する

2 人のユーザーが暗号化した電子メールを送信できるようにする最も簡単な方法は、署名したメッセージを互いに送ることです。必要な作業は、メッセージの作成後に [署名] ボタンをクリックするだけです (このボタンを一度も使用したことがない場合、Outlook の既定の設定では、このボタンが非表示になっていることがあります。新しいメッセージのウィンドウで [オプション] をクリックして、[セキュリティ設定] ボタンをクリックして、[セキュリティのプロパティ] ダイアログ ボックスの [このメッセージにデジタル署名を追加する] チェック ボックスをオンにすると表示されるようになります)。[署名] ボタンをクリックすると、メッセージにデジタル署名が追加され、メッセージの作成者の信頼性が証明されます。このボタンには、小さな黄色い封筒に赤いリボンが付いていて、ポイントすると "署名" というテキストが表示されます。

[送信] ボタンをクリックすると、スマート カードを挿入したり、PIN を入力するなど、キーを所有していることを証明する追加の証拠となるものを提示するように求められることがあります。このボタンをクリックしたときの動作は、組織で採用されているキーの保護方法によって異なります。

S/MIME を使用して署名されたメッセージを受信したユーザーは、"差出人:" の後に表示されている送信者の名前を確認し、名前を右クリックして、[Outlook の連絡先に追加] をクリックする必要があります。この操作により、新しい連絡先エントリが追加されるか、既存の連絡先エントリが更新されます。この操作により、証明書が、その特定の連絡先エントリに関連付けられます。2 人のユーザーが同じフォレストまたは社内にいるという一般的な Active Directory の環境では、ユーザーの Active Directory オブジェクトの属性により、パブリック用のユーザー証明書が自動的に配布されます。

証明書を交換する別の方法としては、各ユーザーが、各自の S/MIME 証明書を添付ファイルとして送信することができます。これを行うには、双方のユーザーが、各自の証明書を CER ファイルとしてエクスポートする必要があります。ユーザーは証明書を表示して、この後説明するエクスポート手順を実行する必要があります。また、この際、図 2 に示すように、秘密キーをエクスポートしないように注意する必要があります。

図 2** 証明書をやり取りする際には秘密キーをエクスポートしないように注意する必要がある **(画像を拡大するには、ここをクリックします)

証明書を受信したら、Outlook で連絡先エントリを手動で作成し、送信者のエントリに証明書を追加します。証明書を交換したら、その後は、互い暗号化した電子メールを送受信することができます。

トラブルシューティング

受信者が暗号化されたメッセージを開けないことがあります。この問題の原因として可能性が高いのは、ルート CA が信頼されていない、中間証明機関が確認できない、または CRL が利用できないことです。

通常、ルート CA が信頼されていない場合、Outlook では、"署名に問題があります。詳細を表示するには、[署名] ボタンをクリックしてください。" という署名に関するエラー メッセージが表示されます。この問題を解決するには、Outlook 内から証明書を開き、ポップアップ ダイアログ ボックスの [証明機関の表示] ボタンをクリックします。証明書プロパティ ダイアログ ボックスの [全般] タブに表示されているメッセージを確認します。CA ルートから発行された証明書が信頼されておらず、インストールする必要があることが示されている場合は、[詳細] タブをクリックします。[ファイルにコピー] ボタンをクリックし、ウィザードの指示に従います。ウィザードでは既定の設定を使用し、ファイル名とフォルダを指定するページでは、これらの情報を指定します。

コンピュータの管理者として、新しい Microsoft 管理コンソール (MMC) を起動します。[ファイル] メニューの [スナップインの追加と削除] をクリックして (または、Ctrl キーを押しながら M キーを押して)、[証明書] を選択し、管理する証明書を指定するように求められたら [コンピュータ アカウント] をクリックします。左側のツリーで [証明書] ノードを展開し、[信頼されたルート証明機関] を展開します。このノードを右クリックし、[すべてのタスク] をポイントして、[インポート] をクリックします。前述のエクスポートした証明書ファイルを信頼されたルート証明機関の証明書としてインポートし、[完了] をクリックします。その後、この問題が発生したユーザーに Outlook を再起動するように指示します。

この手順は、信頼できることが確認されているルート CA を追加する場合にのみ使用してください。すべてのルート CA が同じように作成されているとは限りません。この手順を使用して全システムの証明書ストアにルート CA を追加する前に、そのルート CA の所有者と運用者について十分検討してください。組織で、グループ ポリシーを使用して信頼されたルート証明機関の一覧を管理している場合は、構成がクライアント システムに展開されます。その場合、この手順を使用しても問題が解決しない可能性があります。この手順を使用しても問題が解決しない場合は、電子メールではシームレスでセキュリティが保護された操作性を実現できないので、データのやり取りには、セキュリティで保護された Web サイトやサーバーを使用する必要があります。

中間証明機関が確認できないことが原因であるという 2 つ目の問題が発生する主な状況は 2 つあります。1 つは、証明書の検証を試行しているクライアントが証明書で定義されている機関情報アクセス (AIA) の場所にアクセスできない場合です。もう 1 つは、中間証明機関が発行しているものと一致しない証明書をクライアントが所有している場合です (クライアントでは、CA が所有している証明書よりも 1 ～ 2 バージョン古いものを所有していることがあります)。このような状況は、Outlook のユーザー インターフェイスでも同じように発生します。この問題は、信頼チェーンに含まれる中間レベルの CA が発行した他の従属証明書が失効する前に、親証明書が失効するという非常に特殊な状況でのみ発生することが確認されています。

基本的に、この問題は、証明書チェーンに断絶がある場合に発生します。親証明書の詳細情報が不足していたり、親証明書が適切にリーフ ノードに組み込まれていないと、状況がさらに複雑になります。

この問題を解決するには、送信者が新しいメッセージを作成し、[オプション]、[セキュリティ設定]、[設定の変更] を順にクリックする必要があります。その後、署名証明書の [選択] ボタンをクリックし、ポップアップ ダイアログ ボックスの [証明書の表示] をクリックします。[証明のパス] タブをクリックし、リーフ ノードの発行者 (証明書チェーンの 1 つ上位レベルのノード) を選択し、[証明書の表示] ボタンをクリックします。[詳細] タブをクリックし、[ファイルへコピー] ボタンをクリックし、エクスポート ウィザードの指示に従います。エクスポート ファイルの形式を選択するページでは、[Cryptographic Message Syntax Standard - PKCS #7 証明書 (*.P7B)] をクリックし、[証明のパスにあるすべての証明書を含める] チェック ボックスがオンになっていることを確認します (図 3 参照)。最後に、エクスポートした証明書チェーンのファイルを然るべきユーザーに送信します。

図 3** 証明書チェーンにある断絶の修正 **(画像を拡大するには、ここをクリックします)

エクスポートした証明書チェーンを受け取ったら、受信者は、ファイルを開いて、ルート CA のインポートと同じ手順で証明書チェーンをインポートする必要があります。唯一異なるのは、保存先のフォルダとして [中間証明機関] を選択する必要があることです。メッセージが開けるようになり、証明書が Outlook で有効なものとして表示されれば、問題が解決したということになります。

CRL が利用できないという 3 つ目の問題は、比較的簡単に解決できます。Outlook の状態は、1 つ目と 2 つ目の問題と非常によく似ていますが、ルート署名 CA または中間署名 CA が信頼されている場合にもエラーが表示されることはあります。リーフ ノードの上位に位置する証明書チェーンの各レベルで、証明書のプロパティ ダイアログ ボックスを開いて、[詳細] タブの "CRL 配布ポイント" フィールドの設定を確認します。

このフィールドに表示されている CRL 配布ポイント (特に、インターネットにアクセスできる配布ポイント) ごとに、その CRL ファイルの URL にアクセスできるかどうかを確認します。確認を行う際には、チェーンの下位から上位に向かって作業を進めます。CRL が利用できないレベルがある場合、そのレベルが問題の原因である可能性があります。この問題を解決するには、ローカル ネットワーク ポリシーによってアクセスがブロックされていないことを確認する必要があります。他の解決策としては、CA を所有している企業に連絡するか、CA の CRL 配布ポイントが利用できるようになるまで待機します。

証明書を配布する

配布は簡単に行えます。基本的に、署名したメッセージはメール サーバーに転送され、メール サーバーでは信頼できる SMTP を使用してメッセージが送信されます。署名または暗号化したメールの送信に関して発生する問題は、メール システムによってメッセージが拒否されたり、メール システムを経由するときにメッセージが破損することがあるという問題です。この問題を解決するには、そのようなメール システムの IT 管理者に働きかけて、このような種類のメッセージを許可するようにしてもらう必要があります。もちろん、特定のメッセージの種類がブロックされるという状況を受け入れなければならないこともあります。メッセージを受信する側には、特定の運用環境で暗号化されたメッセージを許可しない然るべき理由がある場合があります。

返信メッセージを暗号化する

返信メッセージを暗号化するのに必要な作業は、メッセージを作成して、メッセージ ウィンドウで [暗号化] ボタンをクリックするだけです (ただし、上記のブートストラップの手順が完了していることが前提となります)。このボタンには、小さな黄色い封筒に青い鍵が付いていて、ポイントすると "暗号化" というテキストが表示されます。[暗号化] ボタンが表示されていない場合は、署名したメッセージの送信についての箇所で提示した手順に従います。唯一異なるのは、最後の手順で [メッセージの内容と添付ファイルを暗号化する] チェック ボックスをオンにすることです。

暗号化したメッセージを送信する際には S/MIME による署名は必要ありませんが、両者は相性がよい機能です。暗号化機能では、送信者としての申し立ては一切行わないので、署名を使用すると受信者が送信者を確認できるようになります。暗号化処理では、すべての受信者の公開キーを使用してメッセージを暗号化します。一部の受信者の証明書がシステムに見つからない場合は、メッセージを暗号化しないで送信することを推奨するポップアップ ダイアログ ボックスに当該受信者の名前が表示されます (図 4 参照)。

図 4** 証明書に関して問題が発生した場合はメッセージを暗号化しない状態で送信できる **(画像を拡大するには、ここをクリックします)

既定では、署名と暗号化は、他の同じように構成されたクライアント システムとは問題なく動作します。ただし、下位レベルのシステムでハッシュや暗号化アルゴリズムがサポートされていない場合には、複数のバージョンにまたがる暗号化または署名を伴うメッセージのやり取りで問題が発生することがあります。このような問題は、Windows XP SP2 コンピュータを使用しているユーザーに、(SHA-512 をハッシュ アルゴリズムとして使用して) 署名した電子メールを送信したときに発生しました。受信側のシステムではハッシュがサポートされていなかったので、ユーザーは署名を確認することも、メッセージを読むこともできませんでした。ただし、Outlook の既定の設定を使用していれば、ユーザーが多くの問題に直面することはほとんどありません。

パブリック用の証明書に対応する秘密キーを保持している場合、メッセージの受信者はメッセージを開くことができます。また、秘密キーの展開方法によっては、秘密キーを所有していることを証明する追加の証拠となるものを提示するように求められることがあります。同様のブートストラップの手順を行ったユーザーは、このような署名および暗号化されたメッセージを他の送信者とやり取りすることができます。ユーザーがコンピュータの紛失などにより秘密キーを変更した場合には、暗号化したメールをやり取りする必要があるユーザーに、証明書を再度要求し、署名したメッセージや証明書ファイルを再配布する必要があります。

まとめ

通常、2 つの異なるディレクトリや組織に所属する 2 人のユーザーが S/MIME を使用して署名および暗号化したメッセージをやり取りすることは、この記事で説明した以上に複雑になることはありません。署名は適切に使用すると、メッセージに信頼性を追加できるので、非常に便利なものです。機密情報に関しては、メッセージを暗号化することで、送信中のデータの機密性が強化されます。署名と暗号化を組み合わせて使用すると、データの提供元の信頼性とデータの機密性の両方を確保できます。また、この記事で説明した手順を使用すれば、大多数のユーザーにとって、これらの機能を使用するのは、それほど大変なことではありません。

Matt Clapham は CISSP 資格保持者で、Microsoft IT でセキュリティ エンジニアとして働いています。日中は LOB アプリケーションのセキュリティ レビューを行い、夜はテクノロジ、ゲーム、コンピュータ ミュージック、またはセキュリティにもちょっと手を伸ばしています。また、ピュジェット湾周辺の IT セキュリティ コミュニティを対象に講演を行うこともあります。連絡先は、matt.clapham@microsoft.com (英語のみ) です。

Blake Hutchinson は、マイクロソフトの Business Online Services Group (BOSG) でサポート アナリストとして働いています。彼の任務は、社内で BOSG の法人顧客向けに作成した LOB ツールの運用サポートとプロジェクト レビューです。趣味は、写真、スキー、コンピュータ ゲームです。連絡先は blakeh@microsoft.com (英語のみ) です。

© 2008 Microsoft Corporation and CMP Media, LLC.All rights reserved; 許可なしに一部または全体を複製することは禁止されています.