誰かの公開鍵を偽装する可能性
公開鍵暗号の仕組みは知っています。 （非常に）簡略化：
アリスはボブの公開鍵を受け取り、その鍵で暗号化されたメッセージを送信し、それをボブに送信します。
ボブとボブだけがメッセージを復号化できます。これは、同意する秘密鍵を所有しているのはボブだけだからです。
シナリオ（これも簡略化）：
どういうわけか、アリスのデバイスに感染し、ボブの「保存された」公開鍵を自分の公開鍵に置き換えます。彼女が私の公開鍵でメッセージを暗号化して送信した後、私はメッセージを傍受し、秘密鍵でメッセージを復号化できるようになりました。その後、中間者として行動することができました。
編集：どういうわけか私たちは公開鍵を変更することしかできず、平文でメッセージを読むことができないと想定しています。
私の質問は：
- アリスはどのようにしてボブの公開鍵を知っていますか？
- 誰か（またはデバイス自体）をだまして、メッセージをボブに送信しているように思わせることはできますか？
- この問題はどのように回避されますか？
アリスはどのようにしてボブの公開鍵を知っていますか？
AliceがBobの公開鍵を検証する方法はいくつかあり、それぞれに長所と短所があります。
直接、直接
これはおそらく最も安全な方法です。アリスとボブは直接会って、交換し、場合によってはお互いに公開鍵に署名します。これは、誰もがこのプロセスを改ざんすることを事実上不可能にします。
欠点はすぐに明らかになるはずです。このアプローチは、定期的に直接会うことのない人には実行可能ではありません。世界中の人々は、鍵を交換するためだけに、お互いに会うことができるようにかなりの金額を投資する必要があります。
ボブのサーバー経由
Bobには適切なTLSで保護されたWebサーバーがあり、公開鍵をダウンロードとして提供しています。これはボブと直接会うよりもはるかに便利ですが、妥協のリスクもあります。
イブがボブのサーバーにアクセスして自分のキーペアを生成できた場合、彼女はボブの公開キーを自分のキーに置き換えることができます。これは、人々がボブにメッセージを送信しようとしたときに明らかになり、ボブはそれらを復号化できなくなるでしょうが、現時点ではすでに遅すぎた可能性があります。
キーサーバー経由
ボブは自分でキーをホストする代わりに、自分のキーをキーサーバーにアップロードし、それにリンクするだけです。これは以前のアプローチと非常に似ていますが、リスクをボブからキーサーバーを制御する人に移行します。
さらに、攻撃者はボブの名前で偽の公開鍵（「Evil Bob」）を作成し、さらにボブの友人のために偽の公開鍵を作成して、「Evil Bob」に関する偽の信頼の網を作成する可能性があります。
「ダイレクトメッセージング」経由
素朴なアプローチは、Twitter、WhatsApp、または類似のプラットフォームでボブにメッセージを送り、彼に公開鍵を要求することです。ここでの問題は、それが本当に彼であるかどうかを実際に確認できないことです。攻撃者が自分のアカウントにアクセスし、「Evil Bob」の偽の公開鍵を配布した可能性があります。
VoIPシステムは優れているかもしれませんが、人々が考えるほど完璧ではありません。
誰かがだまされて、偽の公開鍵を使用する可能性はありますか？
はい、上記のとおりです。 Bobが直接および個人的にキーを提供しないシナリオはすべて侵害される可能性があります。
ただし、保護があります。人々はボブの鍵に署名できるので、ボブを保証することができます。これらの接続が密に織り込まれているほど、鍵を偽造することが難しくなります。それにもかかわらず、それは可能です。
アリスはどのようにしてイブが自分のデバイスでボブの公開鍵を変更するのを防ぐことができますか？
イブはボブの秘密鍵を変更するためにアリスのデバイスを悪用することができたと想定されています。
このシナリオは難しいですが、不可能ではありません。すべてのキーにはフィンガープリントがあり、実際にはキーを識別する「ロング」と「ショート」の2つのフィンガープリントがあります。アリスが長い指紋を覚えているとしたら、イブが衝突を起こして彼女が制御するキーを挿入することは現実的ではなく、アリスがそれを正当なキーと間違えるのに十分似ています。
彼女が「短い」指紋のみを記憶している場合、それは 技術的に実現可能 になりますが、高価値のキーはおそらくアリスやボブのような平均的な人々の前にターゲティングされます。
信頼の網はこの場合にも役立ちます。偽の信頼の網が生成されたとしても、アリスは署名に自分の秘密鍵を必要とするため、これらの鍵を信頼しません（そして、アリスは自分の秘密を保護しましたイブが知らない強力なランダムパスワードを使用したキー）。
アリスが相手の公開鍵をデータベース、スプレッドシート、テキストドキュメントに保管している場合。その後、あなたのシナリオが機能することは現実的です。
ただし、ほとんどの場合（Aliceを含むと幸いです）、本物であると認定された公開鍵のみを信頼します。これが現在行われている主な方法は2つあります。
中央当局により認定
公開鍵は、このタスクのために特別に設定された組織によって認定されます。これらは、 Certification Authorities （CA）と呼ばれます。
CAは、ボブの公開鍵を認証するように依頼したときに、ボブの資格情報を確認しました。次に、ボブは自分の認定公開鍵（一般に証明書と呼ばれます）をアリスと他の多くの友人/同僚に送信できます。
アリスが信頼できるCAによって認証された公開鍵のみを信頼する場合、シナリオは失敗します。公開鍵は認証されていないため、アリスがそれを信頼しないため、こっそり入れることはできません。
公開鍵でCAにアプローチできますが、CAはそれが自分のものであることを証明するだけであり、Bob（またはAlice、または他の誰か）には証明しません。
このメソッドは、インターネット上のリソース（このサイトなど）のIDをアサートするために使用される証明書に署名する商用CAによって使用されます。組織は独自のCAを運用することもできます。
友人や同僚によって認定されています
上記の方法の代わりに、アリスがボブとすでに対応している友人/同僚に、彼の公開鍵が本物であるかどうかを確認することもできます。彼らは、他の人に確認するか、ボブ自身に確認することによって（多分対面の会議）、これを知っています。このようにして、信頼はクモの巣のように広がり、この概念は web-of-trust と呼ばれます。
この後者の方法は、Pretty Good PrivacyおよびGnu Privacy Guardによって使用されます。
しかし、CAは問題のすべてではなく、すべてではありません。あなたのシナリオでは、アリスのデバイスを危険にさらしています。つまり、別のCA（つまり、あなたのCA）によって認証された公開鍵を信頼するように彼女のデバイスを構成できます。これで、BobとAliceが無意識のうちにそれを信頼するようになりすましている公開鍵を認証できます。
ただし、CAは、質問から少し逸脱し、「ボブ」を人ではなく、インターネットなどの非常に大規模なネットワーク上の新しいリソースであると見なすと、独自のものになります。このような場合、すべての公開鍵を管理するという問題の規模のために、Web-of-Trustモデルは機能しません。
つまり、CAは、質問のAliceとBobのように、1対1の単一の関係で構成されるシナリオではあまりメリットがありません。これは、Aliceが暗黙的にボブの公開鍵を信頼していますか？から追加のCAを信頼するようにデバイスが設定されていないことを信頼していますか？
ただし、インターネットなどの1対多の関係では、CAは使用前にすべての公開鍵を何らかの方法で確認する必要をなくし、デバイスの構成の確認に置き換えます（私たち全員が問題なく実行します！ ）。
もちろん、現実の世界では、アリスのデバイスの侵害に成功した場合、ボブの公開鍵を変更するかどうかは、全体像では重要ではありません。