信頼できる暗号化は、現代のインターネットの基盤です。 暗号化がなければ、安全な接続は存在せず、インターネット上で信頼できるトランザクションを行う可能性は失われます。 安全な接続を確立していないと、対談者でさえ信頼できません。
Googleによると 、現在の公開暗号化インフラストラクチャには重大な欠陥があります。 実際のところ、サーバーがキーで侵害された場合、ユーザーは対話者でキーを手動で 確認する必要が あります。 これは非常に不便であり、実際には機能しません。 このような困難のために、一部の暗号愛好家はPGPを完全に放棄し 、簡単に理解できます。
Googleは解決策を考え出しました。公開キーを検索するための透過的なメカニズムであるKey Transparencyを誰でも使用できるようにします。
問題は何ですか？
問題は、電子メール暗号化用のPGP信頼ネットワークが20年以上前に作成され、多くのユーザーがそれを使用できない、または使用したくないということです。
この問題は、暗号の専門家Filippo Valsordaの記事「 私はPGPを拒否しました 」でよく説明されていました。
公開キーの検証に信頼ネットワークを使用したことはありません。 そして、覚えておいて、私はうまく接続されたキーを持っています。 正式な調査は行いませんでしたが、PGPを使用して私に連絡したすべての人が、次のいずれかを実行した、または実行できました（質問された場合）
- 最も可能性の高いキーをキーサーバーから引き出しました。
- 「これは私の新しいキーです」という言葉で彼に答えた場合、別のキーを使用します。
- 「旅行中です」などの言い訳で彼に尋ねると、手紙は平文で送られます。
乗車や旅行は長期キーに対して特に敵対的であり、 この種の新たなスタートは不可能です。
さらに、長期的なキーが意味をなす攻撃者がいるかどうかさえわかりません。 平均的な平均的な敵は、おそらくTwitterのプライベートメッセージに対してMitM攻撃を行うことはできません（つまり、プライバシーを維持しながら、プライベートメッセージを使用して公開キーの指紋を交換することができます）。 Mossadは 、どのキーを使用しても、車でMossadを実行します。
最後に、最近では、破ることのできない信頼よりも、直接の秘密、拒否の可能性、およびエフェメリティに関心があります。 長期キーを永久に保護できると確信していますか？ 攻撃者があなたを標的にして成功させると、これからあなたのすべてのメッセージだけでなく、過去のすべてのメッセージにもアクセスできるからです。
きっと多くの人がこの意見に同意するでしょう。
PGPの作成者自身がPGPを使用していない場合、何を言えますか。
メッセンジャー 、ファイル共有プログラム、およびソフトウェア更新配信システムにも同じキー交換の問題があります。
Googleのセキュリティおよびプライバシーエンジニアリング部門の従業員であるRyan HurstとGary Belvinは、開発されたKey Transparencyシステムのタスクの1つはシステムを簡単にすることであると公式ブログに書いています。 専門家でなくても暗号化ツールを確実に使用できるインフラストラクチャを作成します。
その考えは、その人のオンライン識別子と彼の公開鍵との関係が自動的に検証され、一般に公開されるべきだということです。 ユーザーは、特定のアカウントに関連付けられているすべてのキーを確認する必要があります。また、第三者（ハッカーまたは政府機関）による情報の代用の試みはすぐに表示されるはずです。 このようなインフラストラクチャにより、送信者は、検証されてアカウントに関連付けられている受信者と同じ公開鍵を常に使用して、メッセージを暗号化することが保証されます。
主要な透明性
「鍵の透明性は、開発者が独自に検証されたアカウントデータを使用して、あらゆる種類のシステムを簡単に作成できる、透明で公開されたディレクトリです」と、Ryan HurstとGeri Belvinは書きます。 -データを暗号化または認証する必要があるさまざまなシナリオで使用できます。 ユーザーフレンドリーなセキュリティ機能を開発すると同時に、アカウントの回復などの重要なユーザーニーズをサポートするために使用できます。
著者によると、鍵の透明性を開発する際に、 証明書の透明性とCONIKSのプロパティを組み合わせました。
Google Certificate Transparencyは、SSL証明書をほぼリアルタイムで監視および監査するためのオープンフレームワークです。 認証局が誤ってまたは意図的に新しいSSL証明書を発行した場合、それらは証明書の透明性システムによってすぐに検出されます。 システムは、証明機関が偽の証明書を発行するかどうかも判断します。
一方、CONIKSはエンドツーエンドのキー管理システムであるため、プロバイダーまたはサーバーに信頼がなくても、エンドツーエンドの安全な暗号化チャネルを維持できます。 つまり、CONIKSはユーザーの暗号化キーを検証に使用できるように保存し、キーの置換は即座に記録されます。
Googleの主要な透明性は、証明書の透明性とCONIKSのプロパティを組み合わせたものです。 または、これは証明書の透明性をモデルにした、GoogleのCONIKSの独自バージョンであると言えます。
Key Transparencyのプロパティについては、 このページで詳しく説明します 。 原則を一言で説明すると、同じアカウントに対して同じ公開鍵を同時に要求したときに2人が同じ結果を得るはずです。 つまり、この場合、ユーザーの1人（中間者）に対してこのアカウントを置き換えるサードパーティの介入はありません。
Googleは、ユーザーアカウントとその公開鍵を使用してデータベース全体の単一のハッシュを計算するマークルツリーを作成することにより、この種の自動検証をキー透明性システムに実装し、結果のハッシュをユーザー間で配布します。
ハッシュ構造は、ハッシュに含まれる情報を効果的に使用するように設計されています。 アプリケーションは、特定の結果がハッシュの一部であることをすばやく確認できます。 これを次の図に示します。
マークル木ハッシュは、シートAがハッシュKの一部であることを証明します。検証は、シートAをハッシュし、結果のハッシュEを中間ノードFおよびJと組み合わせてKを計算することにより行われます。
図に示されているように、すべてが非常に簡単に、そして効果的に機能します。 マークルツリーには各ユーザーのシートがあります。ノードには0〜2 256 -1の番号が付けられています。
したがって、ユーザーがキー透過性システムを使用してメッセージを送信する前に受信者の身元を確認すると、受信者の公開キーがアカウントに対応していることを確認できます。
Googleは、アプリケーション開発者が新しいキーを自動的に検出するために次のようなものを実装することを推奨しています。
データベースを更新するために、システムに数秒ごとに新しいマークルツリーが構築され、新しいハッシュが計算されます。
Key Transparencyでのデータスプーフィングを除外するために、Merkleツリーのすべての古い画像は、Certificate Transparencyの通常のMerkleツリーと同じ構造で新しいMerkleツリーを補充します。 ツリーは左から右に埋められているため、その構造には、各新しいバージョンが前のバージョンの変更された状態であるという証拠が含まれています。
Githubリポジトリには、Key Transparency Clientをインストールして使用し、Key Transparencyクラスターを起動するための手順が公開されています。