PKIへの別のアプローチ
まだ 公開鍵インフラストラクチャの障害の後、私は全体がどれほど壊れているかを考えていました。アイデンティティと公開鍵を確実に関連付けるこのビジネスと、それを達成するために私たちが行ったすべての作業は、坂を登るように感じ始めています。私を許して、私はほとんどここで声を出して考えているだけです。
ToR Hidden Service Protocol と、これを解決する方法について考え始めました。 「hidden service name」（他のURLと同様にアドレスバーに入力されます）は実際には公開鍵から派生しているため、kpvz7ki2v5agwt35.onionなどのサイトにアクセスすることになりますが、証明書やPKIが必要ない場合、公開鍵とドメインだけで、それらが一緒に属していることを証明するのに十分な情報になります（衝突を生成できるようになるまでですが、それは別の話です）。さて、これには明らかに問題があります。DNSの要点は、人間が読めるIPアドレスへのマッピングを提供することです。
それが私の最終的な、おそらく欠陥のある提案につながります。公開鍵から生成されたIPアドレスを使用しないのはなぜですか？ （逆の方法は、最初はより便利に聞こえますが、明らかな暗号化の理由で機能しません）。
IPv6の巨大なアドレス空間があります。 1024ビットのRSAキーペアは、最大で約80ビットのエントロピーを持つと考えられています。それでは、80ビットのセグメントを分割して、RSA公開鍵をこのセグメントのIPアドレスにマッピングしてみませんか？
私の頭の上からいくつかの欠点があります。
- そのため、攻撃者はキーペアを生成し、そのようなサーバーが存在する場合、そのキーペアがどのサーバーで使用されるかを即座に知ることができます。おそらく、80ビットスペースを拡張して、最大エントロピーが約256ビットであると考えられる4096ビットのRSAキーを使用するように拡張し、そのような検索を実行不可能にすることができます（ただし、残念ながら、これに適合するには、512ビット程度のIPv7 +が必要です）。この攻撃も対象外なので、最初の音のようにas悪いわけではありません。この攻撃は、key-> IPプロセスにソルトを含めることで軽減できます。これは、サーバーがクライアントに接続するときにクライアントに送信します。このソルトは、各サーバーのキー-> IPプロセスを一意にします。
- 攻撃者は、選択したIPと一致するまで、既知のソルトを使用してキースペースをブルートフォースで攻撃する可能性があります。これは標的型攻撃であるため、少し怖いです。ただし、slow（1-3秒）アルゴリズムを使用して公開鍵からIPへのマッピングを行うと、これを軽減できます。ソルトの使用は、そのようなブルートフォースが単一のIPにのみ適用され、ターゲットIPごとに繰り返される必要があることも意味します。
これを閉じるモッドを停止するために試行するために、私はそれを質問に変えるために最善を尽くします。このアイデアは何らかの形で完全に欠陥がありますか？過去に試みたことはありますか？私はただとりとめていますか？
公開鍵をIPアドレスにマッピングするのは簡単で（ハッシュして最初の80ビットを維持するだけ）、これを何らかの方法で堅牢にする方法（つまり、変換を遅くする方法）をリストしました ）。 問題をまったく解決しないという欠点があります：移動するだけです。
問題は、暗号で保護されたアクセス（つまり、サーバーの公開鍵）を、人間のユーザーが理解するアイデンティティの概念にバインドすることです。人間のユーザーはドメイン名を把握します。ハッシュで生成されたIPv6アドレスを検証しないでください...
もちろん、そこにはnamesをIPアドレスなどの技術データにマップする展開済みシステムがあります。これは [〜＃〜] dns [〜＃〜] です。これを拡張して、ドメイン名を公開鍵検証トークンにマッピングする（つまり、公開鍵のハッシュをDNSのどこかに配置する）か、公開鍵自体にマッピングすることもできます。 DNSを使用してセキュリティの影響を受ける名前とキーのバインディングを転送する場合、DNSは貴重なターゲットになるため、DNS自体にセキュリティを追加する必要があります。その時点で、あなたは [〜＃〜] dnssec [〜＃〜] を持っています、これはがX-509の置き換えの現在の提案です HTTPS WebサイトのPKI。 DNSSECが既存のCAよりもうまく機能するかどうかは不明です。それは俳優を切り替えることですが、概念的な認証ビジネスはまだここに潜んでいます。
人間は人間が判読できる名前を望んでおり、公開鍵は判読できません。すべての証明書ベースのソリューション（X.509またはDNSSECなど）は、公開鍵を任意に選択した名前にバインドしようとします。別の明確な方法は、公開鍵を読み取り可能にすることです。奇妙なことに、そのための暗号化プロトコルがあります。 IDベースの暗号化 。彼らはいくつかのかなり曲がりくねった数学ツール（楕円曲線のペアリング）を使用します。彼らはコアコンセプトを変更しません（実際には、ある時点で、誰かが「Google」などの社会的アイデンティティとコンピューターの世界との間のリンクを作成する必要があります）が、ダイナミクス。 SSLのIDベースのシステムでは、各サーバーは有効期間が非常に短い秘密鍵を持ち、中央機関は名前に一致する新しい秘密鍵を各サーバーに毎日発行します。正味の効果は、X.509 PKIのようなもので、取り消しは本質的にうまく機能するため、損傷の封じ込めは効果的です。
さらに別のひねりは、アイデンティティの概念を置き換えることです。人間は公開鍵を読むことができないので、それを受け入れてください。代わりに、doがキーの読み取り方法を知っている専門のエンティティによるアクティブな攻撃を追跡します。それが Convergence の「公証人」の要点です。公証人は、どのサイトでどの公開鍵が使用されているかを追跡し、何か怪しいものを見るたびに悲鳴を上げたり蹴ったりします。
とにかく、現在のシステムは壊れていない壊れています-経済的に適切な方法ではありません。あなたがリンクしている違反は、ComodoとDigiNotarの事故に加わります。これは短いリストです。このような問題は、金融レーダーにもほとんど表示されない方法で発生します。「信頼されたCA」から取得した偽のサーバー証明書を使用したすべての詐欺のコストを合計すると、次の点に関して非常に少ない金額になります。ありふれたクレジットカード詐欺による数十億ドル。銀行、マーチャント、およびインターネットで商取引を行う人々の観点から、X.509 PKIは機能します。交換を促進するインセンティブはありません。偽のGoogle証明書が毎日あり、実際に人々からお金を盗む場合、状況は異なります。現在、年に1回開催しています。
あなたのアイデアの最初の大きな欠点は、それが実際にはあまり解決しないことです。現在使用されているような意味のある名前が必要になったら、DNSまたは同様のシステムが必要です。ですから、今やDNSであってCAではないことを除いて、失敗のポイントが戻ってきました。
フィンガープリントをIPに入れることは、IPと一緒にDNSに入れることに比べて利点がほとんどありませんが、ルーティングがより複雑で高価になるという欠点があります。
キーフィンガープリントをDNSSECに入れるシステムがあり、それは [〜＃〜] dane [〜＃〜] と呼ばれます。 Chrome最近 追加されたサポート そのため。
cjdns と呼ばれるシステムがあり、指紋をIPに書き込みます。 120ビットのIPと強化構造の8ビットを使用して、128ビットのフィンガープリントと同等のものを取得します。マルチターゲット攻撃のため、実際のセキュリティレベルは指紋のサイズよりも低いことに注意してください。
また、PKI障害のレベルを過大評価しています。強力な敵は時折それを破りますが、通常の犯罪者は通常は破りません。 Certificate Transparency のようなシステムを展開すると、このような障害が迅速に検出されるため、攻撃者は貴重な証明書をより速く焼きます。
すべての名前解決システムは Zookoの三角形 にぶつかります。グローバルで意味のある名前が必要な場合は、何らかの信頼できる中央レジストリが必要になります。
Namecoin zookoの三角形を壊すのに最も近いですが、問題のシェアもあります。 IMOの最大の1つは、商標を執行できないため、google.bitはおそらく有名な会社ではないでしょう。
また、このトピックについて Zookoのエッセイ もお読みください。
より大きな鍵は、PKIの信頼されたルートCAが取り消される方法を改善することだと思います。ルートCAのマスター失効リストがあった場合、危険にさらされる可能性は低くなり、侵害されたルートCAが1つだけ問題になり、フォートノックスのように保護される可能性があります。それが侵害された場合は、修正するパッチの現在の手段を適用できます。
SSL資格情報をDNSレコードに関連付けることもできます。特定のTLDは、それがIDであると言うために有効なSSL証明書を解決できる必要があります。これにより、DNSが偽装され、ルートCAが侵害され、両方とも検出されずに失効がトリガーされる必要があります。たとえば、ルートCAが危険にさらされ、私がGoogle.comであると証明書を作成した場合、google.comのDNSレコードをチェックするだけで、証明書が一致せず、本物ではない可能性があります。事実上、サードパーティを独占的に信頼するのではなく、サードパーティとファーストパーティの両方が2つの異なるチャネルに同意することを要求します。
それでもMITMに侵害されたルートCAとDNSの結果を変更する機能の両方がある状況には役立ちませんが、侵害されたCAの潜在的な有用な攻撃シナリオを大幅に制限します。 （現在、ほとんどのユーザーにwww.gaggle.comは、Googleウォレットでログインする必要がある新しいGoogleサービスであると思わせることができます。