WhatsAppはローカルまたはGoogleドライブのバックアップをどのように復元できますか？
これはすべてエンドツーエンドの送信プロトコルに関するものではなく、私の質問は主にAndroid中心です。
私が自問していること：ローカルのWhatsAppデータベースのバックアップのハッキングと解読について読むとき、制限されたアプリ領域の秘密鍵がAndroidから必要であると述べられています。ルート権限を取得した電話がない場合は、通常、このキーにアクセスできません。バックアップファイル（ファイル拡張子crypt5-12）は通常、このキーがないと役に立ちません。
電話を切り替えるとき（新しい電話を購入するときなど）は、ローカルsdcard/WhatsApp新しい電話へのフォルダと同じ番号が使用されている場合、WhatsAppはそのバックアップを復号化できます：ソースはここにあります https://www.whatsapp.com/faq/en/Android/20887921#restore
最初の前提：バックアップキーはWhatsAppサーバーにも保存されます。それ以外の場合、ローカル電話から電話へのバックアップは機能しませんか？
2番目の想定：したがって、最悪の部分は、Googleドライブにバックアップする場合、WhatsAppは理論的には（うまくいけば暗号化された）バックアップにアクセス（？）し、サーバー上の暗号化キー/復号化キーにもアクセスできることです。または、少なくともWhatsApp自体で読み取れないGoogleドライブの間に分離がありますか？誰かがもっと詳細を持っていますか？
End2end暗号化プロトコルに関する最後の言葉：少なくとも1人の友人がGoogleドライブのチャットのバックアップを行うと（通常のハッカーに対してではなく、米国の監視に対しては）役に立たないようです（チャットの履歴は取得可能です）。
最初の前提：バックアップキーはWhatsAppサーバーにも保存されます。それ以外の場合、ローカル電話から電話へのバックアップは機能しませんか？
TL; DR：はい、調査の結果、そうなったようです。
セカンダリデバイス
プロトコルはかなり複雑で、WhatsAppに限定されませんが、一般的にはこのように機能します。チャットアプリを使用する電話は、最初のデバイスと呼ばれます。このデバイスは、プライベートIDキー、接続パスワード、ローカル暗号化キー、添付ファイル暗号化キーなどのすべての機密データを格納する万能のデバイスです。他のすべてのデバイスは2番目のデバイスと呼ばれ、これにはWhatsAppが含まれますWebおよびデスクトップクライアント。これらのクライアントは基本的にdumbです。
新しいデバイスが表示されるときは常に、最初に最初のデバイスを介して認証される必要があります。 WhatsAppは、初期QRコードを使用して（他のアプリはSMSトークンを使用）、次に証明のセットを使用してこれを行います。最終的に、最初のデバイスは、セカンダリデバイスが機密データを制御できるかどうかを決定します。その場合、2番目のデバイスは要求に応じてこれらのキーを受信します。これらのキーを使用して、2番目のデバイスは連絡先ファイルをダウンロードし、要求されたキーを使用してそれを復号化できます。同じことがすべてのメディアメッセージで機能します。 WhatsApp固有の注意：これらのキーリクエストは非常に短いため、セカンダリクライアントです必須最初のデバイスにデータにアクセスするための新しいキーを定期的に要求します。これにより、WhatsApp Webで迷惑な「Phone not connected」アラートが発生します。
WhatsAppを新しい電話にインストールすると、このプロセス全体が実行され、最初のデバイスが新しい電話を承認し、2つのアクティブなインスタンスの1つを即座にロックアウトします。次に、いずれかの電話を選択する選択肢があります。新しい電話を選択すると、すべてのシークレットの所有権が2番目のデバイスに転送され、それが最初のデバイスになり、サークルが完成します。
バックアップ
いくつかの調査、アプリの逆コンパイル、テストシナリオの実行後、次のことを実行できます。アプリはいくつかのローカル（SQLite）データベースを使用しています。メッセージは暗号化されずにこれらのデータベースに保存され、データベース自体も暗号化されません。これは、data /フォルダーから.dbファイルをダウンロードすることで確認できます。これは、実行モードのWhatsAppのデフォルトの保存場所であり、パフォーマンス上の理由から暗号化されていません。通常のアプリはdataフォルダー内の.dbファイルにアクセスできないはずですが、いくつかのadb回避策があります。
設定やメッセージを含むデータベースファイルは、Googleドライブにバックアップされます（選択した場合）。アプリは、ユーザーがバックアップをダウンロードまたはアクセスできないようにするために、Googleドライブのフォルダーのロックをリクエストできます。リモートバックアップの場所に送信されるメッセージデータベースはmsgstore.db.crypt[0-12]ファイルで、最後の数字はプロトコルバージョンを示します。データベース暗号化されているデータフォルダーに格納されているキー。このキーは実際にはWhatsAppサーバーに保存されています。
2番目の想定：したがって、最悪の部分は、Googleドライブにバックアップする場合、WhatsAppは理論的には（うまくいけば暗号化された）バックアップにアクセス（？）し、サーバー上の暗号化キー/復号化キーにもアクセスできることです。または、少なくともWhatsApp自体で読み取れないGoogleドライブの間に分離がありますか？誰かがもっと詳細を持っていますか？
新しいデバイスをインストールしてGoogleアカウントをセットアップした瞬間に、ファイルはアプリからリクエストされ、ローカルデバイスで設定されます。これには、他人にあなたの身元を証明するために必要な身元鍵を含むaxolotlデータベースが含まれます。復号化キーは、新しくインストールされたWhatsAppインスタンスに電話番号（ユーザー名）の所有権を証明した後に取得されます。理論的には、WhatsAppはこれらのファイルにアクセスできるnotでなければなりませんが、あなたとGoogleだけがアクセスできます。もちろん、WhatsAppはファイルをダウンロードして別の場所に送信することもできます。しかし、ある時点で、特にオープンソースでない場合は、アプリを信頼する必要があります。
WhatsAppもローカルバックアップを作成しており、通常は1日2回sdcard/whatsappにあります。これらのローカルバックアップにはIDキーとメッセージストレージデータベースも含まれており、実際には暗号化されています。ここでも、暗号化キーはWhatsAppプロファイルと一緒にリモートサーバーに保存されます。これは、WhatsAppバックアップフォルダ全体を1つのデバイスから別のデバイスに移動できる理由を説明しています。検証済みの電話番号がないと、バックアップファイルを読み取ったり、IDキーを使用したりすることはできませんが、ルート化されたデバイスは、元の暗号化されていないデータベースファイルに簡単にアクセスできます。
End2end暗号化プロトコルに関する最後の言葉：少なくとも1人の友人がGoogleドライブのチャットのバックアップを行うと（通常のハッカーに対してではなく、米国の監視に対しては）役に立たないようです（チャットの履歴は取得可能です）。
Googleや、FacebookやWhatsAppなどの他の企業が、FISA法に基づく要求に応じてファイルを提供していることはわかっているため、この時点から話は良くなりません。すでに「バックドア」が存在するため、エンドツーエンドの通信で攻撃する必要はありません。 E2Eは、通信チャネル上のアクティブな攻撃者からのみ保護します。攻撃者は、一方の当事者にバックアップファイルを要求し、他方の当事者に復号化キーを要求する能力を持ちません。
攻撃の窓
リソースが限られている非政府または「通常の」攻撃者からの状況を見るとすると、デバイスは明らかに弱点です。 root権限を持つすべてのアプリは、データベースへのアクセス、キーのコピーなども行えます。デフォルトのAndroid ROMには、systemユーザーで実行されている多くのアプリが含まれていますが、ROMに同梱されているベンダーのアプリ（およびアップデート）も含まれていますユーザーの介入から保護されているため、systemとして実行されます。
悪意のあるアプリにもリスクがないわけではありません。適切な権限があれば、SDカードストレージを完全に制御でき、暗号化されたバックアップにアクセスできます。検証SMSが正しいタイミングでインターセプトされ（SMS受信コールでフック）、電話番号がコピーされると、自己制御のWhatsAppインスタンスをアクティブ化できるはずですデータベースの復号化キーを受信します。攻撃者がモバイル通信を制御している場合（政府がよく行う）、攻撃はさらに可能性が高くなります。
ルート権限を必要としないため、adb攻撃はさらに悪化します。基本的に、ダウングレード攻撃は、古いバージョンのWhatsAppがブリッジインターフェースを介してインストールされている場合に可能です。これはいわゆるレガシーWhatsAppをだましてアプリケーション全体のバックアップを作成し、tarアーカイブを作成できます。 tarballはadbサーバー側にプルされ、抽出されます。適切に準備すると、USBケーブルと数秒で完了します。