WhatsAppがチャットバックアップをパスキーで保護——“バックアップは最弱点”の常識が塗り替わる可能性です

今日の深掘りポイント

• バックアップ鍵の保護主体が「ユーザーが覚えるパスワード」から「デバイスの生体認証・ロックコード（パスキー）」にシフトします。これにより、クラウド側アカウント侵害からのバックアップ閲覧が難しくなり、攻撃の主戦場がクラウドからエンドポイント（端末）に移ります。
• 企業・公的機関にとっては、WhatsAppバックアップへの合法的取得や保全（リーガルホールド）の難易度が上がる可能性があります。監査・証拠保全・eDiscovery・法執行との窓口方針の更新が必要になります。
• エンドユーザーにとっては、フィッシングや認証情報詐取に強い反面、端末紛失・窃取とロック解除の組み合わせ（ショルダーハックなど）への備えがより重要になります。
• スコアリング指標の「probability: 9.00」「credibility: 8.50」は実装・展開の確度が高いことを示し、SOC/IT部門は“発表待ち”ではなく展開前提で運用準備を始めるべきです。
• メッセージ本文のE2EEは従来通りですが、「保存履歴（バックアップ）」の守りが段違いに強くなるため、SIMスワップやクラウドアカウント乗っ取りによる“過去ログ奪取”の成功率は低下する見込みです（仮説）。

はじめに

WhatsAppがiOS/Android向けに、パスキーで暗号化されたチャットバックアップを導入すると報じられています。ユーザーは顔認証・指紋認証・端末ロックコードといったデバイス側の要素を使ってバックアップを保護でき、従来の“覚えるパスワード”に依存しない運用に移行できる見込みです。この変更は数カ月内の提供が見込まれており、長年「攻撃面の穴」になりがちだったバックアップの防御を大幅に底上げする動きです。現時点の公開情報は限定的で、設計実装の詳細は未公表の部分がありますが、企業のリスク姿勢・運用設計・法的対応に与えるインパクトは小さくないと見ます。一次情報の不足ゆえ、以下の一部は仮説として提示します。

参照元: Help Net Securityの報道（記事日付: 2025-10-30）

深掘り詳細

事実整理（現時点で公表・報道されていること）

• WhatsAppがチャットバックアップをパスキーで暗号化可能にする新機能を発表したと報じられています。対象はiOSおよびAndroidです。
• パスキーは、端末の生体認証やロックコードで保護された秘密鍵により認証するパスワードレス方式とされ、ユーザーがバックアップ用のパスワードを記憶・管理する必要がなくなると報じられています。
• 数カ月内のロールアウトが示唆されています。
• 背景として、従来のメッセージングにおける“弱点”はバックアップにあることが多く、クラウド連携や人間が管理するパスワード起因の事故が定番でした。今回の変更はその弱点の構造を変える狙いがあります。
• 出典は現時点でHelp Net Securityの報道のみで、WhatsApp公式の詳細仕様は未確認です。

出典: Help Net Security

インサイト（何が変わり、どこが盲点になり得るか）

• 攻撃面の再配分（クラウド→端末）です。これまで“クラウドアカウント乗っ取り→バックアップ閲覧”が比較的成立しやすかったのに対し、パスキーで暗号化した場合、バックアップ復号の鍵素材は端末の生体認証・ロックに紐づく形（少なくともパスワード直接管理ではない形）になり、クラウド側だけを押さえても中身が取れない設計になる可能性が高いです（仮説）。
• 代わりに、端末実物＋ロック解除情報の奪取（窃取端末に対するショルダーハックや強要、スパイウェアによる入力情報・画面窃視など）が相対的に“近道”になり得ます。端末ロックの強度（桁数・英数字化・生体認証の失敗時ポリシー）や、紛失・盗難時の迅速な消去フローの整備が、これまで以上に重要になります。
• ビジネス・法務面では、企業・公的機関における監査・インシデント調査・eDiscoveryで「クラウド側のバックアップを正規手続きで取得すれば中身が読めた」パスが細くなる可能性があります。WhatsAppやクラウド事業者が復号鍵を保持しない設計だとすれば、合意・令状ベースの取得でも“暗号化済みデータ”しか得られない場面が増え、当事者デバイス（鍵素材）へのアクセスが実質的な前提になるかもしれません（仮説）。
• エンドユーザー視点では、フィッシング耐性やパスワード再利用起因の破綻リスクが下がる一方、端末ロックの強度・物理セキュリティ・生体認証の安全性（登録管理・顔写真/指紋のなりすまし対策）に注意が移ります。SOCは“クラウドアカウント保護”偏重から“端末コンテキスト・ロック強度・端末状態監視”を含む体制へ重心移動すべきです。

脅威シナリオと影響

以下はMITRE ATT&CKに沿った想定シナリオの仮説です。実装次第で成立性は変わるため、確定情報ではありません。

• シナリオ1: クラウドアカウント乗っ取りの残存リスクとその低減

  • 想定: 攻撃者が被害者のGoogle/iCloudアカウントを奪取（フィッシング、クッキー盗難、パスワードリスト攻撃）し、クラウド上のWhatsAppバックアップを取得しようとする。
  • 影響の変化: パスキーで暗号化されたバックアップはクラウド側だけでは復号不可のため、従来よりも成功率が低下する見込みです（仮説）。
  • ATT&CK対応: Valid Accounts（T1078）、Credential Access/Phishing（T1566）、Brute Force（T1110）。

• シナリオ2: 端末窃取＋ロック解除（ショルダーハック/強要/情報のぞき見）

  • 想定: 攻撃者が物理端末を窃取し、事前に観察したロックコードを用いて解除、生体認証回避を狙う。
  • 影響: パスキーの“強さ”は端末ロックの強さと運用に依存するため、端末ロックが弱い組織・ユーザーではバックアップ復号の実現性が上がります（仮説）。
  • ATT&CK対応: Input Capture/Shoulder Surfingに近い行為（T1056系の入力取得）、Exploitation of Valid Accounts（T1078）に準ずる扱い。

• シナリオ3: スパイウェア/マルウェアによる認証プロンプト窃視・フロー攪乱

  • 想定: 端末上の悪性アプリが画面のオーバーレイやアクセシビリティAPI悪用でロックコード入力や認証フローを覗き見る。
  • 影響: パスキーそのものの秘密鍵抽出は困難でも、利用者入力や認証コンテキストを奪えばバックアップ復号の機会が生まれる可能性があります（仮説）。
  • ATT&CK対応: Credential Access/Keylogging・Input Capture（T1056）、Modify Authentication Process（T1556）。

• シナリオ4: SIMスワップによるアカウント乗っ取り後の“過去ログ”への到達

  • 想定: 攻撃者がSIMスワップでWhatsAppアカウントを乗っ取り、新端末で復元を試みる。
  • 影響: アカウント自体は奪えても、パスキーで暗号化されたバックアップは復号できないため、過去ログの奪取は困難化する見込みです（仮説）。
  • ATT&CK対応: Phishing（T1566）、Valid Accounts（T1078）。

• シナリオ5: 法執行・監査のためのデータ取得が暗号化で遮断されるケース

  • 想定: 正規手続きでクラウド事業者またはWhatsAppからバックアップ提供を受けても、復号鍵が当事者端末側にしかない設計だと内容閲覧が困難。
  • 影響: 電子証拠の取得は“端末＋ロック解除”が前提となり、現場対応・差押え・デジタルフォレンジックの手順がより中心的になります（仮説）。
  • ATT&CK視点: 攻撃者行為ではないものの、組織側の“アクセスパス”が暗号化で閉じることによる調査プロセスの再設計が必要になります。

総じて、攻撃者コストの主たる増分は「クラウド側の信用情報さえ奪えば勝ち」という従来パターンの失効です。一方で、エンドポイント保護（物理・ロック・マルウェア耐性）の運用成熟度が差を生みやすくなる点に注意が必要です。

セキュリティ担当者のアクション

• 端末ロック強度のベースライン引き上げ

  • BYOD/COPEを問わず、MDM/EMMでロックポリシーを強化します（英数字パスコード、最小桁数、一定回数失敗でデータ消去、スクリーンオーバーレイ禁止、アクセシビリティ悪用対策など）を必須とします。
  • 生体認証の登録ポリシーを整備し、未承認の生体追加を検知・抑止する設定を確認します。

• 紛失・窃取への即応体制

  • 紛失申告からの“端末遠隔ワイプ”SLA、セルラー停止、アカウントセッション無効化のRunbookを整備し、定期演習します。
  • 物理盗難＋ショルダーハックを想定した啓発（ロック解除時の周囲環境、スマートロック機能の無効化、ロック画面通知の秘匿）を徹底します。

• クラウド依存から端末依存へのリスク移行を前提に、監視と検知を再設計

  • これまで重点だったクラウドアカウント保護（OAuthトークン監視、ログイン異常検知）に加え、端末コンテキスト（Jailbreak/Root検知、悪性アプリ、アクセシビリティ悪用、画面オーバーレイ）に関するテレメトリを可視化します。
  • モバイルEDR/MTDの導入・チューニングを進め、入力窃取・画面覗き・権限濫用の兆候検知を強化します。

• eDiscovery・リーガルホールド・法執行対応の方針更新

  • 暗号化バックアップが標準化すると、クラウドから“読めるデータ”を得る経路が細る可能性があります。事前の合意、業務チャットの利用方針、証跡の保存要件を見直し、必要に応じて監査可能な公式コラボレーション基盤に誘導します。
  • インシデント時の証拠確保は“端末＋ロック解除権限”の確保が鍵になるため、デジタルフォレンジックのキット・手順・法務連携を再整備します。

• 利用者向けの具体的ガイダンス

  • WhatsApp側の設定でパスキー暗号化バックアップが利用可能になり次第、有効化を推奨します。展開告知前に社内FAQとハウツーを用意します。
  • SIMスワップ対策（携帯キャリアのアカウント保護、PIN設定）、フィッシング対策（ブラウザ・メール・SMS）を併せて周知します。バックアップ保護が強化されても、アカウント乗っ取り自体のリスクは依然残るためです。

• メトリクスの読み解きと優先度付け

  • score: 61.50（scale: 10.00相当の合成指標）は、複数観点（novelty: 6.00、immediacy: 7.00、actionability: 7.00、positivity: 8.00、probability: 9.00、credibility: 8.50）を加重した結果と解釈できます。確度（probability・credibility）が高く、即応性（immediacy・actionability）も十分なため、SOC/ITは“リリース後に考える”ではなく、端末側の統制・紛失対応・教育を前倒しで始めるべきシグナルと読みます。
  • magnitude: 6.00は全社リスクプロファイルの中位〜中上位を示唆します。WhatsAppの業務利用（正式・非公式）依存度が高い部門では優先度を一段引き上げる判断が妥当です。

参考情報

• Help Net Security: WhatsApp now lets users secure chat backups with passkeys（2025-10-30）: https://www.helpnetsecurity.com/2025/10/30/whatsapp-secure-chat-backups-passkeys/

注記:

• 本稿のうち、設計詳細や攻撃シナリオの一部は、現時点の公知情報が限られるため仮説として提示しています。WhatsApp公式ドキュメントが公開され次第、技術仕様と運用示唆をアップデートします。