収束-証明機関システムの置き換えの可能性

すべての人に良い一日を！

このノートの編集に基づいて、資料への2つのリンクをすぐに提供したいと思います。 ソースを直接知り、トピックを読むことはできません。これは私の無料翻訳であり、少量のギャグで主要なポイントを読み直します。
BlackHat USA 2011：SSLと未来の真正性
Moxie Marlinspike ::ブログ-SSL and The Future of Authenticity

入門

数日前、SSL / TLS証明書の取得に関する記事がありました。 しかし、私のコメントは、それに対するコメント、この主題分野の議論そのもの、あるいはむしろその不在によってではなく、記事自体によってではありませんでした。 私はその場で議論を開始せず、問題を解決するためのオプションと一緒に問題を強調し、コメントで全体を議論することができる別のトピックを持つことが理にかなっていると判断しました。

上記の記事からのコメントをいくつか引用しましょう。

証明書は航空取引の優れた例です。 そして、かなり現実的なお金のために、何も保証せず、何に対しても保護しないバイトのセットを取得します....（c）angry_elf

それに対する答え：

MiM保護オプションを提供します！ その後、あなたは空中で取引するか、何もする必要がないほど豊かで人気があります。 （c）okazymyrov。

また、多くのコメントがありますが、これらのコメントから、次のトピック、問題、質問についてはまだ人々が気にしていることが明らかです。

• 証明書取引-航空取引？ 何のためにお金を払うのですか？
• 認証局（CA）は、割り当てられた責任に対応しており、実際の保護を提供すると想定できますか、またはこれに疑問を呈することができますか？
• 陰湿な中間者から身を守るために、ジャンボのアリスとボブに何をすべきか？

これらは、表面的に、より深く、より多くの質問にすぎません。 見てみましょう。

理論のビット

インターネット上のノード間でのデータの安全な送信は、HTTPSプロトコル（HTTPプロトコル拡張）を介して行われ、送信されたデータはSSL / TLS暗号化プロトコル（TLSはSSL 3.0に基づいて開発された標準）にカプセル化され、非対称アルゴリズムの使用に基づいています公開鍵暗号化-RSA。 非対称暗号化の一般的な問題は、公開キーの信頼性を検証することが難しいことです。 したがって、公開鍵アルゴリズムに基づくすべての暗号化プロトコルでは、信頼の問題が根本的に重要です。 つまり、サーバーから受信した公開キーが、すべてのHTTPSをラップする中間者ネットワークセグメントにあるキーではなく、実際にサーバーが安全な通信チャネルを確立するために使用するキーであることを確認する方法sslsniffへのトラフィック。 信頼の問題があります。

認証局

歴史的に、彼らはPKI（Public Key Infrastructure）などの認証技術を使用して信頼の問題を解決し始めました。 これは、CAを介して公開キーをユーザーのIDに接続する包括的な測定システムです。 PKIは、公開キー暗号化システムといくつかの基本原則の使用に基づいています。

1. 秘密鍵はその所有者のみが知っています。
2. CAは公開鍵証明書を作成し、それによってこの鍵を認証します。
3. 誰もお互いを信頼していませんが、誰もがCAを信頼しています。
4. CAは、対応する秘密キーを所有する特定の人物に対して、公開キーの所有権を確認または反論します。

実際、PKIはCAを主要コンポーネントとするシステムであり、ユーザーはCAを介して相互に対話します。
これは次のように機能します。ボブは、アリスと他の友人が彼と安全な接続を確立できるようにしたいと考えています。 彼は、公開鍵と他のデータ（名前、住所など-証明書に含まれるすべて）とともにCAに来て、何らかの方法で身元を確認し（多くの場合、単に電子メールでこれを行います）キー。 CAは彼に証明書を発行します。 次に、Bobはそれを友人に渡します。友人は、完全に信頼しているCAのデジタル署名をチェックすることで、Bobに本当に属していることを確認できます。

問題

問題は何ですか？ 問題は、彼らがあなたを信頼する人をあなたのために決めることです。 リソースの所有者が、たとえばComodoから証明書を受け取ることを決定したその瞬間に-あなたが信頼しなければならない人をあなたのために決定します。 誰かが彼のリソースは彼のためであり、証明書を受け取る相手は彼次第だと言うかもしれません。 はい、ただしデータは（たとえばクレジットカードデータ）このリソースはあなたのものです！ そして、これ、彼女の母親は問題です！ 認証センターの既存のシステムの信頼性に誰も疑問を呈せず、彼らが完璧に作業を行うなら、すべてがうまくいくでしょうが、そうではありません。 UTは民間企業です。彼らは、あなた自身の利己的な利益を追求し、賄bri、脅迫、脅迫を受けることができるあなたに知られていない生きている人々を雇います。 CAは部外者（別名ハッカー）によって侵害される可能性があります。 今年の春（ link ）に発生したComodo CAの騒々しい話を思い出すことができます。その間、サイバー犯罪者によって清算され 、 先日 DigiNotar CA（ link1 、 link2 ）で事件が清算されました 。 DigiNotarで、彼らはどういうわけか問題を解決しました-ブラウザのルート証明書のリストから地獄にそれらをカットし、それは終わりました（ 誤発行の範囲が明確でないため、私たちはFirefoxの新しいバージョンをリリースしています...まもなく取り消すDigiNotarルートを信頼します）。 しかし、ComodoはDigiNotarではなく、より大きな魚です。 コモドはどうなりましたか？ 誰もが不平を言って、不平を言って忘れました。 Comodoがブラウザのルート証明書のリストに載っていたように、証明書を販売しているので、Comodoは同じままです。 静かに眠り、ブラウザの認証局リストに登録されている人を信頼し続けることができます。 そして、これらは報道で取り上げられたケースだけであり、誰にも話されなかったケース、自分自身さえ知らなかったケース、現時点で有効な正式な証明書はいくつありますか？ そして、外部から認証機関を認証する作業を危険にさらす未知の攻撃者の要因を除外したとしても、これらのセンター自体の舞台裏で何が起こっているのでしょうか？ スペシャルの代表者はどうですか。 サービス？ でたらめ妄想？ この記事とit- Law Enforcement Devices UnderSSL SSLのリンクをご覧ください 。 一般的に、小さな問題は、誰が言っても、それらは存在しますが、目が見えない人だけがそれらを目にしません。

解決策

ご存知のように、証明書インフラストラクチャを編成するためのモデルには、集中型（PKI）と分散型（いわゆる信頼ネットワーク-信頼のWebに基づいて実装）の2つがあり、現在PGP / GPGネットワ​​ークで最も広く使用されています。 集中型モデルのすべての利点については上記で説明しました。 単一の認証元が存在しない分散システムについて考えてみましょう。逆に、各ユーザーは、他の公開鍵の認証を信頼する人と信頼しない人を独自に決定し、それによって個人の信頼ネットワークを作成します。 このアプローチは、悪意のある影響に対するシステムの柔軟性と安定性を提供します。分散システムの1つのノードに影響を与えることができます（この場合、信頼ネットワークから除外します）。

中央集中型モデルを修正できます。これに基づいて、リソース自体が特定のCAで証明書を要求することで信頼を開始し、それにより、すべての顧客がこの特定のCAと対話して信頼性を検証し、分散型アプローチを適用することを義務付けます。クライアントが開始し、相互作用は次のとおりです。

1. クライアントは、特定のサイトとの安全な通信チャネルを確立したいと考えています。 彼はこのサイトにアクセスし、彼からSSL証明書を受け取ります。 問題は、これはこのサイトの証明書なのか、中間者をすり抜けた証明書なのか？ 確認する必要があります。
2. クライアントは、自分が作成した証明書サーバーのリストに目を通し、それぞれに「このサイトでどの証明書が表示されますか？」と尋ねます。
3. サーバーリクエストに応答して、指定されたサイトにアクセスし、そこから証明書も受信し、要求元のクライアントに転送して、署名を確認します。
4. クライアントは、サーバーから直接受け取った証明書と証明書サーバーから受け取った証明書を比較します。
5. 証明書が一致する場合-すべてが正常であれば、私たちは働きます。 それらは一致しません。近くのどこかが中間者であり、問​​題が発生する可能性があります。

実装

先月初めにラスベガスで開催されたBlackHat会議で、セキュリティスペシャリストの研究界でよく知られているMoxie Marlinspikeは 、 Convergence （認証機関システムのアジャイル、分散、安全な代替）と呼ばれるプロジェクトを発表しました。 。 プロジェクトの一環として、認証サーバーはNotaryと名付けられました。

FireFoxプラグインをローミングしてインストールします-onvergence ：


公証人リストを作成します。 これを行うには、既存のサーバーのリストを使用できます-Notary list 、Notary-serversを上げることができます-Running -a-Notary 、最初と2番目を行うことができます。



システム設定の機能-検証しきい値オプションを変更することにより、妄想のしきい値を調整できます。


以前は、従来の認証機関システムの使用は次のとおりでした。


プラグインをアクティブにし、Convergenceに移動します。


すてきなこと：

• サイト管理者はサーバー側で何もする必要はありません。 インターネットの新しい認証システムへの移行を手配する必要はありません。 すべてがすでに機能しているため、すべての主要なブラウザにプラグインを実装するだけです。
• クライアントは自分が誰に署名したかを気にしないため、自己署名証明書に関する警告はもうありません。クライアントは、Man-In-The-Middleではなくサーバーによって提供された証明書を使用することを確認することが重要です。

おわりに

誰を信頼する必要がありますか？
...そしてどれくらいの期間？
定められた一連の人々、
または、収束を試す時間ですか？