例えばこれを実行すると:
gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys 0xFBB75451
その後、インポートは安全な方法で行われますか?安全な接続のみを通過するのですか? (HKP?)キーのフェッチでエンドツーエンドの暗号化と適切な認証([〜#〜] mitm [〜#〜]攻撃)が使用されていないため、侵害される可能性がありますか?
更新:だから私は正確にこれを求めています:誰かの公開GPGを取得したい場合、それはMITMで攻撃される可能性がありますか? (攻撃者が「接続」をハイジャックし、keyserver.ubuntu.comが所有するIPになりすまし、偽の公開鍵を提供するようにします。GPGで確認すると、不正なGPGキーサーバーに連絡し、 GPGキーが有効であるように見えます!)
それはあなたの「妥協」の定義に依存します。主な懸念事項はプライバシーです。以下に示すように、パルシモニーとTorがソリューションです。
しかし、最初にデータの整合性を見てみましょう。
「エンドツーエンド」のセキュリティの概念は、データについて考えている実際のアプリケーションをカバーする場合に最も役立ちます。 OpenPGP HTTPキーサーバープロトコル(HKP)によって移動されたオブジェクトは、公開鍵技術に基づく署名でカバーされているため、アプリケーション(gpgなど)自体でチェックできます。署名が有効かどうか、他の鍵や信頼する人に適用されるかどうかなどが確立されます。(更新:したがって、gpgのみ(オプション)はキーサーバーから証明書を取得するため、依存しません。鍵の有効性を確立するための任意の鍵サーバー。)
たとえば、gpgを使用してメールの署名をチェックしているとします。 gpgで指定されたキーが不明であると通知された場合は、キーサーバーから取得します。おそらく、最終的に信頼された鍵からメールに署名した鍵への信頼できるパス( wotsap を利用するなど)がないため、メールは鍵は既知であるが信頼されていないことを通知します( like this / )。したがって、署名を見て、あなたが知っている誰かから信頼されている人のキーを見つけ、そのキーを信頼している人もダウンロードします。あなたが信頼できる道で終わるなら、すべてが素晴らしいです。ダウンロード中にキーをだまされた場合、信頼できるパスを取得できない(キーが壊れているか役に立たないため)、または(これはかなり珍しいことです)、別のパスを取得する可能性があります。あなたのために働かない。しかし、要点は、パスをチェックし、信頼パスの「無形要素」を自分で評価する必要があります(人々をどの程度信頼しているか彼らの理解)署名など)。ただし、常にPGPを使用する必要があります。したがって、署名を作成した人から、署名をチェックするソフトウェア、および構成された信頼ルートまで、完全に保護されているという意味で「エンドツーエンド」であり、非常に理想的です。
トランスポートのセキュリティは特に重要ではありません。TLSと関連するPKIおよび証明書を使用すると、データの整合性を向上させることなく、PGPキーサーバーインフラストラクチャに複雑さ、コスト、および脆弱性を追加します。誰かがトランスポートをいじった場合、彼らはあなたのサービスを拒否したり、フィッシング攻撃のようなことをしたりできますが、とにかくあなたはとにかくそのような種類の問題に対処しなければなりません。
たとえば、件名に関する(期限切れですが、おそらくまだ有用です)インターネットドラフトの「セキュリティに関する考慮事項」セクション: draft-shaw-openpgp-hkp-00-OpenPGP HTTP Keyserver Protocol(HKP)
より重要なデータ整合性の懸念は、gpgクライアントなどのバッファオーバーフローの脆弱性を不正利用できる、注意深く作成された「マルウェア証明書」を与えられるリスクです。私はgpgでそのようなエクスプロイトについて聞いたことがありませんが、SSLで発生しました: yaSSL証明書処理のバッファオーバーフローの脆弱性-CNET 。これについては、 信頼されていない公開鍵サーバーへの接続に固有のリスクは何ですか?
更新:より問題の多い懸念は、プライバシーです。検索しているキーを他の人に見られたくない場合や、キー転送に手を加えたくない場合は、TLSを使用することもできます。しかし、それはあなたが何に興味があるかを知っているサーバーからあなたを保護しません。
@ teris-rielはプライバシーの懸念を拡大します:誰かがあなたに署名して暗号化したメールを送信すると想像してください。メールクライアントが署名のキーを取得します。エヴァンは交通を見守っていて、鍵が通り過ぎるのを見ています。これで彼は、1)送信したキーで暗号化されたメッセージを読むことができること、2)特定のメッセージを読んだこと、3)おおよその時間を知っていることを知っています。この種の確認攻撃が心配な場合は、hkpsとTorを使用してキーを取得し、自動的には行わないでください。 parcimonie は、この問題を解決するために機能するツールです。
そして、 bash のparcimonie実装として:gpg --refresh-keysは、使用しているキーサーバーへのPGPキーの全リストを開示します。 HKP(ほとんどのセットアップのデフォルト)などの暗号化されていないプロトコルを使用している場合、接続を盗聴している人。それは悪いことです。
したがって、パルシモニーのようなものを使用します。
いくつかの代替プロトコルがありますが、必要なキーを含むそれらのサーバーを見つけるのは難しいようです。
こちらもご覧ください
キーサーバーも信頼すべきではないため、キーサーバーへの安全な接続を使用しても意味がありません。
OpenPGP (GnuPGが実装するプロトコル)では、公開鍵が信頼できる誰かがその公開鍵に署名することにより、その公開鍵を信頼します。これは再帰的であるため、アイデアは、あなたが絶対に知っているキー(基本的に、あなたのキー、または物理的に会った、その機会にあなたの公開キーを提供した人のキー)から、それぞれが次に署名するキーのチェーンを取得することです)使用するキーに。これは一種の 公開鍵インフラストラクチャWeb of Trust として知られています。 「他の人が署名した公開鍵」は実際には「証明書」です。署名を検証できる証明書のみを使用するため、証明書の取得方法はセキュリティに影響を与えません。したがって、特に信頼できるとは考えられていない公開サーバーに保存し、保護なしでクリアテキストで送信できます。
WoTでの実際のセキュリティは、いくつかの(多くの)検証パスを見つけることによって実現されます。単一のパスでは十分ではありません。これは、キー[〜#〜] k [〜#〜]がボブに属していることを確認しても、必ずしもキーK 'ボブによって署名されたものは、ボブがそれを信じると信じている人のものです。 X.509 用語(別のPKI標準)では、WoTは「誰もが認証局です」のようなものです。ボブは騙されやすい、または3パイント後に他のキーに無謀に署名する傾向があるため、これはうまく機能しません。これは、定義された証明書パスのセットを要求することで軽減されます。つまり、使用したいキーは、偽のキー(つまり、間違ったIDを持つが他の人によって署名されているキー)を作成するという前提で、多くの異なるボブによって署名されています。攻撃者に多大な労力(またはビール)を要求します。
全体として、PGPワールドワイドWoTはうまく機能しません。うまく機能しているのは、安全でない媒体(キーサーバー、簡単な電子メールなど)を介してキーを交換し、次にキーホルダーに電話をかけて「フィンガープリント」(キーのハッシュ)を交換することです。名刺に公開鍵の指紋を含める人もいます。基本的に、ボブを経由しない直接認証。これがほとんどの場合OpenPGPが使用される方法であり、それで問題ありません。
ほとんどの人は、実際にPGP証明書について話すとき、PGPキーについて話すようです。 ( PGP 6.5.1ドキュメントのドキュメントの暗号化入門の第1章 表現は「PGPキー」ではなく「PGP証明書」を使用します。)
X.509証明書と同様に、PGP証明書のセキュリティ値は署名にあり、消費者が知っている信頼できるエンティティに署名者をバインドすることができます。 X.509証明書とPGP証明書の主な違いは、X.509証明書は1つの署名と発行者しか持つことができない(したがって、階層の一部である)のに対し、PGP証明書は追加の署名で定期的に更新でき、パブリック間のバインディングをアサートします。キーとアイデンティティ。 (私の知る限り、PGP証明書は常に少なくとも自己署名されており、多くのことを保証するものではありません。 編集、@ nealmcbに感謝)
安全なトランスポートメカニズムを介して証明書を取得しても、それほど多くは追加されません(@nealmcbが言ったように)。重要なのは、その署名を使用して、おそらく中間体を介して、知っている信頼できる署名者にチェーンバックできるようにすることです。もちろん、X.509の場合と同様に、トップに立つには「信念の飛躍」(または「指示された」企業の信頼)が必要です。
keyserver.ubuntu.com
はTLS経由でキーを提供していました(X.509証明書を前提としています)。探しているPGP証明書がサーバーとユーザーの間で侵害されていないことは確かです(証明書の発行元CAを信頼している場合)。 )。ただし、これが原因で鍵を信頼すると、2つのモデルが混在することになります。これは、鍵サーバーがPGP証明書をホストしているためではなく、その内容をどのように信頼すべきかについての表明を行うものではありません。鍵サーバーは証明書の単なるリポジトリです。
ここでの危険は、リモートロケーションのなりすましの形で発生します。これは、HTTPSに切り替えることで解決されないDNS経由で発生する可能性が最も高いです。
ここでの最良のオプションは、定期的にダウンロードすることですが、キーが正しいことを受信者に手動で確認することです。
これらは長い回答なので、簡単に説明します。安全な接続には2つの利点があります。
まれに(場合によっては)、公開された場合に機密と見なされる公開暗号鍵を取得することはほとんどありません。アリスとボブがキーを交換したことを知るだけでイブがあまりにも多くを知るようになると問題になるかもしれませんが、すべての基本的なインテントでは、サードパーティから何も隠す必要がないので、それを暗号化します。
ダウンロードする公開鍵は、安全を確保するためにすでに交換されている暗号化フィンガープリントによって検証されます。認証はキーに組み込まれているので(すでに指紋を知っている限り)、それを超える追加の認証レイヤーは不要になります。
したがって、プレーンテキストで送信された場合でも、GPGキーは安全です。 SSL、プライベートクーリエ、または壁の側面にスプレーで送られるかどうかにかかわらず、認証はキーに不可欠であり、その公開はほとんどリスクを伴いません。