|
次のページ
前のページ
目次へ
2. Secure Sockets Layer/Private Key Infrastructure への招待PKI は、公開鍵 (クライアントに送られます) と秘密鍵 (サーバ上に存在します) からなる、非対称の鍵システムです。PKI は、クライアントとサーバの両方が 暗号化/復号化に同じ鍵を使う、対称の鍵システムとは異なります。
2.1 SSL/PKI の信頼性クレジットカード情報や医療記録、法律文書、e-commerce アプリケーションといった、 最も機密に注意しなければならない処理の通信にも利用可能であるように、 という要求を満たすために SSL は設計されました。 各アプリケーションは、機密性や処理される取引の価値によって、 以下の特徴のどれを (あるいはすべてを) 使うか選択できます。
2.2 SSL はどう機能するのかSSL プロトコルは、2 つのサブプロトコルを含みます − SSL レコードプロトコルと SSL ハンドシェイクプロトコルです。SSL レコードプロトコルはデータの伝送に使う フォーマットを定義します。SSL ハンドシェイクプロトコルには、 SSL レコードプロトコルの利用が含まれています。 これは SSL 化されたサーバとクライアントが最初に SSL 接続を確立するときに やりとりする一連のメッセージ交換に用いられます。 このメッセージ交換は、以下の機能を容易にするべく設計されています。
SSL ハンドシェイクプロトコルハンドシェイクプロトコルは、クライアントとサーバの状態を調整するのに 使われます。ハンドシェイクの間、以下のイベントが発生します −
注: IP アドレスは、各 SSL 接続毎に必要になります。 名前ベースのヴァーチャルホストはアプリケーション層で解決されます。 SSL がアプリケーション層の下に存在していることを思い出しましょう。
セッション鍵 (対称鍵)
公開/秘密鍵のペア(非対称コード)
2.3 PKI の仕組みクライアントとサーバは、それぞれ公開鍵と秘密鍵を持ちます (クライアントが 自分の証明書を持っており、それがサーバに要求されない限り、クライアントの ブラウザは SSL のセッション用に鍵のペアをランダムに生成します)。
送信者は、自分の秘密鍵を使ってメッセージを暗号化します。これにより、 メッセージのソースが認証されます。結果の暗号は、受け手の公開鍵で もう一度暗号化されます。これは、受け手のみが、自身の秘密鍵を使ってメッセージを 最初に解読することができるようにすることで、機密性をもたらします。 受信者は、暗号化されたメッセージをさらに解読するため、送信者の公開鍵を 使います。送信者のみが自分の秘密鍵にアクセスできるので、受信者は 暗号化されたメッセージがその送信者からのものであるということを保証されます。
メッセージダイジェストは、関係者も第三者も、メッセージに何らかの改竄や 変更を施していないことを確認するのに利用されます。メッセージダイジェストは、 メッセージにハッシュ関数 (指紋として知られる、秘密鍵の一部) を使うことで 得られます。ダイジェスト (署名と呼ばれます) はメッセージに添付あるいは 追加されます。署名の長さは (メッセージの長さに関らず) 一定で、 秘密鍵がもつメッセージダイジェストのタイプ (md5 は 128 ビット、 sha1 なら 160 ビット、など) によります。メッセージをたった 1 ビット変更した だけでも署名の長さは変化するので、メッセージが変更されたことが証明されます。
2.4 証明書(x509 標準)デジタル証明書はインターネット上の存在を信頼できるようにします。 デジタル署名は、中立の第三者である証明書発行機関によって立証された、 ユーザの保証書を含みます。
数学的なアルゴリズムと値 (鍵) がデータを読めない形に暗号化するために使われます。 データの復号には 2 つめの鍵が用いられ、 これは相補的なアルゴリズムと値を使います。 2 つの鍵は関連づけられた値を持っていなければならず、 鍵のペア と呼ばれます。
注:ITU-T の勧告 X.509 [CCI88c] は X.509 証明書の記法のみならず、 X.500 ディレクトリへの認証サービスの仕様を定めています。 証明書は、対象の(ユーザの)名前とユーザの公開鍵とのつながりを認証するために、 発行者によって署名されます。SSLv3 は 1994 年に採択されました。 バージョン 2 と 3 の主な違いは、拡張フィールドが追加されたことです。 このフィールドにより、単なる鍵と名前のつながりだけでなく、追加の情報を 伝達することができるようになり、より柔軟になります。標準的な拡張では、 対象と発行者の帰属、認証ポリシー情報、鍵の利用制限などが含まれます。
X.509 証明書は、これらのフィールドで構成されます −
2.5 デジタル証明書の秘密鍵秘密鍵は、デジタル証明書に埋めこまれてはいません。秘密鍵はどんなサーバ情報も もちません。秘密鍵が持つのは暗号情報と指紋です。これは自分のシステム上で ローカルに生成され、安全な環境のままでなければなりません。秘密鍵が危険に さらされれば、加害者は、本質的にそのセキュリティシステムのコードを手に したことになります。クライアントとサーバ間の送信は、傍受され、解読され得ます。 こういった弱点が、triple DES 技術を使って暗号化された秘密鍵を作ることが 推奨されている理由です。 するとファイルは暗号化され、パスワードで保護されます。これにより、 正確なパスフレーズなしに使うことがほとんど不可能になります。
トランザクションのセキュリティは、その秘密鍵に依存します。この鍵が 誤った人手にわたったら、誰でも簡単にその合鍵を作って、セキュリティを 破るために使用できます。 危うい鍵は、サーバへのメッセージが無法なハッカーによって傍受され、操作される 事態を招きかねません。 完全にセキュアなシステムでは、詐称を検知でき、鍵の複製を妨害するように なっていなければなりません。
2.6 デジタル証明書の公開鍵公開鍵はデジタル証明書に埋めこまれており、セキュアな接続が要求された時に、 サーバからクライアントへ送られます。この過程により、証明書を使ってサーバの 身元が確認されます。公開鍵は完全性、信憑性を検証し、秘密のデータ転送を するためにデータを暗号化するのにも使われます。
2.7 証明書署名要求(CSR)CSR は証明書発行機関が証明書を作成するのに必要となる情報を含むものです。 CSR は、秘密鍵に対して相補的なアルゴリズム、 サーバの身元を証明する情報を もちます。この情報には、国、州、組織、一般名(ドメイン名)、連絡先といった情報が 含まれますが、限定されるわけではありません。
次のページ 前のページ 目次へ |
[ |