前のページ 目次 次のページ

最終更新日: 2002年10月25日


7  PKI アプリケーション

本章では、PKI を利用する様々な PKI アプリケーション(PKI-Enable Application)について概要、機能、構造等を解説します。PKI アプリケーションとしては、Webの暗号化と認証を行う「TLS/SSL)」、電子メールの暗号化とデジタル署名を行う「S/MIME」、ネットワークの暗号化を行う「VPN」、XML文書へのデジタル署名を行う「XML 署名」 および Web で公開されるプログラム(アプレット)の認証を行う「コードサイニング」を取り上げます。

7.1  TLS (SSL)

7.1.1  概要

TLS (Transport Layer Security) は、クライアント/サーバー間における安全な通信環境を提供するプロトコルです。TLS は、証明書を利用することによって、通信の 守秘性、認証、完全性を確保します。TLS は 、TCP/IP レイヤの上で動作し、様々なアプリケーションプロトコル (HTTP, LDAP, FTP, TELNET等) で利用できます(図 7-1)。

図 7-1 TLSの概念

TLS の前身は、Netscape 社によって提唱されたSSL (Secure Sockets Layer) です。SSL は、主に Web において、クレジットカード番号や個人情報といった重要な情報を保護するために利用されています。IETFに おいて、SSLのバージョン 3.0 をベースとして TLS が策定され、RFC2246 として公開されました。 (以降は、TLS と SSL をあわせて TLS/SSL と記述します。)

TLS/SSL を利用するには、サーバーとクライアントに証明書が必要になります。クライアントを認証せず、サーバーのみの認証とする場合は、クライアント側の証明書は必要ありません。

7.1.2  機能

TLS/SSLは、以下のセキュリティ機能を提供します。

(1)  認証 (Authentication)

X.509 証明書を利用することで、サーバーおよびクライアントの認証を行い、第三者によるなりすましを防ぎます。クライアントの認証はオプションとなっており、サーバ ーのみの認証とすることもできます。

(2)  守秘性 (Confidentiality)

サーバーとクライアント間の通信を暗号化することで、第三者への情報の漏洩を防ぎます。暗号化は共通鍵(RC4、トリプルDES など)によって行われます。共通鍵をサーバーとクライアント間で交換するために、X.509 証明書に含まれる公開鍵(RSA、DH など)が用いられます。

(3)  完全性 (Integrity )

サーバーとクライアント間で交換されるデータの完全性を確認し、情報の改ざんを防ぎます。完全性の確認には MAC (Message Authentication Code)を用います。

7.1.3  構造

TLS/SSL は、レコードプロトコルとハンドシェイクプロトコルの 2つの層から構成されます(図 7-2)。

図 7-2 TLS/SSLの内部プロトコル構造

(1)  ハンドシェイクプロトコル

ハンドシェイクプロトコルは、通信相手(サーバとクライアント)の認証や暗号化に使用する共通鍵の生成といった、暗号通信のための準備を行います。ハンドシェイクプロトコルは、証明書の交換を行う Handshake Protocol、暗号アルゴリズムを決定する Change Cipher Spec Protocol、警告情報を通知する Alert Protocol の 3つのサブプロトコルから構成されます。

(2)  レコードプロトコル

レコードプロトコルは、データの送受信を行います。ハンドシェイクプロトコルで確立した鍵を使い、送受信するデータの暗号化と完全性のチェックを行います。

7.1.4  シーケンス

ハンドシェイクプロトコルは、SSL のセッションを確立する際に使用します。ハンドシェイクプロトコルの目的は以下の 2つです。

(1)  お互いの証明書を交換して、相手を認証する。

(2)  守秘性や完全性のための共通鍵(セッション鍵)や MAC 鍵を生成し、双方で安全に共有する。

以下に、ハンドシェイクプロトコルのシーケンスを示します(図 7-3)。

図 7-3 ハンドシェイクプロトコルのシーケンス

(1)  Client Hello

通信の開始をサーバに通知します。クライアントが利用可能な、暗号化と圧縮のアルゴリズムの一覧を送信します。

(2)  Server Hello

使用する暗号化と圧縮のアルゴリズムを決定し、クライアントに通知します。アルゴリズムはクライアントから送信された一覧から選ばれます。

(3)  Certificate

サーバーの証明書を、ルートCA までの証明書のリスト(証明書チェーン)を含めて送信します。

(4)  Server Key Exchange (省略可)

一時的な RSA 鍵か DH 鍵を生成し、サーバーの署名をつけて送信します。このメッセージは、サーバーが証明書を持たないか、Certificateで送信したサーバ ーの証明書に、鍵交換可能な公開鍵(RSAおよびDH) が含まれない場合の代替として使用します。

(5)  Certificate Request (省略可)

サーバーが信頼するルート CA の一覧を付与し、証明書の提示を要求します。クライアントの認証を行う場合に使用します。

(6)  Server Hello Done

クライアントに対して、Server Hello から始まる一連のメッセージが完了したことを通知します。

(7)  Certificate (省略可)

クライアント証明書をサーバーに送付します。(3) と同様に証明書チェーンも送信します。

(8)  Client Key Exchange

暗号化に使用するセッション鍵を生成するための情報(プリマスタシークレット)を生成し、暗号化してサーバーに送信します。プリマスタシークレットの暗号化には、サーバ ーの証明書に含まれる公開鍵を使用します。

(9)  Certificate Verify (省略可)

クライアントは、今までに受信したHelloメッセージから署名 (Certificate Verify) を生成し、サーバーに送信します。署名 (Certificate Verify) を受け取ったサーバーは、クライアントから受け取った証明書 (Certificate) を使い、署名の検証を行います。検証が成功すると、その証明書が間違いなくクライアントのものであることが確認できます。

(10)  [Change Cipher Spec]

クライアントは、プリマスタシークレットからマスタシークレットを生成し、さらにマスタシークレットからセッション鍵を生成します。

次に、使用する暗号アルゴリズムの準備が整ったことをサーバーに通知します。Change Cipher Spec は、ハンドシェイクプロトコルの一部ではなく、独立したプロトコル(Change Cipher Spec Protocol)となっています。

(11)  Finished

鍵交換と認証処理が成功したことをサーバーに通知します。交換したセッション鍵を使い、メッセージを暗号化して送信します。

(12)  [Change Cipher Spec]

サーバーは、クライアントから受信した暗号化されたプリマスタシークレットを、自身の秘密鍵を使い復号します。次に復号したプリマスタシークレットからマスタシークレットを生成し、さらにマスタシークレットからセッション鍵(共通鍵)を生成します。このセッション鍵は、クライアントが生成したセッション鍵と同じ鍵になります。

次に、使用する暗号アルゴリズムの準備が整ったことをクライアントに通知します。Change Cipher Spec は、ハンドシェイクプロトコルの一部ではなく、独立したプロトコル (Change Cipher Spec Protocol) となっています。

(13)  Finished

鍵交換と認証処理が成功したことをサーバーに通知します。交換したセッション鍵を使い、メッセージを暗号化して送信します。

以降は、アプリケーションのデータを、暗号化された状態で送受信します。

実際には、(10) (12) におけるマスタシークレットからの鍵生成は、レコードプロトコルにおいて行われます。レコードプロトコルでは、ハンドシェイクプロトコルから受け取ったマスタシークレットから、完全性の確認に用いる MAC 鍵、暗号化に用いるセッション鍵、ブロック暗号方式の CBC モードで使用する初期ベクトル(IV)を生成します(図 7-4)。

図 7-4 セッション鍵の生成

TLS/SSL では、クライアントの認証はオプションとなっています。サーバーのみを認証する場合を片方向認証、サーバーとクライアントの双方で認証する場合を双方向認証といいます。片方向認証の場合は、(5) Certificate Request, (7) Certificate, (9) Certificate Verifyは省略されます。

7.1.5  アルゴリズム

TLS/SSL では、ハンドシェイクプロトコルによって、サーバーとクライアントの双方が利用可能なアルゴリズムを決定します。利用するアルゴリズムは、鍵交換に用いる公開鍵(RSA, DHなど)、暗号化に用いる共通鍵(トリプル DES, RC4 など)、および セキュアハッシュ(MD5, SHA-1)の組み合わせから選択されます。

以下に、TLSで規定されたアルゴリズムの一覧を示します(表 7-1)。

表 7-1 TLS において利用されるアルゴリズム

種別

アルゴリズム

鍵サイズ

説明

鍵交換

NULL

N/A

 

RSA

制限なし

RSA 公開鍵。

RSA_EXPORT

RSA = 512 bits

DHE_DSS

制限なし

その場限りの DH 鍵。

(DSS署名つき)

DHE_DSS_EXPORT

DH = 512 bits

DHE_RSA

制限なし

その場限りの DH 鍵。

(RSA署名つき)

DHE_RSA_EXPORT

DH = 512 bits

DH_DSS

制限なし

DH鍵。(DSS署名つき)

DH_DSS_EXPORT

DH = 512 bits

DH_RSA

制限なし

DH鍵。(RSA署名つき)

DH_RSA_EXPORT

DH = 512 bits

DH_anon

制限なし

匿名DH鍵。(署名なし)

DH_anon_EXPORT

DH = 512 bits

暗号化

NULL

N/A

 

IDEA_CBC

128 bits

CBCモードのIDEA。

RC2_CBC_40

40 bits

CBCモードのRC2。

RC4_40

40 bits

RC4。

RC4_128

128 bits

RC4。

DES40_CBC

40 bits

CBCモードのDES。

(鍵を40ビットに圧縮)

DES_CBC

56 bits

CBCモードのDES。

3DES_EDE_CBC

168 bits

CBCモードのトリプルDES。

(2Key方式)

ハッシュ

NULL

N/A

 

MD5

N/A

MD5ハッシュ関数。

SHA-1

N/A

SHA-1ハッシュ関数。

これらのアルゴリズムの組み合わせは、「TLS_[鍵交換]_WITH_[暗号化]_[ハッシュ] 」の形式で表されます。たとえば、鍵交換に RSA、暗号化に RC4_128、ハッシュに SHA-1 を利用する場合は、「TLS_RSA_WITH_RC4_128_SHA-1」と表します。アルゴリズムの組み合わせを、暗号スイート(Cipher Suite)とよびます。TLS に準拠したアプリケーションでは、最低でも暗号スイート「TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA」を実装しなければなりません。

以下に、RFC2246 で規定された暗号スイートの一覧を示します(表 7-2)。

表 7-2 TLS において利用される暗号スイート

アルゴリズムセット名

鍵交換

暗号化

ハッシュ

TLS/SSL_NULL_WITH_NULL_NULL

NULL

NULL

NULL

TLS_RSA_WITH_NULL_MD5

RSA

NULL

MD5

TLS_RSA_WITH_NULL_SHA

RSA

NULL

SHA

TLS_RSA_EXPORT_WITH_RC4_40_MD5

RSA512

RC4 40bit

MD5

TLS_RSA_WITH_RC4_128_MD5

RSA

RC4 128

MD5

TLS_RSA_WITH_RC4_128_SHA

RSA

RC4 128

SHA

TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

RSA512

RC2_CBC_40

MD5

TLS_RSA_WITH_IDEA_CBC_SHA

RSA

IDEA_CBC

SHA

TLS_RSA_EXPORT_WITH_DES40_CBC_SHA

RSA512

DES40_CBC

SHA

TLS_RSA_WITH_DES_CBC_SHA

RSA

DES_CBC

SHA

TLS_RSA_WITH_3DES_EDE_CBC_SHA

RSA

3DES_EDE_CBC

SHA

TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA

DH_DSS_EXPORT

DES40_CBC

SHA

TLS_DH_DSS_WITH_DES_CBC_SHA

DH_DSS

DES_CBC

SHA

TLS_DH_DDS_WITH_3DES_EDE_CBC_SHA

DH_DSS

3DES_EDE_CBC

SHA

TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA

DH_RSA_EXPORT

DES40_CBC

SHA

TLS_DH_RSA_WITH_DES_CBC_SHA

DH_RSA

DES_CBC

SHA

TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA

DH_RSA

3DES_EDE_CBC

SHA

TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA

DHE_DSS_EXPORT

DES40_CBC

SHA

TLS_DHE_DSS_WITH_DES_CBC_SHA

DHE_DSS

DES_CBC

SHA

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

DHE_DSS

3DES_EDE_CBC

SHA

TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA

DHE_RSA_EXPORT

DES40_CBC

SHA

TLS_DHE_RSA_WITH_DES_CBC_SHA

DHE_RSA

DES_CBC

SHA

TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

DHE_RSA

3DES_EDE_CBC

SHA

TLS_DH_anon_EXPORT_WITH_RC4_40_MD5

DH_anon_EXPORT

RC4_40

MD5

TLS_DH_anon_WITH_RC4_128_MD5

DH_anon

RC4_128

MD5

TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA

DH_anon

DES40_CBC

SHA

TLS_DH_anon_WITH_DES_CBC_SHA

DH_anon

DES_CBC

SHA

TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

DH_anon

3DES_EDE_CBC

SHA

7.1.6  Web での利用

TLS/SSL は、Web (HTTP) において最もよく利用されています。TLS/SSL の主な利用目的を以下に示します。

(1)  通信の暗号化と完全性の保証

サーバーとクライアントの通信を暗号化することにより、クレジットカード番号や個人情報などの重要な情報をネットワークの盗聴から保護します。暗号化と同時に改ざんの検出を行うため、通信内容(データ)の完全性も保たれます。

(2)  サーバーの認証

Web における電子商取引(EC)を利用する際には、利用者はアクセスする Web サーバーが本当に信頼できるかを確認する必要があります [73]。ドメインは誰でも取得できるため、URL に含まれるドメイン名は必ずしも信用の根拠とすることはできません。

TLS/SSL を利用することで、アクセスしている Web サーバーを証明書によって認証することができます。

(3)  クライアント認証

Webサーバーにアクセスするクライアントに対して、証明書を利用した認証を要求することができます。従来利用されている ID とパスワードによる認証よりも、強固な認証が実現できます。

Web では、サーバーのみが証明書を持つ片方向認証と、サーバーとクライアントが証明書を持つ双方向認証が利用されています。それぞれの違いを以下に示します(表 7-3)。

表 7-3 Web における TLS/SSL の利用

 

片方向認証

双方向認証

目的

サーバーの認証

通信の暗号化と完全性の保証

サーバーの認証

クライアントの認証

通信の暗号化と完全性の保証

証明書の所有

サーバーのみ

サーバーとクライアント

Web において TLS/SSL を利用する場合には、URLが「http://〜」ではなく、「https://〜」となり、443番ポートを使用します。

Web において TLS/SSL を利用した例を以下に示します(図 7-5)。

図 7-5 HTTPS の利用例(Internet Explorer の場合)

TLS/SSL を利用してWeb サーバーにアクセスすると、Web ブラウザの下に鍵のアイコンが表示されます。この鍵のアイコンをダブルクリックすると、サーバーから提示された証明書が表示されます。利用者はこの証明書を確認することで、Webサーバ ーの確認を行うことができます。

TLS/SSL では、交換した証明書をどのように検証するかは、アプリケーション任せとなっています。一般の Web ブラウザは、証明書の有効性確認として、証明書が信頼されている CA から発行されているか、有効期限は過ぎてないかということを確認します。最近の Web ブラウザでは、証明書失効リスト(CRL) を確認できるものもあります。

Web ブラウザには、いくつかの CA が初めから登録されています。これらの CA から発行された証明書は、デフォルトで信頼されるように設定されています。

以下に TLS/SSL を利用する際の注意点を示します。

(1)  サポート機能

TLS/SSL 対応の様々な製品が存在しますが、それぞれサポートする暗号アルゴリズムや証明書の検証方法などの機能に差異があります。利用目的に応じた製品を選定する必要があります。

(2)  ポート番号

HTTPS においては、HTTPの 80番ポートではなく、443番ポートを利用します。ファイアウォールで 443番ポートが許可されていない、プロキシサーバーが HTTPS に対応していないといった場合、HTTPS が使用できないことがあります。

(3)  性能

TLS/SSL においては、暗号化や復号のオーバーヘッドによって、サーバーの負荷が増大します。大規模な Web サイトでは、応答性能の低下に注意しなければなりません。Web サーバ ーに代わって専用のハードウェアで暗号計算を行う製品(SSL アクセラレータ)が、各社から販売されています。しかし、双方向認証に利用する場合は、アプリケーション連携の際にバックエンドのサーバ ーに対してクライアントの証明書情報を引き継ぐ機能がない、あるいは SSL アクセラレータと Web サーバー間のプロトコルの標準が無いこと等の課題を残しています。


前のページ 目次 次のページ Copyright © 2002 Information-technology Promotion Agency, Japan. All rights reserved.