暗号学的 ID の復旧、アカウントへの再ログイン、チャット履歴の復元は、それぞれ異なる操作です。Livara のセキュリティ文書によると、v7 形式は暗号学的 ID の復旧に用いられます。この形式そのものがチャット履歴を復元するわけではありません。
また、このアーキテクチャを「クラウドバックアップが一切ない」と表現すべきではありません。現行文書には、ID の構成情報をデバイス上で暗号化し、その後、暗号化されたバックアップとしてアップロードすると記されています。重要なのは、読める鍵をサーバーに保存することと、開くために復旧鍵が必要な暗号化コピーを保存することの違いです。
同じ鍵では開かない三つの扉
| 操作 | 目的 | それだけでは不十分な理由 |
|---|---|---|
| アカウントへのログイン | サービスのアカウントへのアクセス権を証明する | 過去のメッセージの復号鍵が得られるとは限らない |
| ID の復旧 | 暗号学的 ID の構成情報に再びアクセスする | それだけでは全メッセージの存在や復元を証明しない |
| 履歴の復元 | 必要なメッセージや添付ファイルを戻す | 鍵に加え、データ自体とサポートされた復元方法が必要 |
この区別により、ログインパスワードを知っていれば全会話を戻せると思い込み、古いスマートフォンを消去するという、代償の大きな誤りを防げます。
v7 の文書には正確には何と書かれているか？
Livara のセキュリティページは、P-256 の鍵合意用・署名用の鍵と ML-KEM のシードが、ランダムな 256 ビット復旧鍵を使ってデバイス上で暗号化されると説明しています。v7 形式の説明では、アルゴリズムスイート、ID エポック、世代についても真正性が検証されます。これは提供元の文書であり、それだけで実装の独立監査にはなりません。
Livara の脅威モデルは、鍵のバックアップを開くには復旧フレーズが必要だとしています。この説明から、フレーズを鍵に変換する具体的なアルゴリズムや、すべての鍵を直接再構成できることを推測してはいけません。実際の手順は、アプリのバージョンと、そのバージョンのガイドに合わせて確認する必要があります。
なぜ導出関数は弱いフレーズを強くしないのか？
関数の出力長と、入力の推測しにくさは同じではありません。RFC 5869は、HKDF は既存のエントロピーを集約するものの、増やさないと明記しています。したがって、任意のフレーズを HKDF に通すだけで、自動的に完全な 256 ビットの安全性が得られるとは主張できません。
アプリの正式な手順で生成されたフレーズを、勝手に短縮したり書き換えたり、推測しやすい文に置き換えたりしないでください。誰にも、サポート用ボットにも、不明なフォームにも送信しないでください。
スマートフォンを交換・消去する前に
- アプリで、何がバックアップされているかを確認します。ID、履歴、または別々の方法による両方でしょうか。
- 復旧フレーズは、そのスマートフォンとは独立した安全な場所に保管してください。他者にアクセスされることを重大なリスクと考えます。
- 現行バージョンの復旧ガイドを読んでください。「ログイン成功」という表示だけを完全な復旧の結果と見なさないでください。
- 復旧テストの方法がサポートされている場合は、まず非機密データで、唯一の現存コピーを消さずに試してください。
- 移行後、必要な会話やファイルを確認してから、古いデバイスを手放すかどうかを判断してください。
復旧フレーズがない場合は？
まだ認証済みデバイスを持っているなら、そのアプリ内にある正式な手順だけを確認してください。バージョンを確認せず、新しいバックアップを作れると想定してはいけません。デバイスとフレーズの両方を失った場合、Livara の文書は鍵の復旧を約束していません。「復号保証」をうたうサービスを、この限界に代わる手段と考えないでください。
アカウント移行の計画は、「どのデータが、どの鍵で、どのバックアップから戻るのか？」という問いから始めてください。再ログインが全チャットの復帰と同じだと想定してはいけません。
