Alice と Bob の 2 つのクライアントは、サーバーを使用してログインし、サーバーを介してメッセージを交換します。ログイン時に、両方とも公開鍵を送信してサーバーに保存します。Alice が Bob と話したいときは、Bob の公開鍵で対称鍵を暗号化し、それをサーバー経由で Bob に送信します。
サーバーが独自の公開鍵ペアを作成せず、ボブの公開鍵の代わりにアリスに送信しないようにするにはどうすればよいですか。このようにして、サーバーは最初に Alice が送信したものを復号化し、Bob の実際の公開鍵を使用して再度暗号化します。
ありがとう
Alice と Bob はサーバーを信頼できないため、お互いのキーを確認する別の方法を見つける必要があります。1 つの可能性は、別のパーティに依存することです。アリスを知っているボブがキャンディスを信頼する (そしてキャンディスの公開鍵を知っている) 場合、キャンディスはアリスの公開鍵に署名し、署名されたバージョンをボブに送信できます。これは信頼の網と呼ばれます。
ボブの証明書に信頼できる第三者 (Verisign、あなたの会社、Web of Trust など) によって署名してもらうか、Bob に自分の証明書を帯域外の別の安全なパスを介して Alice に送信させる (USB キーを直接渡す)例えば）。
これらは両方とも、ボブの証明書が何を意味するのかという核心に迫るものです。ボブの証明書がボブの証明書であることだけを信頼します。信頼できる誰かが証明したからです。その「誰か」は、ボブ自身か、ボブの証明書に署名した信頼できる第三者です。認証者を信頼する限り、これを信頼することはできません。
暗号化では、あなたはあなたが知っていることです。MITMを回避したい場合、アリスは「ボブ」が誰であるかという概念を持っている必要があります。つまり、ボブは攻撃者が知らないデータ要素を知っている必要があります。ここで、攻撃者はサーバーであり、攻撃を仕掛けるのに理想的な場所にあります。
だから問題は：ボブは誰ですか？サーバーはどのように「ボブではない」のですか？
たとえば、「ボブ」は次のように定義できます。「ボブは、「ボブ」と書かれた運転免許証を持っている人間です」。または：「ボブは私がバーで会ってビールを飲んだあの男です」。
非対称暗号化を使用すると、問題を公開鍵の信頼性の問題に減らすことができます。アリスは、ボブの公開鍵であると彼女が信じているものを使用します。したがって、アリスは、自分が持っている公開鍵が実際にボブによって所有されていることを確認するための何らかの方法を必要とするだけです。公開鍵の所有権は、対応する秘密鍵の制御によって定義されます。ボブの公開鍵は、秘密鍵がボブの排他的制御下にある鍵です（たとえば、ボブだけがその鍵を知っているか、秘密鍵がハードウェアトークンにあります）。 -スマートカード-ボブが自分の財布に保管しているもの）。
基本的な解決策は、公開鍵を直接交換することです。アリスがバーでボブに会ったとき、彼らはお互いに公開鍵を与えました。したがって、アリスは「定義上」ボブの公開鍵を信頼できます。交換を容易にするために（特にビールを数杯飲んだ後）、アリスとボブは「指紋」、つまり公開鍵で計算されたハッシュ値のみを交換できます。これらの値は公開鍵よりも短く（たとえば、一般的なRSA公開鍵の1000ビットを超えるのではなく、128ビット）、特定の公開鍵が一致することを確認するのに十分です。その設定では、サーバーには公開鍵のリポジトリがあり、アリスとボブは指紋を再計算するだけで、サーバーが偽のゲームをプレイしていないことを確認します。
直接アルコール摂取の必要性を軽減するより高度な解決策は、証明書を使用することです。証明書は、 ID（「Bob」などの名前など）と公開鍵を含むボックスです。ボックスは認証局（CA）によって署名されています。CAは、署名を適用することにより、公開鍵が実際にボブに属していると主張します。アリスがCA公開鍵を知っている場合、彼女は証明書の署名を検証し、公開鍵と証明書に含まれるIDとの間のリンクの信頼を得ることができます。
認証は信頼の委任です。アリスは彼女の信頼をCAに委任します。おそらく、CA（チャーリーと呼びましょう）はボブに会うためにバーに行きました。証明書を通して、チャーリーはアリスにこう言います：「ええ、それは本当にボブの鍵です、彼は彼の3パイントの後にそれを私に見せました」。信頼を委任することは容易ではないため、ここでは物事が少し曖昧になります（特に、チャーリーが暴飲の習慣がある場合）。CAが別のCAの証明書に署名すると、委任はさらに進む可能性があります。ここで、チャーリーはアリスに次のように語っています。「ボブに会ったことはありませんが、ボブに会い、CAとして行動した可能性のあるダフネに会いました」。アリスは、チャーリーからダフネに発行された証明書とダフネからボブに発行された証明書の両方を使用して、署名のチェーンを検証できます。
ここで注意が必要なのは、アリスはチャーリーを知っていて、ギネスのガロンの影響下であっても、ボブに会ったときにボブを正しく識別する能力を信頼しているかもしれませんが、アリスはダフネを知らないということです。アリス-チャーリー-ダフネ-ボブチェーンでは、アリスはチャーリーが信頼できる（ダフネを正しく識別した）だけでなく、チャーリーがだまされていないこと、つまり、ダフネがダフネの証明書に署名することを拒否したことを信頼する必要があります自分自身は信頼できません。実際の状況では、信頼は委任されると急速に低下します。
証明書を使用する場合、主に2つの可能な構造があります。
階層型CA：構造によって誰もが知っている単一または少数の「ルートCA」があります。CAは、法を確立する契約上の合意の範囲内でのみ、別のCAに委任します（つまり、IDで、「この公開鍵は証明書の署名を検証する目的で信頼される可能性があります」という従来のフラグを使用して証明書に署名します）。認証に関する両方のCAの責任。これは、委任が正式に定義されていることを意味し、それは簡単ではないことが起こります。通常「CertificationPolicyStatement」（CPS）と呼ばれる弁護士と互換性のある認証契約は、200ページの長さの文書です。
Web of Trust：誰もがCAとして機能します。「正式な信頼性」がない場合、個々のチェーンはごくわずかな信頼しか得られません。これは、膨大な数によって補われることを意図しています。アリスは、ボブにつながるいくつかの（多くの）別個のチェーンを検証でき、別個の参加者を経由する場合にのみ、ボブのキーを受け入れます。たとえば、アリスはチャーリー-ダフネ-ボブチェーンだけでなく、エリヤ-フィオナ-ボブとジェラルド-ヒラリー-イワン-ボブチェーンも必要とします。それらはすべて酔っぱらいですが、アリスが使用する各チェーンの1人の参加者を破壊するために、偽のボブが多くのラウンドを支払う必要があるという点で、集合的に信頼できる可能性があります（アリスが個別の証明書を持つn個のチェーンを必要とする場合、攻撃者は少なくともnを破損する必要があります参加者）。
したがって、認証ビジネスは主に手続きの問題です。CAとは誰か、証明書を発行（署名）する前にCAが何を検証するか、法的な観点から全体がどのように立っているかなどです。これらの手順は本質的に複雑であり、証明書形式の詳細（「この公開鍵はCA鍵です」というフラグなど）によってサポートされる必要があります。現在定義されている2つの主要な標準形式は、X.509とPGPです。。X.509は、階層型CAを多くサポートしており、標準、形式、慣行、および委員会の非常に複雑な混乱です。PGP（「OpenPGP」という名前で標準化されている）は、階層型CAを実際にはサポートしていません。WebofTrustで使用することを目的としています。OpenPGPはX.509よりも単純ですが、特に証明書の背後に強力な法的意味を持たせたい場合は、より制限されます。
IMサーバーの場合、これはすべてやり過ぎになる可能性があります。アリスが本当に望んでいるアイデンティティの概念は、おそらく繰り返しの概念です。「ボブは、昨日チャットしたボブと同じボブです」。アリスはボブを事前に知りませんが、彼と話すことでアリスの目に彼のアイデンティティが確立されます。彼女は他のボブにだまされたくないだけです。そのためには、「アリスのソフトウェアが新しいおしゃべりの発表された公開鍵を保存し、後でそれを使用する」などの簡単なプロセスでうまくいきます。重要な問題は、自分が求めているアイデンティティの概念を適切に定義することであることを忘れないでください。
サーバーを制御しない限り、できません。もちろん、ボブの公開鍵をすでに知っている場合を除きますが....ここで鶏が先か卵が先かという問題に直面していると思います。