エンドツーエンド暗号化（E2E）を使用するメッセンジャーでは、ユーザーがキーを管理します。 彼がそれらを失うと、彼は彼のアカウントをリセットすることを余儀なくされます。



アカウントのリセットは危険です。 あなたは公開鍵を消去し、すべての会話で暗号の見知らぬ人になります。 IDを復元する必要があります。ほとんどすべての場合、これは個人的な会議と各連絡先との「セキュリティ番号」の比較を意味します。 MiTMからの唯一の保護であるこのようなテストを実際にどのくらいの頻度で受けますか？



セキュリティ番号を真剣に考えている場合でも、会議で年に一度だけ多くのチャットパートナーが表示されるため、行き詰まっています。

しかし、これはめったに起こりませんよね？

リセットはどのくらいの頻度で発生しますか？ 回答：ほとんどのE2Eチャットアプリケーションでは常に。



これらのメッセンジャーでは、暗号化を落とし、サーバーを信頼し始めるだけです。（1）新しい電話に切り替えるたびに。 （2）人が新しい電話に切り替えるたび。 （3）電話の工場出荷時設定にリセットされたとき。 （4）対話者が工場設定へのリセットを実行したとき。 （5）アプリケーションをアンインストールして再インストールするとき、または（6）話している人がそれをアンインストールして再インストールするとき。 多数の連絡先がある場合、数日ごとにリセットが発生します。



リセットは非常に定期的に行われるため、これらのアプリケーションはこれが問題ではないふりをします。









セキュリティのアップグレードがあるようです！ （しかし、そうではありません）

本当に豆腐ですか？

暗号化では、用語TOFU（「最初の使用に対する信頼」）は、2人の当事者が初めて話すときの偶然のゲームを表します。 調停者は直接会うのではなく、それぞれの側に責任を負います...そして、当事者が自らを提示した後、各側はキーを注意深く監視して、何も変更されていないことを確認します。 キーが変更された場合、両側がアラームを発します。



このような状況でリモートホストのキーがSSHで変更された場合、「正常に動作」することはありませんが、完全に好戦的になります。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@



IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

It is also possible that a host key has just been changed.

The fingerprint for the RSA key sent by the remote host is

00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff

Please contact your system administrator.

Add correct host key in /Users/rmueller/.ssh/known_hosts to get rid of this message.

Offending RSA key in /Users/rmueller/.ssh/known_hosts:12

RSA host key for 8.8.8.8 has changed and you have requested strict checking.

Host key verification failed.

これが正しい動作です。 そして、覚えておいてください。小さな警告を出してさらに作業を進めることができれば、これは豆腐ではありません。 どくろのある巨大な頭蓋骨が見えるはずです。



もちろん、これらのインスタントメッセンジャーは、ユーザーに警告があるため、すべてが正常であると主張します。 必要に応じて、セキュリティ番号を確認できます。 それが私たちが同意しない理由です：

1. 検証は頻繁に行われるため、実行されません。
   
   
2. チェックを吸います。
   
   
3. セキュリティを心配している友人の大まかな調査でさえ、誰もこのテストを心配していないことが示されました。
   
   
4. したがって、これはサーバーに対する信頼とSMSへの信頼にすぎません（まあ！） 何度も何度も 。
   
   
5. 最後に、これらのアプリケーションはこの方法で動作しないはずです。 特にデバイスを変更するとき。 通常の通常のケースはスムーズかつ安全に処理できますが、まれに状況が悪化するほど、見た目が悪くなります。 すぐに、キーベースソリューションを紹介します。

豆腐と呼ぶのをやめる

非常に効果的な攻撃があります。 イブがアリスとボブの既存の会話に侵入し、それらの間に立ちたいと仮定します。 アリスとボブは長年連絡を取り合っており、長い間豆腐を亡くしています。



Eveは、AliceにBobが新しい電話を買ったと思わせるだけです。

ボブ（イブ）：ちょっと、ちょっと！



アリス：ヨ、ボブ！ 新しいセキュリティ番号があるようです。



Bob（Eve）：はい、私はiPhone XSを購入しました。これは良い電話で、とても満足しています。 RWC 2020でセキュリティ番号を交換しましょう。現在のキャロラインの住所はありますか？ サンフランシスコにいる間に彼女を驚かせたいです。



アリス：私は比較できない、Android 4ライフ！ はい、Cozy Street 555。

したがって、ほとんどの暗号化されたメッセンジャーは、TOFUコンプライアンスを獲得する可能性は低いです。 これはTADAに似ています-デバイスを追加した後の信頼。 これは、既存の会話に悪意のある実装の機会を作成するため、架空の問題ではなく、実際の問題です。 本当の豆腐では、誰かがあなたの会話に興味を持つ時までに、彼らはそれに浸透することができません。 TADAを使用すると、これが可能になります。



グループチャットでは、状況はさらに悪化します。 チャットの参加者が多いほど、アカウントが頻繁に再インストールされます。 わずか20人の会社では、これは約2週間に1回発生すると見積もっています。 そして、会社のすべての人がこの人に会わなければなりません。 個人的に。 そうしないと、1人のほくろまたはハッカーによってチャット全体が危険にさらされます。

解決策

秘密鍵サーバーへの信頼を暗示しない良い解決策はありますか？ 私たちは、複数のデバイスに対する真のサポートがあると考えています。 これは、あなたの個性を表す一連のデバイスを管理することを意味します。 新しいデバイス（電話、ラップトップ、デスクトップコンピューター、iPadなど）を受け取ると、独自のキーペアが生成され、以前のデバイスがそれに署名します。 デバイスを紛失した場合、残りのデバイスの1つから「削除」します。 技術的には、そのような削除はリコールであり、この場合、何らかの種類のキーの反転も自動的に発生します。



その結果、 対談者や同僚が新しいデバイスを受け取ったときにサーバーを信頼したり、直接会ったりする必要はありません 。 同様に、デバイスが最後でなかった場合、デバイスを取り外すときにサーバーを信頼したり、直接会ったりする必要はありません。 警告を表示する必要があるのは、誰かがすべての設定に実際にアクセスできなくなったときだけです。 この場合、次のような重大な警告が表示されます。









特にSpecialい



その結果、リセットおよび再インストールされるアカウントははるかに少なくなります。 歴史的に、キーベースでは、デバイスのアドオンとレビューの合計数はアカウントの解約数の10倍です（これについて言葉にする必要はありません。これはマークルツリーで公開されています）。 他のインスタントメッセンジャーとは異なり、最近キーを再インストールした人と話しているときに、本当に恐ろしい警告を表示できます。



デバイス管理は複雑なエンジニアリング操作であり、何度か修正されています。 既存のデバイスは、新しいデバイスの公開鍵に署名し、新しいデバイスの公開鍵のすべての重要な秘密データを暗号化します。 ユーザーの注意範囲について話しているため、この操作は迅速に（1秒以内に）実行する必要があります。 その結果、キーベースはキー階層を使用するため、古いデバイスから32バイトの秘密データを転送する場合、新しいデバイスはすべての長期暗号データ​​を見ることができます（詳細については、以下のFAQを参照してください）。 これは少し驚くかもしれませんが、 それがまさに暗号化のポイントです 。 秘密管理の問題を解決するのではなく、システムのスケーラビリティを高めるだけです。

セキュリティの全体像

これで、キーベースアプリケーションの4つの基本的なセキュリティプロパティを定式化できます。

1. 長期にわたる秘密鍵は、それらが作成されたデバイスから離れることはありません
   
   
2. マルチデバイスの完全サポートにより、アカウントのドロップを最小限に抑えます
   
   
3. キーの取り消しを悪意を持って遅延またはロールバックすることはできません
   
   
4. はかない時間メッセージを使用した直接秘密

最初の2つは理解できるようです。 3番目は、デバイスのリコールが予想され、正常と見なされる設計で重要になります。 システムには、悪意のあるサーバーがデバイスのレビューを遅らせることができないことをチェックする必要があります。



4番目のセキュリティ機能の詳細については、 短命メッセージングに関する記事を参照してください 。

多くの新しい暗号化、すべてが正しく実装されていますか？

Keybaseは、これまでにKeybaseによって実装されたことはなく、科学記事にも記載されていません。 暗号化プロトコルを自分で発明する必要がありました。 幸いなことに、あらゆる状況に対応する、市販の標準化され、広く使用されている暗号化アルゴリズムがたくさんあります。 すべてのクライアントコードは公開されています。 理論的には、誰でも設計または実装エラーを見つけることができます。 しかし、内部構造を実証し、完全な分析のために最高のセキュリティ監査会社を雇いたかったのです。



本日、NCCグループレポートを発表し、その結果に非常に勇気づけられました。 キーベースは監査に10万ドル以上を費やし、NCCグループはトップレベルのセキュリティおよび暗号化の専門家を雇いました。 彼らは私たちの実装で2つの重要なエラーを発見し、すぐに修正しました。 これらのバグは、サーバーが悪意を持って動作した場合にのみ発生する可能性があります。 彼らがそのように振る舞わないことは保証できますが、あなたは私たちを信じる理由はありません。 それがポイントです！



NCCチームは素晴らしい仕事をしたと信じています。 彼らが私たちのアーキテクチャと実装を完全に理解するのに費やした時間を尊重してください。 彼らは最近、コードベースのこの部分を繰り返し見ていますが、開発者の注意を引く微妙なエラーを見つけました。 こちらのレポートをご覧になるか、よくある質問をご覧になることをお勧めします。

よくある質問

XYZ製品をどのように攻撃しますか？

記事から特定の製品への参照を既に削除しました。

他に何？

Keybaseは電話番号を必要とせず、誰かを知っていればTwitter、HackerNews、Reddit、Githubの識別子を暗号で検証できることを誇りに思っています。



そして...まもなく...マストドンのサポートがあります。

電話リダイレクト攻撃はどうですか？

多くのアプリケーションはリダイレクトされた攻撃を受けやすくなっています。 イブはショッピングセンターのキオスクに足を踏み入れ、モバイルオペレーターのボブに、ボブの電話番号をデバイスに転送するように説得します。 または、電話で代表者を説得します。 これで、Eveはメッセンジャーサーバーで認証でき、自分がBobであると主張します。 結果は、アリス、ボブ、イブの例のほうが高いように見えますが、イブはサーバーに侵入する必要はありません。 一部のアプリケーションは、この攻撃から保護するために「登録ブロック」を提供しますが、デフォルトでは迷惑です。

Keybaseがいくつかの秘密鍵をサーバーに送信すると聞きましたか？

初期（2014年から2015年初期）では、KeybaseはPGP Webアプリケーションとして機能し、ユーザーは自分のPGP鍵をパスフレーズで暗号化されたサーバーに保存する機能を選択できました（Keybaseは知りませんでした）。



2015年9月に 、新しいキーベースモデルを導入しました。 PGPキーは、キーベースチャットまたはファイルシステムでは決して使用されません（使用されません）。

古い電話は新しい電話ですぐに表示されますか？

他の一部のアプリケーションでは、サーバーを介して古いメッセージを同期することは直接の秘密に反するため、新しいデバイスでは古いメッセージが表示されません。 キーベースアプリを使用すると、特定のメッセージ、または会話全体を「一時的な」ものとして指定できます。 それらは一定の時間後に破棄され、2回暗号化されます。1回は長寿命のチャット暗号化キーを使用し、もう1回は頻繁に変更される一時キーを使用します。 したがって、一時メッセージは直接の秘密を提供し、電話間で同期することはできません。



非一時的メッセージは、ユーザーが明示的に削除し、E2Eを暗号化のみで新しいSlackスタイルのデバイスと同期するまで残ります！ したがって、誰かをチームに追加するか、自分で新しいデバイスを追加すると、メッセージのブロックは解除されます。



次の段落で同期について詳しく説明します。

PUKについて教えてください！

2年前、 ユーザー向けキー（PUK）を導入しました。 PUKのパブリック半分は、ユーザーのパブリックsigchainでアドバタイズされます。 秘密の半分は、各デバイスの公開鍵用に暗号化されます。 アリスが新しいデバイスを準備しているとき、彼女の古いデバイスは、PUKの秘密の半分と新しいデバイスの公開鍵を知っています。 新しいデバイスの公開キー用にPUKの秘密の半分を暗号化し、新しいデバイスはこの暗号文をサーバーからダウンロードします。 新しいデバイスはPUKを復号化し、すべての長命のチャットメッセージにすぐにアクセスできます。



アリスはデバイスをリコールするたびにPUKを変更します。これにより、最近リコールされたデバイスを除くすべてのデバイスが新しいPUKを受け取ります。



この同期スキームは、初期のキーベースPGPシステムとは根本的に異なります。 ここで、関係するすべてのキーには32バイトの真のエントロピーがあり、サーバーハッキングの場合にブルートフォースで壊れることはありません。 True、 Curve25519またはGoのPRNGが破損している場合、すべてが破損します。 ただし、PUK同期では、他の重要な暗号化の仮定は行われません。

大きなグループチャットはどうですか？

tL; drグループには、ロールの変更、メンバーの追加および削除のための独自の監査済み署名チェーンがあります。



セキュリティ研究者は 、グループチャットに対する仮想ユーザー攻撃について書いています。 ユーザーのクライアントがグループメンバーシップを暗号で検証できない場合、悪意のあるサーバーがグループチャットにスパイウェアとモルを埋め込むことができます。 キーベースには、ここでグループの特別な機能という形で非常に信頼性の高いシステムがありますが、これについては今後説明します。

NCC-KB2018-001について話してもらえますか？

このバグはNCC監査の最も重要な発見であると考えています。 キーベースは不変のデータ構造を積極的に使用して、サーバーのあいまいさから保護します。 バグの場合、正直なサーバーが回避を開始する可能性があります。「以前Aに言ったが、バグが発生したため、Bを意味した」。 しかし、クライアントには、サーバーにこのような柔軟性を許可しないという共通のポリシーがあります。バグの場合には、 ハードコーディングされた例外があります。



最近、 Sigchain V2も導入しました 。このシステムは、最初のバージョンでは正しく予測できなかったスケーラビリティの問題を解決します。 現在、クライアントは、各中間リンクの署名ではなく、署名チェーンの末尾から1つの署名のみを受信するサーバーから取得する暗号化データを使用する方が経済的です。 したがって、顧客は特定の署名ハッシュを検索するサイクルに行く機会を失いましたが、以前はこれらのハッシュを使用して、このハードコーディングされた例外のリストで不良チェーンリンクを検索しました。 Sigchain V2のリリースの準備をしていましたが、抽象化のいくつかの層に埋もれていたこの詳細を忘れていたため、システムはサーバー応答からフィールドを単純に信頼していました。



NCCがこのエラーを発見すると、 修正は非常に簡単でした。チェーンリンク署名ハッシュではなく、チェーンリンクハッシュを使用してハードコーディングされた例外を探します。 クライアントは常にこれらのハッシュを直接計算できます。



このエラーは、Sigchain V1とSigchain V2を同時にサポートするために必要な追加の複雑さに起因することもあります。 最新のクライアントはSigchain V2リンクを記述しますが、すべてのクライアントは無期限にレガシーv1リンクをサポートする必要があります。 顧客は各デバイスの秘密鍵でリンクに署名することを思い出してください。 これらのクライアントは単にオフラインである可能性があるため、すべての顧客が妥当な時間内に履歴データを上書きするよう調整することはできません。

NCC-KB2018-004について話してもらえますか？

001（上記参照）のように、時代遅れのソリューションの同時サポートと最適化の特定の組み合わせに失望しました。これは、システムの操作経験を積むにつれて重要に思われました。



Sigchain V2では、ユーザーの検索に必要な帯域幅を削減するために、チェーンのサイズをバイト単位で削減します。 この節約は、携帯電話では特に重要です。 したがって、チェーンリンクをJSONではなくMessagePackでエンコードします 。 次に、顧客はこれらのチェーンの署名に署名して検証します。 NCCの研究者は、JSONとMessagePackのように見える「署名」を作成するための巧妙な方法を発見し、競合を引き起こしています。 JSONパーサーを標準のGoパーサーからより効率的なパーサーに切り替えたときに、最適化中にデコードのこのあいまいさを意図せずに導入しました。 この高速パーサーは、このポリグロット攻撃機能を含む実際のJSONを見つける前に、大量のゴミを静かにスキップしました。 このエラーは、 追加の入力検証によって修正されます 。



Sigchain V2では、署名者がパッケージの前にコンテキストラインプレフィックスとバイト\0



署名を付けることで、検証者が署名者の意図に混乱しないようにするというAdam Langleyの提案も受け入れました。 このコンテキストプレフィックスアイデアの検証側には、他のポリグロット攻撃につながる可能性のあるエラーがありました。 ホワイトリストでこの欠陥をすばやく修正しました 。



両方のバグを修正すると、サーバーはポリグロット攻撃の悪意のある負荷を拒否するため、これらの脆弱性の悪用は、侵害されたサーバーの助けを借りてのみ可能です。

ドキュメントはどこにありますか？

https://keybase.io/docs



今後数か月のうちに、ドキュメントの作成により多くの時間を費やします。

NCCによるこのステートメントの詳細については、「ただし、攻撃者は、チェーン内の後続のリンクを切り捨てることにより、sigchainの更新を拒否したり、ユーザーのsigchainを以前の状態にロールバックしたりすることができます」

キーベースは、サーバーインフラストラクチャがユーザー識別子の1つの真の表現をキャプチャすることを強制する不変の追加専用パブリックデータ構造を広範囲に使用します。 侵害されたサーバーがロールバックできないような方法で、デバイスのリコールとグループメンバーの削除を保証できます。 サーバーが一貫性のないビューを表示することを決定した場合、この偏差は不変のパブリックレコードの一部になります。 キーベースの顧客またはサードパーティの監査人は、攻撃後いつでも不一致を検出できます。 これらの保証は、競合製品の保証をはるかに上回り、携帯電話や計算能力が限られているお客様の実際的な制限を考慮して、ほぼ最適であると考えています。



簡単に言えば、Keybaseは他人の署名を発明することはできません。 他のサーバーと同様に、データを保持できます。 しかし、私たちの透明なマークルツリーは、それらを非常に短時間保存するように設計されており、常に発見可能です。

Keybaseはアカウントのリセットをどのように処理しますか？

キーベースユーザーが実際にすべてのデバイスを失ったとき（新しいデバイスを追加したり、いくつかを失ったりするのではなく）、リセットする必要があります。 アカウントをリセットした後、ユーザーは基本的に新規ですが、ユーザー名は同じです。 彼はすべての鍵を失ったため、「リセット指示」に署名することはできません。 その代わり、Keybaseサーバーは、Merkleツリーに消去不能なステートメントをコミットします。これはリセットを意味します。 クライアントは、これらの指示をロールバックすることを不可能にします。 将来の記事では、特定のメカニズムについて詳しく説明します。



このユーザーは、新しいキーを使用してID検証（Twitter、Githubなど）を再度追加する必要があります。

サーバーは、誰かのマークルツリーリーフを単に交換して、まったく異なるキーのセットをアドバタイズできますか？

NCCの作成者は、Merkleツリーリーフを完全に交換し、ボブの真のキーセットを完全に新しい偽のセットに置き換える、敵対的なキーベースサーバーを検討しています。 攻撃サーバーには2つのオプションがあります。 まず、Bobを1つのフォークに入れて、Bobを別のフォークに入れて世界の状態をフォークできます。 第二に、彼は、正しいボブキーのセットを含むマークルツリーのバージョンと偽のセットを含む他のバージョンを公開することで、「チート」することができます。 ボブと定期的に対話するユーザーは、以前にダウンロードしたボブの履歴のバージョンがサーバーからダウンロードした新しいバージョンの有効なプレフィックスであることを確認するため、この攻撃を発見します。 すべてのキーベースの更新をスキャンするサードパーティのバリデーターもこの攻撃に気づきます。 サードパーティのキーベースバリデーターを作成する場合は、大きな報酬を提供できます。 Keybaseのmax



を参照してください。 そうでなければ、すぐに自律型バリデーターの作成を計画したいと考えています。

私が最後まで読んだことを信じられますか？

あなたはそれを読みましたか、それともただ下にスクロールしましたか？