Secure Sockets Layer (SSL) は、Web で暗号化を実装する場合にもっともよく使用されるプロトコルです。SSL は、ネットワークで安全な通信を行うために暗号化プロセスを組み合わせて使用します。この節では、SSL および SSL が使用する暗号化プロセスについて簡単に説明します。
SSL は、インターネットで使用される標準的な TCP/IP ソケットプロトコルの機能を安全に拡張します。次の図「SSL を使用する TCP/IP プロトコル」で示すように、Secure Sockets Layer は標準的な TCP/IP プロトコルのトランスポート層とアプリケーション層の間に追加されます。SSL とともにもっともよく使用されるアプリケーションは Hypertext Transfer Protocol (HTTP) です。これはインターネットの Web ページ用のプロトコルです。このほかにも、Net News Transfer Protocol (NNTP)、Telnet、Lightweight Directory Access Protocol (LDAP)、Interactive Message Access Protocol (IMAP)、File Transfer Protocol (FTP) などのアプリケーションがあり、やはり SSL とともに使用します。
注: 現在のところ、安全な FTP の標準規格は存在しません。
|
TCP/IP の層 |
プロトコル |
|---|---|
|
アプリケーション層 |
HTTP、NNTP、Telnet、FTP など |
|
Secure Sockets Layer |
SSL |
|
トランスポート層 |
TCP |
|
インターネット層 |
IP |
SSL は 1994 年に Netscape 社によって開発され、インターネットの世界で使用されるようになると、標準的な存在になりました。現在では、国際的な標準化機構である Internet Engineering Task Force (IETF) が管理しています。IETF は SSL の名称を Transport Layer Security (TLS) に変更し、1999 年 1 月にバージョン 1.0 を初めて発表しました。TLS 1.0 は、SSL の最新バージョン 3.0 を少しだけ変更したものです。SSL 3.0 と TLS 1.0 にはほとんど違いがありません。
SSL を使用することの利点
次の 3 つの理由から、機密情報をネットワークで送信する際に危険が伴う場合があります。
- 通信相手のエンティティが、実際には必ずしも想定する相手とは限らない
- ネットワーク上のデータは傍受されることがあり、権限のない第三者 (場合によっては攻撃者) にデータを読み取られてしまうことがある
- 攻撃者がデータを傍受できる場合、攻撃者はデータが受信者に届く前に内容を変更できる
SSL はこれらの問題に対応しています。最初の問題には、認証と呼ばれるプロセスを通じ、通信の当事者双方に互いの識別情報を任意に確認させることで対応しています。両者が認証されると、SSL は両者を暗号化接続して安全な通信を行います。両者の通信を暗号化することで 2 番目の問題に対応し、機密性が保持されます。SSL で使用する暗号化アルゴリズムには、安全なハッシュ関数が含まれています。これはチェックサムに似ています。これにより、送信中にデータが変更されていないことが保証されます。安全なハッシュ関数により、3 番目の問題に対応し、データの整合性を確保します。
認証も暗号化もオプションであり、当事者間でネゴシエーションが行われた符号化方式に基づいていることに注意してください。
もっとも端的な SSL の使用例は電子商取引です。電子商取引では、通信するサーバの識別情報は保証されていると考えるべきではありません。クレジットカードの番号を入力するだけですばらしいサービスが受けられるという偽の Web サイトを作成するのは簡単なことです。SSL を使うと、クライアントがサーバの識別情報を認証することができます。また、サーバもクライアントの情報を認証できますが、インターネット上の取引では、この方法はあまり使われていません。
クライアントとサーバが互いの情報を認証すると、SSL は暗号化アルゴリズムを使って機密性とデータの整合性を提供します。これにより、クレジットカード番号のような機密情報をインターネット上で安全に送信することができます。
SSL は認証、機密性、およびデータの整合性を提供しますが、非拒否サービスは提供しません。非拒否性とは、メッセージを送信したエンティティは、あとになって送信を拒否することができないということを意味します。メッセージとデジタル署名が関連付けられていると、あとになって通信内容を証明することができます。SSL 単独では、非拒否性を提供しません。
SSL のしくみ
SSL が有効な理由の 1 つに、複数の暗号化プロセスを使用していることがあります。SSL は、公開鍵暗号で認証を行い、秘密鍵暗号とデジタル署名で機密性とデータの整合性を提供します。SSL について理解する前に、暗号化の処理方法を理解しておくと役立ちます。暗号化処理
暗号化の主な目的は、権限のない第三者が非公開の通信にアクセスしたり、その内容を理解するのを困難にすることです。暗号化では、データに対する権限のないすべてのアクセスを必ずしも制限できるわけではありませんが、権限のない第三者が非公開のデータを読み取れないようにすることができます。暗号化では、複雑なアルゴリズムを使用して、元のメッセージ (クリアテキスト) を符号化されたメッセージ (暗号テキスト) に変更します。通常、ネットワークで送信されるデータの暗号化および復号化に使用するアルゴリズムには 2 つのカテゴリがあります。秘密鍵暗号方式と公開鍵暗号方式です。これらの暗号方式については、以下の節で説明します。秘密鍵暗号方式も公開鍵暗号方式も、合意に基づく暗号鍵または暗号鍵のペアを使用します。鍵は、データの暗号化プロセスおよび復号化プロセスで暗号化アルゴリズムが使用するビット文字列です。暗号化鍵は錠の鍵に似ています。錠を開けることができるのは、正しい鍵だけです。
通信の当事者が互いに鍵を安全に送信するのは、些細な問題ではありません。公開鍵証明書を使うと、公開鍵を安全に送信し、受信者に公開鍵の信頼性を保証することができます。公開鍵証明書については、あとの節で説明します。
以下で説明する暗号化プロセスでは、セキュリティコミュニティで使用する名称を使います。通信の当事者をそれぞれ Alice と Bob とし、権限のない第三者を Charlie とします。Charlie は攻撃者にもなります。
秘密鍵暗号方式
秘密鍵暗号方式では、通信する Alice と Bob はメッセージの暗号化と復号化に同じ鍵を使います。暗号化されたデータをネットワークで送信する前に、Alice と Bob は鍵を持っていることが必要で、暗号化と復号化に使用する暗号化アルゴリズムに同意している必要があります。
秘密鍵暗号方式で大きな問題になるのは、攻撃者にアクセスされずに一方から他方に鍵を渡す方法です。Alice と Bob が秘密鍵暗号方式でデータを暗号化しても、Charlie がその鍵にアクセスできれば Alice と Bob の非公開メッセージを傍受することができます。Charlie は Alice と Bob のメッセージを復号化できるだけではなく、Alice になりすまして暗号化データを Bob に送信することもできるのです。Bob には、メッセージが Charlie から届いたものか Alice から届いたものかはわかりません。
秘密鍵の配布方法の問題が解決すれば、秘密鍵暗号はたいへん貴重なツールになります。そのアルゴリズムにより、優れたセキュリティと暗号化データが比較的迅速に提供できるからです。SSL セッションで送信される機密性の高いデータの多くは、秘密鍵暗号方式で送信されます。
秘密鍵暗号方式は、データの暗号化と復号化に同じ鍵を使用するので、対称暗号化方式とも呼ばれます。よく知られている秘密鍵暗号化アルゴリズムには、Data Encryption Standard (DES)、トリプル DES (3DES)、Rivest Cipher 2 (RC2)、および Rivest Cipher 4 (RC4) があります。
公開鍵暗号方式
公開鍵暗号化方式は、公開鍵と非公開鍵を使うことで鍵の配布方法を解決しました。公開鍵はネットワークを通じて公開し、送信できますが、非公開鍵は通信の 1 人の当事者にしか公開されません。公開鍵と非公開鍵は暗号化方式が逆で、一方の鍵で暗号化したものをもう一方の鍵で復号化します。
ここで、Bob が Alice に公開鍵暗号方式で秘密のメッセージを送信する場合を考えてみましょう。Alice は公開鍵と非公開鍵をどちらも持っているので、非公開鍵は安全な場所に保管しておき、公開鍵を Bob に送信します。Bob は Alice の公開鍵を使って Alice への秘密のメッセージを暗号化します。Alice は非公開鍵を使ってメッセージを復号化します。
Alice が非公開鍵を使ってメッセージを暗号化し、そのメッセージを Bob に送信すれば、Bob が受信するデータは Alice から届いたものだと考えることができます。Bob が Alice の公開鍵でデータを復号化できれば、そのメッセージは Alice が自分の非公開鍵で暗号化したものに間違いありません。Alice の非公開鍵を持っているのは Alice だけだからです。問題は、Alice の公開鍵が公開されているために、だれもがメッセージを読めてしまうことです。このシナリオは、安全なデータ通信を考慮に入れていませんが、デジタル署名の基本には触れています。デジタル署名とは公開鍵証明書のコンポーネントの 1 つで、SSL でクライアントやサーバを認証するために使用します。公開鍵証明書とデジタル署名については、あとの項で説明します。
公開鍵暗号方式は、データの暗号化と復号化に同じ鍵を使用するので、非対称暗号化方式とも呼ばれます。SSL を使用することが多い、よく知られている公開鍵暗号化アルゴリズムには、Rivest Shamir Adleman があります。このほかにも、秘密鍵を交換するために設計された SSL を使う公開鍵暗号化アルゴリズムには、Diffie-Hellman (DH) があります。公開鍵暗号方式には膨大な計算が必要なため、速度が遅くなります。そこで、この方式は暗号化データ通信全体に使用するよりもむしろ、秘密鍵など少量のデータを暗号化する場合にだけ使用します。
秘密鍵暗号方式と公開鍵暗号方式の比較
秘密鍵暗号方式と公開鍵暗号方式のどちらにも、長所と弱点があります。秘密鍵暗号方式では、データの暗号化や復号化に時間はかかりませんが、通信者同士が同じ秘密鍵情報を持つ必要があり、鍵の交換方法が問題になります。公開鍵暗号方式では、鍵を秘密にする必要がないので交換方法は問題になりません。しかしデータの暗号化と復号化に使用するアルゴリズムには膨大な計算が必要で、速度が遅くなります。
公開鍵証明書
公開鍵証明書を使うと、エンティティは非対称暗号方式で使用する公開鍵を安全に配布できます。公開鍵証明書は次のような状況を回避します。Charlie が自分の公開鍵と非公開鍵を作成すれば、自分は Alice だと名乗って Bob に公開鍵を送信できます。Bob は Charlie と通信できますが、データを Alice に送信していると思い込んでしまいます。
公開鍵証明書は電子的なパスポートだと考えることができます。これは、信頼できる組織によって発行され、所有者に識別情報を提供します。公開鍵証明書を発行する信頼できる組織を、証明書発行局 (CA) と呼びます。CA は公証人に例えることができます。CA から証明書を取得するには、識別情報の証拠となるものを提供する必要があります。CA は、申請者が申し立てる組織の代表であるとの確証が得られたら、証明書に含まれる情報の妥当性を証明する証明書に署名します。
公開鍵証明書には、次のようなフィールドがあります。
- 発行者 - 証明書を発行した CA です。証明書を発行する CA が信頼でき、証明書が有効であれば、証明書は信頼できます。
- 有効期間 - 証明書には期日があります。証明書の妥当性を検証する場合は、この日付は確認すべき情報の 1 つになります。
- 被認証者 - 被認証者フィールドには、証明書が表すエンティティの情報が含まれます。
- 被認証者の公開鍵 - 証明書が提供する主な情報に、被認証者の公開鍵があります。その他のフィールドは、この鍵の妥当性を確認するためのものです。
- 署名 - 証明書は、証明書を発行した CA によって電子的に署名されます。署名は CA の非公開鍵を使って作成され、証明書の妥当性を保証するものです。証明書にだけ署名され、SSL トランザクション送信されるデータには署名されないので、SSL には非拒否性がありません。
Alice が Bob に公開鍵証明書で自分の公開鍵を送信するとき、Bob が Alice の公開鍵を有効であると認める以外のことを行わない場合、Charlie が Alice になりすましたとしても、Bob が Charlie に秘密情報を送信することはありません。
複数の証明書を証明書チェーンでリンクすることもできます。証明書チェーンを使用する場合、最初の証明書は必ず送信者の証明書です。次は送信者の証明書を発行したエンティティの証明書です。チェーン内にさらに証明書がある場合、直前の証明書を発行した証明書発行局の証明書が続きます。チェーンの最後の証明書は、ルート CA の証明書です。ルート CA は、広く信頼されている公開証明書発行局です。複数のルート CA の情報は、通常、クライアントのインターネットブラウザに保存されています。この情報には、CA の公開鍵が含まれています。よく知られている CA には VeriSign、Entrust、および GTE CyberTrust があります。
暗号化ハッシュ関数
暗号化されたデータを送信する場合、SSL は通常、暗号化ハッシュ関数を使ってデータの整合性を保証します。ハッシュ関数を使って、Alice が Bob に送ったデータを Charlie が改ざんできないようにします。
暗号化ハッシュ関数はチェックサムに似ています。主な違いは、チェックサムがデータの偶発的変化を検出するのに対し、暗号化ハッシュ関数は故意による変更を検出するということです。データが暗号化ハッシュ関数で処理されると、ハッシュと呼ばれる小さなビット文字列が生成されます。メッセージがごくわずかだけ変更された場合も、結果として生成されるハッシュは大きく変更されます。暗号化ハッシュ関数には、暗号化鍵が必要ありません。SSL とともに使用されることが多いハッシュ関数には、Message Digest 5 (MD5) と Secure Hash Algorithm (SHA) の 2 つがあります。SHA は、U.S. National Institute of Science and Technology (NIST) によって提案されました。
メッセージ認証コード
メッセージ認証コード (MAC) は暗号化ハッシュに似ていますが、秘密鍵をベースにしている点が異なります。秘密鍵情報が暗号化ハッシュ関数で処理したデータに含まれている場合、その結果生成されるハッシュは HMAC と呼ばれます。Alice は、Bob へのメッセージを Charlie が傍受していないことを確認したい場合、メッセージの HMAC を計算して元のメッセージに HMAC を追加できます。次に、Bob と共有している秘密鍵を使ってメッセージと HMAC を暗号化します。Bob は、メッセージを復号化して HMAC を計算すれば、送信中にメッセージが変更されたかどうかを知ることができます。SSL では、HMAC を使って安全なデータを送信します。
デジタル署名
メッセージに暗号化ハッシュが作成されると、ハッシュは送信者の非公開鍵で暗号化されます。このような暗号化ハッシュをデジタル署名と呼びます。
SSL 処理
SSL を使った通信は、クライアントとサーバ間の情報交換から始まります。この情報交換を SSL ハンドシェークと呼びます。
SSL には、主に次のような 3 つの目的があります。
- 符号化方式のネゴシエーション
- 情報の認証 (オプション)
- 暗号化機構の同意による情報セキュリティの確立
符号化方式のネゴシエーション
SSL セッションは、どの符号化方式を使用するかについて、クライアントとサーバがネゴシエーションを行うことから始まります。符号化方式とは、コンピュータがデータを暗号化するために使用する暗号化アルゴリズムと鍵のサイズです。符号化方式には、公開鍵交換アルゴリズムまたは鍵協定アルゴリズム、およびおよび暗号化ハッシュ関数に関する情報が含まれます。クライアントは利用できる符号化方式をサーバに伝え、サーバは、どちらにも適用できる符号化方式を選択します。
サーバの認証
SSL の認証ステップは省略できます。しかし、Web 上の電子商取引では、一般的にクライアントがサーバを認証します。サーバの認証により、サーバが表すとクライアントが信じているエンティティを、そのサーバが実際に表していることをクライアントが確認できます。
サーバは、自らが表すと唱える組織に属していることを証明するため、クライアントに公開鍵証明書を提示します。この証明書が有効であれば、クライアントはサーバの識別情報について確信できます。
クライアントとサーバは、同じ秘密鍵について同意できる情報を交換します。たとえば、RSA を使う場合、クライアントは公開鍵証明書で取得したサーバの公開鍵を使用して、秘密鍵情報を暗号化します。クライアントは暗号化された秘密鍵情報をサーバに送信します。復号化にはサーバの非公開鍵が必要なので、サーバでだけ、このメッセージを復号化できます。
暗号化されたデータの送信
クライアントとサーバは、同じ秘密鍵にアクセスします。それぞれのメッセージでは、この処理の最初の段階で選択した、秘密情報を共有する暗号化ハッシュ関数を使って、メッセージに添付される HMAC を計算します。次に、秘密鍵と、この処理の最初の段階で設定した秘密鍵アルゴリズムを使い、安全なデータと HMAC を暗号化します。その後、クライアントとサーバは、暗号化されハッシュ化されたデータを使って安全に通信することができます。
SSL プロトコル
前の節では、SSL ハンドシェークを上位レベルで説明しました。つまり、暗号化されたメッセージを送信する前にクライアントとサーバで行われる情報交換について説明しました。この節では、さらに詳しく説明します。
次の「SSL メッセージ」には、SSL ハンドシェークで交換される一連のメッセージが示されています。特定の状況下でだけ送信されるメッセージには (Optional) と記されています。SSL メッセージの説明は次のとおりです。
SSL メッセージは、次の順序で送信されます。
- Client hello - クライアントはサーバ情報を送信します。この情報には、自分がサポートする最上位バージョンの SSL と符号化方式のリストが含まれます。TLS 1.0 は SSL 3.1 と表示されます。符号化方式の情報には、暗号化アルゴリズムと鍵のサイズが含まれます。
- Server hello - サーバは、クライアントとサーバの両方がサポートする最上位バージョンの SSL と最適な符号化方式を選択し、この情報をクライアントに送信します。
- Certificate - サーバはクライアントに証明書または証明書チェーンを送信します。証明書チェーンは通常、サーバの公開鍵証明書で始まり、認証局のルート証明書で終わります。このメッセージはオプションで、サーバ認証を求められた場合に使用します。
- Certificate request - サーバがクライアントを認証する必要がある場合、クライアントに証明書要求を送信します。インターネットアプリケーションでは、このメッセージが使われることはほとんどありません。
- Server key exchange - 上記の 3 で送信した公開鍵情報が鍵交換を行うのに不十分な場合、サーバはクライアントにサーバ鍵交換メッセージを送信します。
- Server hello done - サーバは、最初のネゴシエーションメッセージを終了したことをクライアントに伝えます。
- Certificate - メッセージ 4 でサーバがクライアントに証明書を要求すると、クライアントはメッセージ 3 でサーバが行なったようにして、証明書チェーンを送信します。
注: クライアントに証明書を要求するのは、ごく一部のインターネットサーバアプリケーションだけです。
- Client key exchange - クライアントは、対称暗号方式で使用する鍵を作成する情報を生成します。RSA では、クライアントはサーバの公開鍵でこの鍵情報を暗号化してサーバに送信します。
- Certificate verify - このメッセージは、上述のとおりクライアントが証明書を提示する場合に送信されます。このメッセージは、サーバにクライアントの認証処理を完了させるためのものです。このメッセージが使用されると、クライアントは暗号化ハッシュ関数で電子的に署名した情報を送信します。サーバがクライアントの公開鍵でこの情報を復号化すれば、サーバはクライアントを認証できます。
- Change cipher spec - クライアントはメッセージを送信し、暗号化モードを変更するようサーバに伝えます。
- Finished - クライアントはサーバに、安全なデータ通信を開始する準備ができたことを伝えます。
- Change cipher spec - サーバはメッセージを送信し、暗号化モードを変更するようクライアントに伝えます。
- Finished - サーバはクライアントに、安全なデータ通信を開始する準備ができたことを伝えます。SSL ハンドシェークが終了します。
- Encrypted data - クライアントとサーバは、メッセージ 1 と 2 で取り決めた対称暗号化アルゴリズムと暗号化ハッシュ関数、およびメッセージ 8 でクライアントがサーバに送信した秘密鍵を使って通信します。
- Close Messages - 接続の終わりに、それぞれの側が close_notify メッセージを送信し、接続が終了したことをピアに伝えます。
SSL セッションで生成したパラメータを保存しておけば、それ以降も SSL セッションで利用することができます。SSL セッションのパラメータを保存しておけば、暗号化通信をすばやく開始できます。
符号化方式の選択とリモートエンティティの検証
SSL/TLS プロトコルでは、保護された接続を確保するための一連の具体的な手順を定義しています。ただし、選択する符号化方式により、接続で確保するセキュリティの種類が決まります。たとえば、匿名符号化方式を選択した場合、アプリケーションにはリモートピアの識別情報を検証する手段がありません。暗号化なしの符号化方式が選択された場合は、データの機密性を保護できません。また SSL/TLS プロトコルでは、受信した資格と、ピアから送信されることが予期される資格が一致するようにとは規定していません。接続が何らかの理由で悪意のあるピアにリダイレクトされたときに、悪意のあるピアの資格が現在のトラストデータに基づいて受け入れられた場合、その接続は有効と見なされてしまいます。raw
SSLSockets/SSLEnginesを使用する場合は、データの送信前に必ずピアの資格をチェックしてください。SSLSocketクラスとSSLEngineクラスは、URL のホスト名がピアの資格にあるホスト名と一致するかどうかを自動的に検証しません。ホスト名が検証されなければ、URL 不正行為によって被害を受ける可能性があります。https などのプロトコルは、ホスト名の検証処理が不要です。アプリケーションは、
HostnameVerifierを使用してデフォルトの HTTPS ホスト名規則を上書きできます。詳細については、「HttpsURLConnection」 を参照してください。
SSL と TLS に関する参照資料
SSL についての参考資料は、「Secure Sockets Layer の関連ドキュメント」を参照してください。
