暗号化と認証の仕組み

  • [アーティクル]

ここでは、Exchange Server5.5のKey Management Serverで利用されている暗号化と認証のテクノロジについてその概要を述べます。次に関連するテクノロジとしてWindows NT RPC、X.509証明書、S/MIME、SSLについて、その概要を述べます。

暗号化

暗号化とは、データやメッセージを暗号化 (スクランブル) して格納し、安全に送信するため技術です。暗号化により、インターネットなどの信頼できない通信方法を使用した場合でも、保護された通信が可能になります。重要なファイルを暗号化すれば、侵入者がそれを理解することはできなくなります。

暗号化されたデータやメッセージを復号化 (アンスクランブル) し、元の状態に戻す技術も必要です。適切な技術が使用された場合、メッセージの復号化に必要な秘密の暗号キーを知らないユーザーがそのメッセージを元の状態に戻すことは、ほとんど不可能になります。特定の受信者だけがメッセージを復号化できるように保証するデジタル封書というこの考え方は、暗号化において重要な役割を果たします。

また、データの送信元を検証する目的には、デジタル署名という技術が使用されます。

データの暗号化

データの暗号化を行うと、ふつうのテキスト形式 (平文) のメッセージをスクランブルして、順不同の意味不明なデータに変換することができます。秘密キーを知らない者がこのデータを解読することは、ほとんど不可能です。ここでは、暗号化対象のデータを "メッセージ" と呼びます。メッセージとは、ASCII テキスト、データベース ファイルなど、安全に送信する必要があるなんらかのデータです。また、暗号化されていないデータのことを "平文"、暗号化されたデータのことを "暗号化テキスト" と呼ぶことにします。

暗号化されたメッセージは、保護されていない媒体に格納したり、保護されていないネットワークで送信したりしても、機密性が保持されます。送信の後、メッセージは復号化により元の形に戻すことができます。次の図は、このようすを示しています。

メッセージの暗号化には、"暗号化キー" が使用されます。暗号化とは、南京錠をかけるようなものです。メッセージの解読には、対応する "復号化キー" が使用されます。復号化キーを知っている人は、その復号化キーに対応する暗号化キーで暗号化されたすべてのメッセージを復号化できます。したがって、復号化キーへのアクセスを適切に制限することが非常に重要です。

暗号化には大別すると共通鍵暗号方式と公開鍵暗号方式二つの方式があります。

共通鍵暗号方式

共通鍵暗号方式は、送信側と受信側が同じ鍵を用いてデータの暗号化と復号化をする暗号方式です。第三者にこの共通鍵を漏らしてしまうと暗号を解かれてしまうので、この共通鍵は隠す必要があります。共通鍵暗号方式は処理速度が速いという長所がある反面、秘密にする必要がある共通鍵を最初に送信側と受信側で交換する必要があるため安全性に問題があります。IBMが開発したDES(Data Encryption Standard)が、この方式における米国の実質的な標準となっています。

公開鍵暗号方式

公開鍵暗号方式は、パブリック キーとプライベート キーと呼ばれる二つの鍵を用います。プライベート キーは第三者に見られないように保管しておきますが、パブリック キーは誰でも見て使うことができます。パブリック キーとプライベート キーは必ず対になっていて、パブリック キーで暗号化したデータは対応するプライベート キーでないと復号化できず、プライベート キーで暗号化したデータは対応するパブリック キーでないと復号化できません。データを送信するためには、受信側のパブリック キーで送信データを暗号化してから送信します。このデータは、受信側が持っているプライベート キーでないと復号化できないので、第三者がこのデータを見ることはできません。公開鍵暗号方式は、パブリック キーのみを送信側と受信側で交換すればよいので安全であるという長所がある反面、処理速度が遅いという欠点があります。そこで、いまのところ共通鍵暗号方式で用いる共通鍵を公開鍵暗号方式で送信側と受信側で交換し、その共通鍵を用いて実際のデータを送受信するということが行われています。公開鍵暗号方式の代表にはRSA(Rivest,Shamir,Adleman)があります。

デジタル署名

デジタル署名を使用すると、ふつうのテキスト形式（平文）のメッセージを送信するとき、受信者はメッセージが何者かによって改ざんされていないことを検証できます。メッセージへの署名はメッセージを変更するわけではなく、デジタル署名文字列を生成するだけです。デジタル署名文字列は、メッセージに付加することも別々に送付することもできます。

デジタル署名は公開鍵暗号方式を使って生成できます。署名には送信側のプライベート キーを使用します。署名されたメッセージを受け取った受信者は、プライベート キーとは別のパブリック キーを使用して署名を検証します。署名を検証できるのは署名者のパブリック キーだけなので、あらかじめ電子メールなどで受け取っておいた送信者のパブリック キーで署名を検証できれば、メッセージが確かにその送信者から送られたことが証明されることになります。次の図は、このようすを示しています。

デジタル封書

デジタル封書は、特定の受信者だけが理解できる私的なメッセージを送る場合に使用されます。デジタル封書は「データの暗号化」で説明している方法で実現されます。メッセージの暗号化には、受信者のパブリック キーが使われます。受信者の公パブリック キーで暗号化されたメッセージは、受信者のプライベート キーによってのみ復号化できます。したがって、目的の受信者だけがそのメッセージを解読できることになります。

認証

デジタル署名とデジタル封書について説明したこれまでの項では、メッセージの暗号化と復号化に使用されるパブリック キーの所有者が確実に識別されていることを前提としてきました。しかし、たとえば "アリス" と称する送信者からデジタル署名付きのメッセージを受け取り、それをアリスのものであると称するパブリック キーで検証できたとしても、まだ安心はできません。使用したパブリック キーが本当にアリスのものであることを確認していないからです。同様に、デジタル封書の送信者が "ボブ" のものであると称するパブリック キーで暗号化を行う場合、送信者はそのパブリック キーが本当にボブのものであることを確認する必要があります。

現実の世界では、長い間、認証の方法として物理的な書類を使用してきました。たとえば、買い物をした客が小切手にサインした場合、店員はその客に対して運転免許証を見せてくれるように求める場合があります。運転免許証を見ることによって、店員はその客が本当に小切手の持ち主であることを再確認できます。なぜなら、店員は運転免許証を発行した公的機関がその客の身元を適切な方法で確認していることを信じているからです。旅行先でパスポートが果たす役割も似ています。税関の役人は、旅行者の政府がパスポートの発行に際して適切な身元確認を行ったことを信じているので、パスポートを見ることでその旅行者を確認できたと考えます。このどちらの場合も、証明書を発行した機関に対する信頼が基礎になっていることに注意してください。

Microsoft® Exchange ServerのKey Management Serverは、Microsoft® Certificate Server を使用することにより、保護されていないネットワークでパブリック キーの身元を保証するため、デジタル証明書 (または単に証明書) を使用した安全な方法でパブリック キーを交換します。

デジタル証明書

証明書には、対象者の身元を完全に識別するために必要なデータが含まれています。証明書を発行できるのは、身元が検証されている証明機関 (CA) だけです。証明書のデータには、対象者のパブリック キーが含まれています。送信者のプライベート キーで署名されたメッセージを受け取った受信者は、送信者の証明書から取り出したパブリック キーを使用して、メッセージが確かにその送信者からのものであることを検証します。証明書は、メッセージと一緒に送ることも、ディレクトリ サービスのいずれかの場所に公開しておくこともできます。

デジタル証明書は、ネットワーク上で個人または実体を認証するための仮想的な書類です。ネットワーク上では、物理的に会ったことのない人どうしが通信を行うことも多いので、ネットワーク上での証明書の使用は物理的な証明書の使用よりも複雑です。物理的な検証を行うことができない環境で高い信頼性を得るには、特別な方法 (プロトコル) を決めておく必要があります。また、保護されていないネットワークでは、容易にメッセージに割り込んで偽りの身元を提示することができます。これらの問題を回避するため、これまでに説明したように、暗号化の技術を使った安全なプロトコルを使用する必要があります。その結果、証明書の偽造や身元の偽証は、不可能とは言えないまでも非常に困難になります。

デジタル証明

デジタル証明の第一の目的は、証明書に含まれているパブリック キーが確かにその証明書を発行された個人または実体のパブリック キーであることを確認することです。たとえば、証明機関 (CA) がユーザーの名前 (たとえば、"アリス") とパブリック キーを含む特別なメッセージ (証明書情報) にデジタル署名し、確かに CA がその証明書情報メッセージに署名したことをだれもが検証できるようにします。これにより、すべての人がアリスのパブリック キーを確認できるようになります。

デジタル証明書の典型的な実装には、証明書に署名する署名アルゴリズムが含まれます。この処理は、次の手順で行われます。

  1. アリスは自分の名前とパブリック キーを含めた証明書要求を CA に送ります。

  2. CA はその要求から特別なメッセージ m を作成します。このメッセージには、証明書のデータの大半が含められます。CA はそのメッセージにそのプライベート キーで署名し、別個の署名 sig を得ます。そして、CA はメッセージ m と署名 sig をアリスに返します。この 2つが証明書を構成します。

  3. アリスは証明書をボブに送ります。証明書により、彼女のパブリック キーの信頼性は保証されます。

  4. ボブは CA のパブリック キーを使用して署名 sig を検証します。署名の検証に成功したら、アリスのパブリック キーを受け入れます。

証明書が証明機関 (CA) によってデジタル署名されていることは、すべての人がいつでも検証できます。この検証を行うために特別な権限は必要ありません。

このシナリオでは、ボブが特定の CA のパブリック キーを知っていることを前提としています。CA 証明書には CA のパブリック キーが含まれているので、CA のパブリック キーは CA 証明書のコピーから取得できます。

証明書には有効期限があるので、証明書は期限が切れて無効になる可能性があります。証明書が有効なのは、それを発行した CA が指定した期間だけです。証明書には発行日と有効期限の情報が含まれています。ユーザーが保護されたサーバーに期限切れの証明書を使ってアクセスしようとすると、サーバーの認証プログラムは自動的にその要求を拒否します。期限が切れる前に、ユーザーは証明書を更新する必要があります。

CA は証明書をほかの理由によって取り消す (失効させる) こともできます。CA は失効した証明書のリストを保持しています。このリストは証明書失効リスト (CRL) と呼ばれ、ネットワークに公開されます。ユーザーは CRL を参照して、受け取った証明書の有効性を確認できます。

Windows NT RPCとは…

RPC(Remote Procedure Call)とは、プロセス間通信の一種で、RPCを使用するとローカルマシンの上で実行されている関数を呼ぶかのように、ネットワーク上のリモートマシン上で実行されている関数を呼び出すことができます。RPCはもともとSun Microsystemsで開発され、後にOSF（Open Software Foundation）によりDCE（Distributed Computing Environment）の一部として開発が進められてきました。

Microsoft RPCは、OSF/DCE標準のRPCと互換性があります。そのためDCEベースのRPCシステムと相互運用ができます。Microsoft RPC機構は、クライアントとサーバーの間で通信を確立するために他のプロセス間通信機構を使用するという点で独特です。Microsoft RPCは次のものを使用して、リモートシステムと通信できます。

  • 名前付きパイプ

  • NetBIOS

  • Windows Sockets

アプリケーションのクライアントとサーバーが同じマシン上にあるときは、ローカルプロシジャーコール（LPC）を使用して情報をプロセス間で転送することができます。これにより、RPCは使用可能なプロセス間通信の中で最も柔軟性と移植性を備えたものになります。

Microsoft RPCは、Windows NTのセキュリティサービスを使い、OSF/DCE RPCのセキュリティ関数群を実装しています。このセキュリティ機能を用いると、サーバーはクライアントの要求を認証することができます。認証にはいくつかのレベルが存在し、クライアントとサーバーが通信を行うためには、共通の認証レベルを決めなくてはなりません。最低レベルはサーバーが決定します。サーバーは、それよりも低い認証レベルでアクセスを試みるクライアントをすべて拒否します。現時点では、６つの認証レベルが存在します。

  • None 認証を行いません。

  • Connect クライアントがサーバーとの関係を確立するときにのみ認証を行います。言い換えると、クライアントはサーバーに対する最初の呼び出しのときにのみ認証されます。

  • Call 個々のリモート プロシージャ コールの先頭で、サーバーが要求を受信したときにのみ認証を行います。メソッド呼び出しはすべてリモート プロシージャ コールなので、認証はすべてのメソッド呼び出しの先頭で行われます。

  • Packet 受信されたすべてのデータが、期待されるクライアントからのものであることを認証します。ネットワーク パケットを受信するたびに認証を実行します。

  • Packet Integrity クライアントとサーバーの間で転送されたデータが変更されていないことを認証し、検証します。認証はパケット レベルで実行されますが、各パケットについて、そのアイデンティティだけでなく、改ざんされていないかどうかもチェックされます。

  • Packet Privacy これよりも低いすべてのレベルでの認証を行い、各リモート プロシージャ コールの引数値を暗号化します。これは実質的には、パケット内のデータが暗号化されているPacket Integrityに相当します。

Windows NT RPCを使うようにExchange Server5.5のSMTP接続を構成すると、北米では128ビット、他の地域では40ビットの暗号を使って、サーバー相互間で安全な接続を確立でき、Microsoft 暗号化認証を利用して、SMTP接続を認証できます。また、クライアント/サーバー間で安全な接続が要求される場合は、ExchangeまたはOutlookの32ビットクライアントでWindows NT RPCを有効に設定します。

X.509証明書とは…

証明書の規格の一つにX.509があります。X.509はITU (International Telecommunication Union) や ISO (International Organization for Standardization) で標準化され、RFC（Request for Comment）2459によって定義されています。S/MIMEとSSLで使用する証明書はX.509をベースにしています。

X.509証明書には複数のバージョンが存在します。1988年に公開されたバージョン1では基本的な必須項目が定義され、1993年に公開されたバージョン２ではエンティティの一意性を表すためのオプショナルな固有識別子が追加されました。バージョン２は特定の証明書がすでに信用できなくなっていることを判断するためにCA によって使用される暗号化取り消し一覧（CRL）などの機能を追加しています。更に1996 年にはさまざまな情報を埋め込めることのできる追加領域を定義したバージョン3が発行されています。現在はこのX.509 v3がよく利用されています。

X.509 v3証明書は以下のようなフィールドを含んでいます。

フィールド 説明
Version X.509のバージョン
serialNumber 認証局がユニークに割り当てるシリアル番号
Signature 証明書の署名方式
Issuer 証明書の発行者である認証局のX.500識別名
Validity パブリック キーの有効期限
Subject 証明書内に含まれるパブリック キーに対応するプライベート キーの所有者のX.500識別名
subjectPublicKeyInfo 証明するパブリック キー
issuerUniqueIdentifier 認証局の固有識別子（v2で追加）
subjectUniqueIdentifier 所有者の固有識別子（v2で追加）
Extensions 拡張フィールド（v3で追加）

S/MIMEとは…

電子メールに使用されるプロトコルであるSMTP(Simple Mail Transfer Protocol)は、認証の仕組みを持っていません。そのため、電子メールのヘッダは偽造することが可能で、偽名のメールを送ることが可能です。また、電子メールの本文を第三者が送信途中に盗聴や改ざんすることも可能です。

S/MIME(Secure/Multipurpose Internet Mail Extensions)とは、従来のメッセージ形式であるMIME(Multipurpose Internet Mail Extensions)をベースに、共通鍵暗号方式と公開鍵暗号方式を組み合わせて、電子メールに暗号化機能をもたせる技術です。

S/MIMEを使用すると、デジタル署名、デジタル封書、デジタル署名とデジタル封書の3パターンの電子メールを作成することができるので、電子メールの盗聴と改ざんを防ぐことが可能です。また、ユーザー同士が互いに認証しあうPGP方式と異なり、CAが発行する証明書によってパブリック キーを管理する方式を採用しているので信頼性の高い認証を行うことができます。

SSLとは…

SSL(Secure Sockets Layer)とは通信の暗号化と認証をおこなうことによって、 第三者によるデータの盗聴や改ざんなどを防ぐプロトコルです。主にWebサーバーとWebブラウザ間でのやり取りに使用されます。

SSLも共通鍵暗号方式と公開鍵暗号方式を組み合わせて用います。ただし、S/MIMEのようにアプリケーション上で実現するのではなく、OSI参照モデルでのセッション層で機能するように作られています。そのため、”http”の他に”ftp”や”telnet”など、新たにポートを割り付ければ、どのアプリケーションでも暗号通信、認証通信を利用することができます。

SSLでは複数の暗号方式を使えるようにしています。そのため両者で使用できる暗号方式を決めなくてはなりません。また、通信相手が本物かどうかを認証する必要があり、暗号化・復号化に必要な共有鍵を交換する必要があります。このような暗号通信前の交渉を行うことをハンドシェイク・プロトコルと言います。以下では、ハンドシェイク・プロトコルの中身について説明します。

  1. SSLでは、まずクライアントから、自分で使用できる暗号方式などをサーバーに送ります。サーバーは、受け取った暗号方式から自分で使用できるものを選び、クライアントへ送り返します。

  2. サーバーはCAから発行された証明書をクライアントへ送ります。証明書を受け取ったクライアントは、CAのパブリック キーを使用して、証明書のデジタル署名を確かめることで、証明書がCAのものであることと、それに含まれるパブリック キーがサーバーのものであることを確認します。

  3. クライアントは共有鍵のもとを作成し、サーバーのパブリック キーで暗号化してサーバーへ送ります。この共有鍵のもとからサーバーとクライアントは共有鍵を生成します。ここまでの過程がハンドシェイク・プロトコルです。

ハンドシェイク・プロトコルの後、生成した共有鍵を用いて、サーバーとクライアントは暗号通信を開始します。

SSLはWindows NT RPCと同様、RSAのRC4ストリーム暗号化を利用し、北米では128ビット、他の地域では40ビットの暗号を使って、クライアント/サーバー間およびサーバー相互間で接続を保護します。SSLは、サーバー相互間のSMTPメール送受信用のネットワークを保護することができます。認証の手段として、X.509 v3証明書またはExchange 5.5以降のSASL（Simple Authentication Security Layer）を利用します。SSLは、LDAP、POP3、HTTP、NNTP、IMAP4のいずれかを利用するクライアント/サーバー間の接続を保護する目的でも利用できます。