Secure Socket Layer プロトコルは Netscape 社によって web サーバとブラウザの間の安全な通信を保証するために作り出されました。 このプロトコルは通信の一方の端、または両端の身元を保証するために、 認証局 (Certificate Authority, CA) と呼ばれる第三者を用います。 以下が簡単なその仕組みです。
ブラウザがセキュアなページ（通常 https:// ）を要求する。
その web サーバが、その証明書と一緒にその公開鍵を送る。
ブラウザはその証明書が信用が与えられた機関 （通常は信用が与えられたルート認証局(root CA)）によって発行されたものであること、 その証明書がまだ有効であって、そして、 その証明書が接続しようとしているそのサイトと関係づけられていることをチェックする。
そして、ブラウザはその公開鍵を用いてランダムに選んだ対称鍵を暗号化し、 その鍵と要求された URL を暗号化したものを、他の暗号化した http データとともに送る。
web サーバは自分の秘密鍵を用いて、送られてきた対称鍵を復号し、 その対称鍵を用いて URL と http データを復号する。
web サーバは要求された html ドキュメントと http データを対称鍵で 暗号化して送り返す。
ブラウザはその http データと html ドキュメントを対称鍵を用いて復号し、 その情報を表示する。
以上で理解しなくてはならない概念がいくつか出てきました。
秘密鍵/公開鍵の鍵ペアを用いる暗号化は、 データが一方の鍵で暗号化されると、その対である他方の鍵でしか復号できない、 ということを保証します。 理解するのが難しいですが、私を信じてうまく行くことにしてください。 その鍵は自然にあるものと似ていますが、違う使い方ができます。 つまり、一方の鍵が暗号化すると、その対の鍵で復号化できるのです。 この鍵対は素数の性質に基づいていて、 それらのビット長が対の鍵なしにメッセージを復号する困難さを保証します。 鍵ペアを使う根本のアイデアは、片方の鍵を秘密にしておき（秘密鍵）、 そしてその対の他方の鍵をみんなに公開してしまう（公開鍵）ことです。 だれでもあなたに暗号化したメッセージを送ることが出来て、 あなただけがそれを復号化することが出来るのです。 あなたは対になっている他方の鍵を持っているただ一人の人なのですから。 でしょう？ この逆に、 あるメッセージが確かにあなたから来たものだと保証することもできます。 なぜなら、あなたが自分の秘密鍵で暗号化したものは、 それと対になっている公開鍵だけが正しく復号できるからです。 この場合には、メッセージは安全ではなく、 単にあなたが署名しただけだということに注意してください。 みんながその公開鍵を持っているのだということを忘れずに！
残された問題の一つは通信相手の公開鍵を知ることです。 通常は、証明書と同じく公開鍵も含まれた、 秘密でない署名入りメッセージを送ってもらうよう相手に要求します。
Message-->[Public Key]-->Encrypted Message-->[Private Key]-->Message |
自分が正しい人物、またはこの場合の方が多いでしょうが、 正しい web サイトとやりとりをしているのだと、 どうすれば知ることが出来るのでしょう。 ええ、web サイトの所有者は彼らが主張している人物たちだと 保証するために、大変な手間をかけています （もし彼らがセキュリティについて真剣ならばですが）。 この人たちと、その通信相手であるあなたは、暗黙のうちに、 彼、または彼女の証明書（ルート証明書）を自分のブラウザに読み込んでいること、 を仮定しなければなりません。 証明書にはその証明書の所有者の情報、例えば e-mail アドレスや、名前や、 証明書の使用目的、有効期間、情報の場所、または 通常名(Common Name, CN)を含む識別名(Distinguish Name, DN) （web サイトのアドレスや e-mail アドレスは用法に依存します）、 そしてこの情報に保証を与えた（つまり署名した）人物の証明書 ID が含まれています。 さらに、証明書はその公開鍵を含み、最後に、 その証明書全体が改竄されていないことを保証するためのハッシュ値を含んでいます。 この証明書に署名した人を信用するという選択をした以上、 それゆえにこの証明書の内容も信じることになります。 これは証明書の信用ツリーまたは認証径路と呼ばれるものです。 通常は、あなたのブラウザやアプリケーションは既に、よく知られている 認証機関(Certificate Authorities, CA) のルート証明書か、 ルート認証局証明書(root CA Certificates)を組み込み済みです。 CA（認証局）は全ての署名入り証明書のリストと、 同じように無効になった証明書のリストを維持しています。 署名された証明書だけが改竄不可能なのですから、 証明書はそれが署名されるまでは安全ではありません。 自分自身で自分の証明書に署名することもでき、 これは自己署名証明書と呼ばれています。 全ての root CA（ルート認証局）の証明書は自己署名しています。
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=SOPAC Root CA/Email=administrator@sopac.org
Validity
Not Before: Nov 20 05:47:44 2001 GMT
Not After : Nov 20 05:47:44 2002 GMT
Subject: C=FJ, ST=Fiji, L=Suva, O=SOPAC, OU=ICT, CN=www.sopac.org/Email=administrator@sopac.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:ba:54:2c:ab:88:74:aa:6b:35:a5:a9:c1:d0:5a:
9b:fb:6b:b5:71:bc:ef:d3:ab:15:cc:5b:75:73:36:
b8:01:d1:59:3f:c1:88:c0:33:91:04:f1:bf:1a:b4:
7a:c8:39:c2:89:1f:87:0f:91:19:81:09:46:0c:86:
08:d8:75:c4:6f:5a:98:4a:f9:f8:f7:38:24:fc:bd:
94:24:37:ab:f1:1c:d8:91:ee:fb:1b:9f:88:ba:25:
da:f6:21:7f:04:32:35:17:3d:36:1c:fb:b7:32:9e:
42:af:77:b6:25:1c:59:69:af:be:00:a1:f8:b0:1a:
6c:14:e2:ae:62:e7:6b:30:e9
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
FE:04:46:ED:A0:15:BE:C1:4B:59:03:F8:2D:0D:ED:2A:E0:ED:F9:2F
X509v3 Authority Key Identifier:
keyid:E6:12:7C:3D:A1:02:E5:BA:1F:DA:9E:37:BE:E3:45:3E:9B:AE:E5:A6
DirName:/C=FJ/ST=Fiji/L=Suva/O=SOPAC/OU=ICT/CN=SOPAC Root CA/Email=administrator@sopac.org
serial:00
Signature Algorithm: md5WithRSAEncryption
34:8d:fb:65:0b:85:5b:e2:44:09:f0:55:31:3b:29:2b:f4:fd:
aa:5f:db:b8:11:1a:c6:ab:33:67:59:c1:04:de:34:df:08:57:
2e:c6:60:dc:f7:d4:e2:f1:73:97:57:23:50:02:63:fc:78:96:
34:b3:ca:c4:1b:c5:4c:c8:16:69:bb:9c:4a:7e:00:19:48:62:
e2:51:ab:3a:fa:fd:88:cd:e0:9d:ef:67:50:da:fe:4b:13:c5:
0c:8c:fc:ad:6e:b5:ee:40:e3:fd:34:10:9f:ad:34:bd:db:06:
ed:09:3d:f2:a6:81:22:63:16:dc:ae:33:0c:70:fd:0a:6c:af:
bc:5a
-----BEGIN CERTIFICATE-----
MIIDoTCCAwqgAwIBAgIBATANBgkqhkiG9w0BAQQFADCBiTELMAkGA1UEBhMCRkox
DTALBgNVBAgTBEZpamkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQww
CgYDVQQLEwNJQ1QxFjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0B
CQEWF2FkbWluaXN0cmF0b3JAc29wYWMub3JnMB4XDTAxMTEyMDA1NDc0NFoXDTAy
MTEyMDA1NDc0NFowgYkxCzAJBgNVBAYTAkZKMQ0wCwYDVQQIEwRGaWppMQ0wCwYD
VQQHEwRTdXZhMQ4wDAYDVQQKEwVTT1BBQzEMMAoGA1UECxMDSUNUMRYwFAYDVQQD
Ew13d3cuc29wYWMub3JnMSYwJAYJKoZIhvcNAQkBFhdhZG1pbmlzdHJhdG9yQHNv
cGFjLm9yZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAulQsq4h0qms1panB
0Fqb+2u1cbzv06sVzFt1cza4AdFZP8GIwDORBPG/GrR6yDnCiR+HD5EZgQlGDIYI
2HXEb1qYSvn49zgk/L2UJDer8RzYke77G5+IuiXa9iF/BDI1Fz02HPu3Mp5Cr3e2
JRxZaa++AKH4sBpsFOKuYudrMOkCAwEAAaOCARUwggERMAkGA1UdEwQCMAAwLAYJ
YIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1Ud
DgQWBBT+BEbtoBW+wUtZA/gtDe0q4O35LzCBtgYDVR0jBIGuMIGrgBTmEnw9oQLl
uh/anje+40U+m67lpqGBj6SBjDCBiTELMAkGA1UEBhMCRkoxDTALBgNVBAgTBEZp
amkxDTALBgNVBAcTBFN1dmExDjAMBgNVBAoTBVNPUEFDMQwwCgYDVQQLEwNJQ1Qx
FjAUBgNVBAMTDVNPUEFDIFJvb3QgQ0ExJjAkBgkqhkiG9w0BCQEWF2FkbWluaXN0
cmF0b3JAc29wYWMub3JnggEAMA0GCSqGSIb3DQEBBAUAA4GBADSN+2ULhVviRAnw
VTE7KSv0/apf27gRGsarM2dZwQTeNN8IVy7GYNz31OLxc5dXI1ACY/x4ljSzysQb
xUzIFmm7nEp+ABlIYuJRqzr6/YjN4J3vZ1Da/ksTxQyM/K1ute5A4/00EJ+tNL3b
Bu0JPfKmgSJjFtyuMwxw/Qpsr7xa
-----END CERTIFICATE----- |
もうお気づきになっているように、 証明書はその発行者への参照を含んでいて、 証明書の所有者の公開鍵、証明書の有効期間と この証明書が改竄されていないことを保証するための証明書の署名が含まれています。 証明書は秘密鍵を含みません。秘密鍵はどんな形式であろうが 決して誰かに渡すべきでないからです。 この証明書は所有者に暗号化メッセージを送り、 そしてメッセージがこの証明書の所有者によって署名されていることを保証するための、 全ての情報を含んでいます。
ええ、秘密鍵/公開鍵暗号アルゴリズムは偉大です。しかし、 これは通常使うものとしては現実的でありません。 復号化するためには別の鍵が必要ですから、これは非対称的です。 暗号化と復号化に同じ鍵を使うことはできません。 復号化と暗号化に同じ鍵を用いるアルゴリズムは対称鍵を持つと呼ばれます。 対称なアルゴリズムは非対称なアルゴリズムよりずっと速く仕事をこなします。 しかし、対称鍵は潜在的に非常に危険です。 もし敵がその鍵を手に入れたら、あなたはもはや秘密の情報はなくなります。 ですから、敵の手に渡すことなくその鍵を相手に送らなければなりません。 ご存知のように、インターネット上には安全なものは何一つありません。 この解決策はその対称鍵を非対称アルゴリズムで暗号化したメッセージの カプセルの中に入れることです。 秘密鍵は決して誰にも渡しませんから、公開鍵で暗号化されたメッセージは安全です （正確に言えば、比較的安全です。死と税金以外に確かなものは何もないのですから）。 対称鍵はランダムに選ばれますから、 もし対称鍵が発見されても、次の通信では全く異なることになります。
Symetric Key-->[Public Key]-->Encrypted Symetric Key-->[Private Key]-->Symetric Key |
可能な暗号化アルゴリズムには、 色々な鍵の長さの、対称的なもの、非対称的なもの、と様々あります。 通常は、アルゴリズムで特許をとることはできません。 もし、ポアンカレが自分のアルゴリズムの特許をとっていたら、 アインシュタインを訴えることができたでしょう… そういうわけでアルゴリズムでは特許をとることはできません、 ただしアメリカ合衆国が主な例外です。 OpenSSL は、アルゴリズムで特許がとることができない、 そして暗号化技術が軍や情報機関のような国家機関だけに制限されてはいない 国で開発されています。 ブラウザと web サーバのネゴシエーション（プロトコルのやりとり）の間に、 その双方のアプリケーションは望ましい順番に並べた可能なアルゴリズムのリストを 見せあいます。 そして共通の望ましいアルゴリズムが選ばれます。 OpenSSL は、特定のアルゴリズムを含めたり、除いたりした形でコンパイル可能ですから、 制限が適用されている多くの国でも使えるのです。
ハッシュ（ハッシュ値） とはハッシュ関数によってメッセージから作られたある数字のことです。 これは一方通行関数で、つまり、 そのハッシュから元のメッセージを得ることが不可能であることを意味しています。 しかし、ハッシュは元のメッセージがほんの少し変更されても劇的に変化します。 よって、そのハッシュを変えないままメッセージを変形することは非常に困難です。 ハッシュはメッセージ要約 (message digest) とも呼ばれます。 ハッシュ関数はパスワード方式の仕組みや、 アプリケーションがオリジナルであることを保証するためや（MD5 チェックサム）、 一般にはメッセージが改竄されていないことを確証するために使われます。 IETF (Internet Engineering Task Force) はいくつかの技術的な理由から MD5 より SHA1 の方が望ましいハッシュ関数であると考えているようです （RFC2459 7.1.2. と 7.1.3. を参照のこと）。
メッセージに署名することは、そのメッセージの真正性をあなた自身が保証した、 ということを意味します（ほとんどの場合はあなたが著者でしょうが、 必ずしもそうでなくても構いません）。 そのメッセージは普通のテキストであったり、誰かの証明書であるという場合もあるでしょう。 あなたがメッセージに署名するためには、 まずメッセージのハッシュを作成し、あなたの秘密鍵によってそのハッシュを暗号化して、 その暗号化されたハッシュと署名された証明書をメッセージに添付します。 これを受け取った方は、 メッセージのハッシュを独立に再び作成し、 あなたの署名入りの証明書から取り出したあなたの公開鍵で復号化して元のハッシュを得て、 この二つのハッシュが等しいかどうかをチェックし、 最後に証明書をチェックします。
メッセージに署名する他の利点は、 全ての受け取り手に対して自動的に公開鍵と証明書を送ることになることです。
通常、署名には二通りの方法があります。 署名の中にテキストメッセージを（区切り指定文字を入れて）カプセル化する形式と、 メッセージを署名と一緒にコード化してしまう方法です。 後の形式は非常に単純な暗号化で、 埋め込まれた公開鍵を読めればどんなソフトウェアでも復号できます。 最初の形式の利点は、メッセージが人間に読むことができて、 それを読むユーザへとメッセージを渡すクライアントに何の問題も生じない一方、 二番目の形式ではメッセージが改竄されていると、 メッセージの一部を読むことさえできないことです。
“パスフレーズはパスワードより長いという以外にはパスワードと 同じようなものです”。 初期には Unix システムでのパスワードは８文字までに限られていたので、 より長いパスワードをパスフレーズと言うのです。 パスワードが長ければ長いほど、推測するのが難しくなります。 現在の Unix システムでは MD5 を使うことで、 パスワードの長さの制限はなくなっています。
公開鍵基盤(PKI, Public Key Infrastructure)とは、 証明書に署名し、無効になった証明書のリストを維持し、公開鍵を配布するといったことを 可能にするためのソフトウェアとデータベースのシステムのことです。 通常は、web サイトか ldap サーバ、またはその両方を通じてこれにアクセスします。 そこでは誰かが、あなたが本当にあなたであることをチェックしていることになるでしょう。 個々のアプリケーションの安全性を高めるには、 良く知られた商用の PKI を用いることができます。 これは、おそらくその root CA の証明書が、 ブラウザやアプリケーションに既に組み込まれているからです。 問題点は、安全に e-mail を使いたい場合で、 あなたは e-mail の一般的なタイプの証明書を手に入れるか、 または証明書/e-mail ごとに一年あたり約 100 USドルを払わなくてはなりません。 もし、以前に（公開鍵を含んだ）証明書つきの e-mail を一度も受け取っていないと、 誰かの公開鍵を見つける方法もありません。