SSL/TLS 暗号化: はじめに

翻訳済み言語: en | + fr | + ja

この日本語訳はすでに古くなっている + 可能性があります。 + 最近更新された内容を見るには英語版をご覧下さい。 +

+ +

+
標準規格の良い所は、たくさんの規格から選べるということだ。 +そして、もし本当にどの規格も気に入らなければ、 +一年待つだけで探していた規格が現れる。
+ +
-- A. Tanenbaum, "Introduction to +Computer Networks"
+

+ +

+入門ということで、この章は Web、HTTP、Apache に通じている +読者向けですが、セキュリティ専門家向けではありません。 +SSL プロトコルの決定的な手引きであるつもりはありません。 +また、組織内の認証管理のための特定のテクニックや、 +特許や輸出規制などの重要な法的な問題についても扱いません。 +むしろ、更なる研究への出発点として色々な概念、定義、例を並べることで +mod_ssl のユーザに基礎知識を提供する事を目的としています。

+ +

ここに示された内容は主に、原著者の許可の下 +The Open Group Research Institute の Frederick J. Hirsch + 氏の記事 +Introducing SSL and Certificates using SSLeay を基にしています。 +氏の記事は Web Security: A Matter of +Trust, World Wide Web Journal, Volume 2, Issue 3, Summer 1997 +に掲載されました。 +肯定的な意見は Frederick Hirsch 氏 + (元記事の著者) へ全ての苦情は Ralf S. Engelschall ( +mod_ssl の作者) へお願いします。 +(訳注: 訳については +Apache ドキュメント翻訳プロジェクト +へお願いします。)

暗号化技術
証明書
Secure Sockets Layer (SSL)
参考文献

参照

暗号化技術

+ +

SSL を理解するには、暗号アルゴリズム、 +メッセージダイジェスト関数(別名: 一方向関数、ハッシュ関数)、 +電子署名などへの理解が必要です。 +これらの技術は本が丸ごと必要な題目で +(例えば [AC96] を参照)、 +プライバシー、信用、認証などの技術の基礎となっています。

+ +

暗号アルゴリズム

+ +

例えば、アリスが送金のために銀行にメッセージを送りたいとします。 + 口座番号や送金の金額が含まれるため、 + アリスはそのメッセージを秘密にしたいと思います。 + 解決方法の一つは暗号アルゴリズムを使って、メッセージを + 復号されるまで読むことができない暗号化された + 形態に変えてしまうことです。 + その形態になると、 + メッセージは秘密の鍵によってのみ復号化することができます。 + 鍵なしでは、メッセージは役に立ちません。 + 良い暗号アルゴリズムは、侵入者が元のテキストを解読することを + 非常に難しくするため、努力が割に合わなくさせます。

+ +

暗号アルゴリズムには + 従来型と公開鍵の二つの種類があります。

+ +

従来型暗号: 対称暗号としても知られ、 + 送信者と受信者が鍵を共有することが必要です。 + 鍵とは、メッセージを暗号化したり復号するのに使われる秘密 + の情報のことです。 + この鍵が秘密になっている限り、送信者と受信者以外は誰もメッセージを読 + むことができません。 + もしも、アリスと銀行が秘密の鍵を知っているなら、 + 彼らはお互いに秘密のメッセージを送ることができるでしょう。 + ただし交信の前に、事前に内密に鍵を共有するという作業自体は難題かもしれません。
公開鍵暗号: 非対称暗号としても知られ、 + メッセージを暗号化することのできる二つの鍵 + を使用するアルゴリズムを定義することで鍵のやり取りの問題を解決 + します。 + もし、ある鍵が暗号化に使われたなら、 + もう片方の鍵で復号しなければいけません。 + この方式によって、一つの鍵を公表して(公開鍵)、 + もう片方を秘密にしておく(秘密鍵)だけで、 + 安全なメッセージを受け取ることができます。

+ +

公開鍵を使って誰もがメッセージを暗号化できますが、秘 + 密鍵の持ち主だけがそれを読むことができます。 + この方法で、銀行の公開鍵を使って暗号化することで、 + アリスは秘密のメッセージを送ることができます。 + 銀行のみが送られたメッセージを復号することができます。

+ + +

メッセージダイジェスト

+ +

アリスはメッセージを秘密にすることができますが、 + 誰かが例えば自分に送金するようにメッセージを変更したり、 + 別のものに置き換えてしまうかもしれないという問題があります。 + アリスのメッセージだという信憑性を保証する方法の一つは、 + メッセージの簡潔なダイジェストを作って、それも銀行に送るというものです。 + メッセージを受け取ると銀行側でもダイジェストを作成し、 + アリスが送ったダイジェストと比べます。もし一致したなら、 + 受け取ったメッセージは無傷だということになります。

+ +

このような要約はメッセージダイジェスト、 + 一方行関数、またはハッシュ関数と呼ばれます。 + メッセージダイジェストは長い可変長のメッセージから + 短い固定長の表現を作るのに使われます。 + ダイジェストアルゴリズムはメッセージから + 一意なダイジェストを生成するように作られています。 + メッセージダイジェストはダイジェストから元のメッセージを + 判定するのがとても難しいようにできていて、 + 同じ要約を作成する二つのメッセージを探すのは(理論上)不可能です。 + これによって、要約を変更することなくメッセージを置き換えられる + 可能性を排除しています。

+ +

アリスへのもう一つの問題は、このダイジェストを安全に送る方法を探すことです。 + ダイジェストが安全に送られればダイジェストの信憑性が保障されて、 + ダイジェストの信憑性をもってオリジナルメッセージの信憑性を得ることができます。 + ダイジェストを安全に送った場合にのみ、そのメッセージの + 信憑性が得られます。

+ +

ダイジェスト安全に送る方法の一つは、電子署名に含める方法です。

+ + +

電子署名

アリスが銀行にメッセージを送ったとき、 +侵入者が彼女になりすまして彼女の口座への取引を申請できないように、 +銀行側ではメッセージが本当に彼女からのものか確実に分かるようにしなければなりません。 +アリスによって作成されて、メッセージに含まれた +電子署名がここで役に立ちます。

+ +

電子署名はメッセージのダイジェストやその他の情報(処理番号など)を +送信者の秘密鍵で暗号化することで作られます。 +誰もが公開鍵を使って署名を復号することができますが、 +送信者のみが秘密鍵を知っています。 +これは送信者のみが署名しえたことを意味します。 +ダイジェストを電子署名に含むことは、 +その署名がそのメッセージのみに有効であることを意味します。 +これは、誰もダイジェストを変えて署名をすることができないため、 +メッセージの信用も保証します。

+ +

侵入者が署名を傍受して後日に再利用するのを防ぐため +電子署名には一意な処理番号が含まれます。 +これは、アリスがそんなメッセージは送っていないと言う詐欺 +から銀行を守ります。 +彼女だけが署名しえたからです。(否認防止)

+ +

証明書

+ +

アリスは秘密のメッセージを銀行に送り、 +署名をして、メッセージの信用を保証することができるおうになりましたが、 +通信している相手が本当に銀行なのか確かめなくてはいけません。 +つまり彼女が使おうとしている公開鍵が、銀行の秘密鍵と対になっていて、 +侵入者の秘密鍵と対になっているわけではないことを +確かめなくてはいけないことを意味しています。 +同様に銀行は、メッセージの署名が本当にアリスの持っている +秘密鍵で署名された署名かを確認する必要があります。

+ +

もし両者に身元を証明し、公開鍵を確認し、また信頼された機関が署名 +した証明書があれば、両者とも通信相手について正しい相手だと +確信することができます。 +そのような信頼された機関は認証局 + (Certificate Authority または CA) と呼ばれ、 +証明書 (certificate) が認証 (authentication) に使われます。

+ +

証明書の内容

+ +

証明書は公開鍵と個人、サーバ、その他の主体の実在の身元を + 関連付けます。 + 表1に示されるように証明対象の情報は + 身元証明の情報(識別名)と公開鍵が含まれます。 + 証明書はまた、認証局の身元証明と署名、そして証明書の有効期間を + 含みます。 + シリアルナンバーなどの認証局の管理上の情報や + その他の追加の情報が含まれているかもしれません。

+ +

表1: 証明書情報

+ + + + + + + + + + + + + +

証明対象	識別名、公開鍵
発行者	識別名、公開鍵
有効期間	開始日、失効日
管理情報	バージョン、シリアルナンバー
拡張情報	基本的な制約、ネットスケープフラッグ、その他

+ + +

識別名(ディスティングイッシュ・ネーム)は特定の状況における + 身分証明を提供するのに使われています。例えば、ある人は + 私用と会社とで別々の身分証明を持つかもしれません。 + + 識別名は X.509 標準規格 [X509] で定義されています。 + X.509 標準規格は、項目、項目名、そして項目の略称を定義しています。(表 + 2 参照)

+ +

表 2: 識別名情報

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

識別名項目	略称	説明	例
Common Name (コモンネーム)	CN	認証される名前 + SSL接続するURL	CN=www.example.com
Organization or Company (組織名)	O	団体の正式英語組織名	O=Example Japan K.K.
Organizational Unit (部門名)	OU	部署名など	OU=Customer Service
City/Locality (市区町村)	L	所在してる市区町村	L=Sapporo
State/Province (都道府県)	ST	所在してる都道府県	ST=Hokkaido
Country(国)	C	所在している国名の ISO コード + 日本の場合 JP +	C=JP

+ + +

認証局はどの項目が省略可能でどれが必須かの方針を定義する + かもしれません。項目の内容についても認証局や証明書のユーザからの + 要件があるかもしれません。 + 例えばネットスケープのブラウザは、サーバの証明書の + Common Name (コモンネーム)がサーバのドメイン名の + *.snakeoil.com + というようなワイルドカードのパターンにマッチすること + を要求します。

+ +

バイナリ形式の証明書は ASN.1 表記法 + [X208] [PKCS] で + 定義されています。 + この表記法は内容をどのように記述するかを定義し、 + 符号化の規定がこの情報がどのようにバイナリ形式に変換されるかを + 定義します。 + 証明書のバイナリ符号化は Distinguished Encoding + Rules (DER) で定義され、それはより一般的な Basic Encoding Rules + (BER) に基づいています。 + バイナリ形式を扱うことのできない送信では、 + バイナリ形式は Base64 符号化 [MIME] で + ASCII 形式に変換されることがあります。 + 開始デリミタ行と終了デリミタ行で囲まれた、この形式のことを + PEM ("Privacy Enhanced Mail") 符号化された証明書と言います。

+ +

PEM 符号化された証明書の例 (example.crt)

+ + +

認証局

+ +

証明書を承認する前に、証明書要求に記載されている情報を確認し、 + 認証局は鍵の所有者の身元を確認します。 + 例えば、アリスが個人証明書を申請したとすると、 + 認証局はアリスが証明書の申請が主張する通りの + 当の本人だということを確認しなくてはいけません。

+ +

証明書の連鎖

+ +

認証局は他の認証局への証明書を発行することができます。 + 未知の証明書を調べる時に、アリスはその証明書の発行者 + に自信が持てるまで、発行者の証明書を + その上位階層の認証局をたどって調べる必要があります。 + 「悪質な」証明書の危険性を減らすため、 + 彼女は限られた連鎖の発行者のみ信頼するように + 決めることもできます。

+ + +

最上位認証局の作成

+ +

前に述べたように、全ての証明書について、 + 最上位の認証局(CA)までそれぞれの発行者が + 対象の身元証明の有効性を明らかにする必要があります。 + 問題は、誰がその最上位の認証機関の証明書を保証するのか、 + ということです。 + このような場合に限り、証明書は「自己署名」されます。 + ブラウザには、とてもよく知られている認証局が初期登録されていますが、 + 自己署名された証明書を信用する際には + 細心の注意が必要です。 + 最上位認証局が公開鍵を広く公表することで、 + その鍵を信頼するリスクを低くすることができます。 + もし、他人がその認証局になりすました時に、それが露見しや + すいからです。

+ +

Thawte + や VeriSign + のような多くの会社が認証局として開設しました。 + このような会社は以下のサービスを提供します:

+ +

証明書申請の確認
証明書申請の処理
証明書の発行と管理

+ +

自分で認証局を作ることも可能です。 + インターネット環境では危険ですが、 + 個人やサーバの身元証明が簡単に行える組織の + イントラネット内では役に立つかもしれません。

+ + +

証明書管理

+ +

認証局の開設は徹底した管理、技術、運用の体制を必要とする + 責任のある仕事です。 + 認証局は証明書を発行するだけでなく、 + 管理もしなければなりません。 + 具体的には、証明書がいつまで有効であり続けるかを決定し、更新し、 + また過去発行されて失効した証明書のリスト + (Certificate Revocation Lists または CRL) + を管理しなければいけません。

+ +

例えばアリスが過去、会社の社員であることを証明する証明書を持っていたが、 + 現在は退職していた際、その証明書は失効されなければなりません。 + 証明書は次々と人に渡されていくものなので、 + 証明書そのものから、それが取り消されたか判断することは + 不可能です。 + よって、証明書の有効性を調べるときには、 + 認証局に連絡して CRL を照合する必要があります。 + 普通この過程は自動化されているものではありません。

+ +

注意

ブラウザに信用できる認証局としてデフォルトで登録されていない + 認証局を使おうとした場合、 + 認証局の証明書をブラウザに読み込んで、 + ブラウザがその認証局によって署名されたサーバの証明書を + 有効にする必要があります。 + 一度読み込まれると、その認証局によって署名された全ての + 証明書を受け入れるため、危険を伴います。

+ + + +

Secure Sockets Layer (SSL)

+ +

Secure Sockets Layer プロトコルは信頼性のあるコネクション型の +ネットワーク層のプロトコル(例えば、TCP/IP)と +アプリケーション層のプロトコル(例えば、HTTP) +の間に置くことができます。 +SSL は、相互認証によってサーバとクライアント間の安全な通信を、 +電子署名によってデータの完全性を、 +そして暗号化によってプライバシを提供します。

+ +

SSL プロトコルは暗号化、ダイジェスト、電子署名について、 +様々なアルゴリズムをサポートするようにできています。 +こうすることで、法や輸出の規制を考慮に入れて、サーバに合わせた +アルゴリズムを選ぶことができ、また、新しいアルゴリズムを +利用していくことも可能にしています。 +アルゴリズムの選択はプロトコルセッション開始時に +サーバとクライアント間で取り決められます。

+ +

表4: SSL プロトコルのバージョン

+ + + + + + + + + + + + + + + + + + + +

バージョン	出典	説明	ブラウザのサポート
SSL v2.0	Vendor Standard (Netscape Corp. より) [SSL2]	実装が現存する初めての SSL プロトコル	- NS Navigator 1.x/2.x + - MS IE 3.x + - Lynx/2.8+OpenSSL
SSL v3.0	Expired Internet Draft (Netscape Corp. より) [SSL3]	特定のセキュリティ攻撃を防ぐための改訂、 + 非RSA 暗号の追加、証明書階層構造のサポート	- NS Navigator 2.x/3.x/4.x + - MS IE 3.x/4.x + - Lynx/2.8+OpenSSL
TLS v1.0	Proposed Internet Standard (IETF より) [TLS1]	MAC レイヤを HMAC へ更新、ブロック暗号の block + padding、メッセージ順序の標準化、警告文の充実などのため + SSL 3.0 を改訂。	- Lynx/2.8+OpenSSL

+ + +

表4に示されるとおり、SSL プロトコルには +いくつものバージョンがあります。 +表にも書かれているように、SSL 3.0 の利点の一つは +証明書階層構造をサポートすることです。 +この機能によって、サーバは自分の証明書に加えて、 +発行者の証明書をブラウザに渡すことができます。 +証明書階層構造によって、 +ブラウザに発行者の証明書が直接登録されていなくても、 +階層の中に含まれていれば、 +ブラウザはサーバの証明書を有効化することができます。 +SSL 3.0 は現在 Internet Engineering Task Force (IETF) +によって開発されている Transport Layer Security +[TLS] プロトコル標準規格の基礎となっています。

+ +

セッションの確立

+ +

図1で示されるように、 + セッションの確立はクライアントとサーバ間の + ハンドシェークシークエンスによって行なわれます。 + サーバが証明書を提供するか、クライアントの証明書をリクエストするか + というサーバの設定により、このシークエンスは異なるものとなります。 + 暗号情報の管理のために、追加のハンドシェーク過程が必要になる + 場合もありますが、この記事では + よくあるシナリオを手短に説明します。 + 全ての可能性についは、SSL 仕様書を参照してください。

+ +

注意

一度 SSL セッションが確立すると、セッションを再利用することで、 + セッションを開始するための多くの過程を繰り返すという + パフォーマンスの損失を防ぎます。 + そのため、サーバは全てのセッションに一意なセッション識別名を + 割り当て、サーバにキャッシュし、クライアントは次回から + (識別名がサーバのキャッシュで期限切れになるまでは) + ハンドシェークなしで接続することができます。

+ +

+
+ 図1: SSL + ハンドシェークシークエンス概略

+ +

サーバとクライアントで使われる + ハンドシェークシークエンスの要素を以下に示します:

+ +

データ通信に使われる暗号スイートの取り決め
クライアントとサーバ間でのセッション鍵の確立と共有
オプションとして、クライアントに対するサーバの認証
オプションとして、サーバに対するクライアントの認証

+ +

第一ステップの暗号スイート取り決めによって、 + サーバとクライアントはそれぞれにあった + 暗号スイートを選ぶことができます。 + SSL3.0 プロトコルの仕様書は 31 の暗号スイートを定義しています。 + 暗号スイートは以下のコンポーネントにより定義されています:

+ +

鍵の交換手段
データ通信の暗号術
Message Authentication Code (MAC) 作成のための + メッセージダイジェスト

+ +

これらの三つの要素は以下のセクションで説明されています。

+ + +

鍵の交換手段

+ +

鍵の交換手段はアプリケーションのデータ通信に使われ、 + 共有される対称暗号鍵をどのようにがクライアントとサーバで + 取り決めるかを定義します。 + SSL 2.0 は RSA 鍵交換しか使いませんが、 + SSL 3.0 は (証明書が使われるときの) RSA 鍵交換や、 + (証明書無しの場合やクライアントとサーバの事前の通信が無い場合の) + Diffie-Hellman 鍵交換 + など様々な鍵交換アルゴリズムをサポートします。

+ +

鍵の交換方法における一つの選択肢は電子署名です。 + 電子署名を使うかどうか、また、 + どの種類の署名を使うかという選択があります。 + 秘密鍵で署名することで共有鍵を保護し、情報交換する時の + マン・イン・ザ・ミドル攻撃を防ぐことができます。 + [AC96, p516]

+ + +

データ通信の暗号術

+ +

SSL はセッションのメッセージの暗号化に前述した + 対称暗号方式を用います。 + 暗号化しないという選択肢も含め九つの暗号方式の選択肢があります:

+ +

暗号化なし
ストリーム暗号 +
- 40-bit 鍵での RC4
- 128-bit 鍵での RC4
CBC ブロック暗号 +
- 40 bit 鍵での RC2
- 40 bit 鍵での DES
- 56 bit 鍵での DES
- 168 bit 鍵での Triple-DES
- Idea (128 bit 鍵)
- Fortezza (96 bit 鍵)

+ +

CBC とは暗号ブロック連鎖 (Cipher Block Chaining) + の略で、一つ前の暗号化された暗号文の一部が + ブロックの暗号化に使われることを意味します。 + DES はデータ暗号化標準規格 (Data Encryption Standard) + [AC96, ch12] の略で、 + DES40 や 3DES_EDE を含むいくつもの種類があります。 + Idea は現在最高なものの一つで、暗号術的には現在ある中で + 最も強力なものです。 + RC2 は RSA DSI による独占的なアルゴリズムです。 + [AC96, + ch13]

+ + +

ダイジェスト関数

+ +

+ ダイジェスト関数の選択はレコードユニットからどのようにダイジェストが生成されるかを決定します。 + SSL は以下をサポートします:

+ +

ダイジェストなし
MD5 (128-bit ハッシュ)
Secure Hash Algorithm (SHA-1) (160-bit ハッシュ)

+ +

メッセージダイジェストは Message Authentication Code (MAC) + の生成に使われ、メッセージと共に暗号化され、メッセージの信憑性を + 確認し、リプレイ攻撃を防ぎます。

+ + +

ハンドシェークシークエンスプロトコル

+ +

ハンドシェークシークエンスは三つのプロトコルを使います:

+ +

SSL ハンドシェークプロトコルは + クライアントとサーバ間での SSL セッションの確立に使われます。
SSL 暗号仕様変更プロトコルは + セッションでの暗号スイートの取り決めに使われます。
SSL 警告プロトコルは + クライアントサーバ間で SSL エラーを伝達するのに使われます。

+ +

三つのプロトコルは、アプリケーションプロトコルデータとともに、 + 図2に示すとおり SSL レコードプロトコル + でカプセル化されます。 + カプセル化されたプロトコルはデータを検査しない + 下層のプロトコルによってデータとして伝達されます。 + カプセル化されたプロトコルは下層のプロトコルに関して一切関知しません。

+ +

+
+ 図2: SSL プロトコルスタック +

+ +

+ レコードプロトコルで SSL コントロールプロトコルがカプセル化されているということは、 + アクティブなセッション上で再ネゴシエーションされたときにも、 + コントロールプロトコルは安全であることを意味します。 + 既存のセッションが無い場合は、Null 暗号スイートが使われ、 + 暗号化は行なわれず、セッションが確立するまでは + ダイジェストも無い状態となります。

+ + +

データ通信

+ +

図3に示される SSL レコードプロトコル + はクライアントとサーバ間のアプリケーションや + SSL コントロールデータの通信に使われます。 + 必要に応じてこのデータはより小さいユニットに分けられたり、 + いくつかの高級プロトコルをまとめて一ユニットとして通信が + 行なわれることもあります。 + データを圧縮し、ダイジェスト署名を添付して、 + これらのユニットを暗号化したのち、ベースとなっている + 信頼性のあるトランスポートプロトコルを用いるかもしれません。 + (注意: 現在メジャーな SLL 実装で圧縮をサポートしているものはありません)

+ +

+
+ 図 3: SSL レコードプロトコル +

+ + +

HTTP 通信の安全化

+ +

よくある SSL の使い方はブラウザとウェブサーバ間の HTTP 通信 + の安全化です。 + これは、従来の安全ではない HTTP の使用を除外するものではありません。 + 安全化されたもの (HTTPS と呼ばれます) は、SSL 上での普通の HTTP で、 + URL スキームに http の代わりに https + を用い、サーバで別のポートを使うことです (デフォルトでは443)。 + これが主に mod_ssl が Apache + ウェブサーバに提供する機能です。

+ +

参考文献

+ +

[AC96]: Bruce Schneier, Applied Cryptography, 2nd Edition, Wiley, +1996. See http://www.counterpane.com/ for various other materials by Bruce +Schneier.
[X208]: ITU-T Recommendation X.208, Specification of Abstract Syntax Notation +One (ASN.1), 1988. See for instance http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.208-198811-I. +
[X509]: ITU-T Recommendation X.509, The Directory - Authentication +Framework. See for instance http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=T-REC-X.509. +
[PKCS]: Public Key Cryptography Standards (PKCS), +RSA Laboratories Technical Notes, See http://www.rsasecurity.com/rsalabs/pkcs/.
[MIME]: N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions +(MIME) Part One: Format of Internet Message Bodies, RFC2045. +See for instance http://ietf.org/rfc/rfc2045.txt.
[SSL2]: Kipp E.B. Hickman, The SSL Protocol, 1995. See http://www.netscape.com/eng/security/SSL_2.html.
[SSL3]: Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol +Version 3.0, 1996. See http://www.netscape.com/eng/ssl3/draft302.txt.
[TLS1]: Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0, +1999. See http://ietf.org/rfc/rfc2246.txt.