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