最終更新日： 2002年10月25日
本章では、PKI を利用する様々な PKI アプリケーション(PKI-Enable Application)について概要、機能、構造等を解説します。PKI アプリケーションとしては、Webの暗号化と認証を行う「TLS/SSL)」、電子メールの暗号化とデジタル署名を行う「S/MIME」、ネットワークの暗号化を行う「VPN」、XML文書へのデジタル署名を行う「XML 署名」 および Web で公開されるプログラム（アプレット）の認証を行う「コードサイニング」を取り上げます。
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 を利用するには、サーバーとクライアントに証明書が必要になります。クライアントを認証せず、サーバーのみの認証とする場合は、クライアント側の証明書は必要ありません。
TLS/SSLは、以下のセキュリティ機能を提供します。
(1) 認証 (Authentication)
X.509 証明書を利用することで、サーバーおよびクライアントの認証を行い、第三者によるなりすましを防ぎます。クライアントの認証はオプションとなっており、サーバ ーのみの認証とすることもできます。
(2) 守秘性 (Confidentiality)
サーバーとクライアント間の通信を暗号化することで、第三者への情報の漏洩を防ぎます。暗号化は共通鍵（RC4、トリプルDES など）によって行われます。共通鍵をサーバーとクライアント間で交換するために、X.509 証明書に含まれる公開鍵（RSA、DH など）が用いられます。
(3) 完全性 (Integrity )
サーバーとクライアント間で交換されるデータの完全性を確認し、情報の改ざんを防ぎます。完全性の確認には MAC (Message Authentication Code)を用います。
TLS/SSL は、レコードプロトコルとハンドシェイクプロトコルの 2つの層から構成されます（図 7-2）。
図 7-2 TLS/SSLの内部プロトコル構造
(1) ハンドシェイクプロトコル
ハンドシェイクプロトコルは、通信相手（サーバとクライアント）の認証や暗号化に使用する共通鍵の生成といった、暗号通信のための準備を行います。ハンドシェイクプロトコルは、証明書の交換を行う Handshake Protocol、暗号アルゴリズムを決定する Change Cipher Spec Protocol、警告情報を通知する Alert Protocol の 3つのサブプロトコルから構成されます。
(2) レコードプロトコル
レコードプロトコルは、データの送受信を行います。ハンドシェイクプロトコルで確立した鍵を使い、送受信するデータの暗号化と完全性のチェックを行います。
ハンドシェイクプロトコルは、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は省略されます。
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。 （２Key方式） |
|
|
ハッシュ |
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 |
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.